5.TCP数据粘包的处理

5.1背锅侠

因为数据的传输是基于流的所以发送端和接收端每次处理的数据的量，处理数据的频率可以不是对等的，可以按照自身需求来进行决策。

TCP 协议是优势非常明显，但是有时也会给我们造成困扰，正所谓：成也萧何败萧何。假设我们有如下需求：

客户端和服务器之间要进行基于 TCP 的套接字通信

• 通信过程中客户端会每次会不定期给服务器发送一个不定长度的有特定含义的字符串。

• 通信的服务器端每次都需要接收到客户端这个不定长度的字符串，并对其进行解析

根据上面的描述，服务器在接收数据的时候有如下几种情况：

1. 一次接收到了客户端发送过来的一个完整的数据包

2. 一次接收到了客户端发送过来的 N 个数据包，由于每个包的长度不定，无法将各个数据包拆开

3. 一次接收到了一个或者 N 个数据包 + 下一个数据包的一部分，还是很悲剧，无法将数据包拆开

4. 一次收到了半个数据包，下一次接收数据的时候收到了剩下的一部分 + 下个数据包的一部分，更悲剧，头大了

5. 另外，还有一些不可抗拒的因素：比如客户端和服务器端的网速不一样，发送和接收的数据量也会不一致

对于以上描述的现象很多时候我们将其称之为 TCP的粘包问题，但是这种叫法不太对的，本身 TCP 就是面向连接的流式传输协议，特性如此，我们却说是 TCP 这个协议出了问题，这只能说是使用者的无知。多个数据包粘连到一起无法拆分是我们的需求过于复杂造成的，是程序猿的问题而不是协议的问题，TCP 协议表示这锅它不想背。

现在问题来了，服务器端如果想保证每次都能接收到客户端发送过来的这个不定长度的数据包，程序猿应该如何解决这个问题呢？下面给大家提供几种解决方案：

1. 使用标准的应用层协议（比如：http、https）来封装要传输的不定长的数据包

2. 在每条数据的尾部添加特殊字符，如果遇到特殊字符，代表当条数据接收完毕了 有缺陷：效率低，需要一个字节一个字节接收，接收一个字节判断一次，判断是不是那个特殊字符串

3. 在发送数据块之前，在数据块最前边添加一个固定大小的数据头，这时候数据由两部分组成：数据头 + 数据块 数据头：存储当前数据包的总字节数，接收端先接收数据头，然后在根据数据头接收对应大小的字节 数据块：当前数据包的内容

5.2解决方案

如果使用 TCP 进行套接字通信，如果发送的数据包粘连到一起导致接收端无法解析，我们通常使用添加包头的方式轻松地解决掉这个问题。关于数据包的包头大小可以根据自己的实际需求进行设定，这里没有啥特殊需求，因此规定包头的固定大小为4个字节，用于存储当前数据块的总字节数。

5.2.1 发送端

对于发送端来说，数据的发送分为 4 步：

1. 根据待发送的数据长度 N 动态申请一块固定大小的内存：N+4（4 是包头占用的字节数）

2. 将待发送数据的总长度写入申请的内存的前四个字节中，此处需要将其转换为网络字节序（大端）

3. 将待发送的数据拷贝到包头后边的地址空间中，将完整的数据包发送出去（字符串没有字节序问题）

4. 释放申请的堆内存。

由于发送端每次都需要将这个数据包完整的发送出去，因此可以设计一个发送函数，如果当前数据包中的数据没有发送完就让它一直发送，处理代码如下：

关于数据的发送最后再次强调：字符串没有字节序问题，但是数据头不是字符串是整形，因此需要从主机字节序转换为网络字节序再发送。

5.2.2 接收端

了解了套接字的发送端如何发送数据，接收端的处理步骤也就清晰了，具体过程如下：

1. 首先接收 4 字节数据，并将其从网络字节序转换为主机字节序，这样就得到了即将要接收的数据的总长度

2. 根据得到的长度申请固定大小的堆内存，用于存储待接收的数据

3. 根据得到的数据块长度接收固定数目的数据保存到申请的堆内存中

4. 处理接收的数据

5. 释放存储数据的堆内存

从数据包头解析出要接收的数据长度之后，还需要将这个数据块完整的接收到本地才能进行后续的数据处理，因此需要编写一个接收数据的功能函数，保证能够得到一个完整的数据包数据，处理函数实现如下