✍个人博客:Pandaconda-CSDN博客
📣专栏地址:http://t.csdnimg.cn/fYaBd
📚专栏简介:在这个专栏中,我将会分享 C++ 面试中常见的面试题给大家~
❤️如果有收获的话,欢迎点赞👍收藏📁,您的支持就是我创作的最大动力💪
📝推荐参考地址:https://www.xiaolincoding.com/(这个大佬的专栏非常有用!)
70. 解释 TCP 为什么是流协议?怎么分割?
当用户消息通过 TCP 协议传输时,消息可能会被操作系统分组成多个的 TCP 报文,也就是一个完整的用户消息被拆分成多个 TCP 报文进行传输。
这时,接收方的程序如果不知道发送方发送的消息的长度,也就是不知道消息的边界时,是无法读出一个有效的用户消息的,因为用户消息被拆分成多个 TCP 报文后,并不能像 UDP 那样,一个 UDP 报文就能代表一个完整的用户消息。
举个实际的例子来说明。
发送方准备发送「Hi.」和「I am Xiaolin」这两个消息。
在发送端,当我们调用 send 函数完成数据“发送”以后,数据并没有被真正从网络上发送出去,只是从应用程序拷贝到了操作系统内核协议栈中。
至于什么时候真正被发送,取决于发送窗口、拥塞窗口以及当前发送缓冲区的大小等条件。也就是说,我们不能认为每次 send 调用发送的数据,都会作为一个整体完整地消息被发送出去。
如果我们考虑实际网络传输过程中的各种影响,假设发送端陆续调用 send 函数先后发送「Hi.」和「I am Xiaolin」报文,那么实际的发送很有可能是这几种情况。
第一种情况,这两个消息被分到同一个 TCP 报文,像这样:
第二种情况,「I am Xiaolin」的部分随「Hi」在一个 TCP 报文中发送出去,像这样:
第三种情况,「Hi.」的一部分随 TCP 报文被发送出去,另一部分和「I am Xiaolin」一起随另一个 TCP 报文发送出去,像这样。
类似的情况还能举例很多种,这里主要是想说明,我们不知道「Hi.」和「I am Xiaolin」这两个用户消息是如何进行 TCP 分组传输的。
因此,我们不能认为一个用户消息对应一个 TCP 报文,正因为这样,所以 TCP 是面向字节流的协议。
当两个消息的某个部分内容被分到同一个 TCP 报文时,就是我们常说的 TCP 粘包问题,这时接收方不知道消息的边界的话,是无法读出有效的消息。
要解决这个问题,要交给应用程序。
71. TCP 粘包问题
- 固定长度
指定固定的长度,实现起来简单方便,但是可能会浪费内存资源。
- 特殊分隔符
我们可以在两个用户消息之间插入一个特殊的字符串,这样接收方在接收数据时,读到了这个特殊字符,就把认为已经读完一个完整的消息。
HTTP 是一个非常好的例子,通过 \r\n 来进行分隔。
HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界。
有一点要注意,这个作为边界点的特殊字符,如果刚好消息内容里有这个特殊字符,我们要对这个字符转义,避免被接收方当作消息的边界点而解析到无效的数据。
- 自定义消息结构
我们可以自定义一个消息结构,由包头和数据组成,其中包头包是固定大小的,而且包头里有一个字段来说明紧随其后的数据有多大。
比如这个消息结构体,首先 4 个字节大小的变量来表示数据长度,真正的数据则在后面。
struct { u_int32_t message_length; char message_data[];
} message;
当接收方接收到包头的大小(比如 4 个字节)后,就解析包头的内容,于是就可以知道数据的长度,然后接下来就继续读取数据,直到读满数据的长度,就可以组装成一个完整到用户消息来处理了。
72. protobuf 了解吗?
Protobuf 是用于数据序列化和反序列化的格式,类似于 JSON。但它们有以下几点区别:
- 数据大小:Protobuf 是一种二进制格式,相对于 JSON 来说,数据大小更小,序列化和反序列化的效率更高,因此在网络传输和存储方面具有一定的优势。
- 性能:由于 Protobuf 是二进制格式,相对于 JSON 来说,解析速度更快,占用的 CPU 和内存资源更少,因此在高并发场景下,性能更优。
- 可读性:JSON 是一种文本格式,可读性更好,易于调试和排查问题。而 Protobuf 是一种二进制格式,可读性较差。
Protobuf 适用于高性能、大数据量、高并发等场景,而 JSON 适用于数据交换、易读性要求高的场景。