TCP粘包问题

什么是粘包

首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.

• 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
  站在应用层的角度, 看到的只是一串连续的字节数据.
  那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.
• TCP受到对端TCP接收缓冲区大小的约束和MTU的影响，需要分割报文。所以，当用户消息通过 TCP 协议传输时，消息可能会被操作系统分组成多个的 TCP 报文进行传输。

举例子

发送方准备发送 【Hello】和【World】这两个消息。

在发送端，当我们调用 send 函数完成数据“发送”以后，数据并没有被真正从网络上发送出去，只是从应用程序拷贝到了操作系统内核协议栈中。

至于什么时候真正被发送，取决于发送窗口、拥塞窗口以及当前发送缓冲区的大小等条件。也就是说，我们不能认为每次 send 调用发送的数据，都会作为一个整体完整地消息被发送出去。

考虑到实际网络传输过程中的各种影响，假设发送端陆续调用 send 函数先后发送 【hello】和【world】 报文，那么实际的发送很有可能是以下几种情况：

• 第一种情况，这两个消息被分到同一个 TCP 报文，即【hello world】

• 第二种情况，两个报文的数据夹杂在一起，如：【hel】【loworld】或者【hellowo】【rld】等等情况

• 所以如果不对报文进行处理，我们无法知道 【hello】和【world】 这两个数据是如何进行传输的。

所以，当两个消息的某个部分内容被分到同一个 TCP 报文时，就是我们常说的 TCP 粘包问题，这时接收方不知道消息的边界的话，是无法读出有效的消息。

要解决这个问题，要交给应用程序。

如何解决粘包？

粘包的问题出现是因为不知道一个用户消息的边界在哪，如果知道了边界在哪，接收方就可以通过边界来划分出有效的用户消息。

所以解决办法归根结底就是一句话, 明确两个包之间的边界.

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲
  区从头开始按sizeof(Request)依次读取即可;
• 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
  对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

特殊字符作为边界

我们可以在两个用户消息之间插入一个特殊的字符串，这样接收方在接收数据时，读到了这个特殊字符，就把认为已经读完一个完整的消息。
以http协议为例：
http的协议格式：

请求行\r\n
请求头部\r\n
空行\r\n
请求体

HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界，同时采取content-length字段来显示告诉对端协议数据包的大小，以此来避免粘包带来的后果。

要注意的是，这个作为边界点的特殊字符，如果刚好消息内容里有这个特殊字符，我们要对这个字符转义，避免被接收方当作消息的边界点而解析到无效的数据。