tcp粘包问题是什么如何解决（数据粘包怎么解决）

导读 我们在涉及TCP协议的应用中，经常会出现粘包的问题。所谓粘包，简单地讲，就是我有两条消息，明明发送端的代码是分两次发送的，但是在接收端却一次性就接收到了两条消息。这个情况不管是在嵌入式行业还是在互联网行业，都非常的普遍。

我们在涉及TCP协议的应用中，经常会出现粘包的问题。所谓粘包，简单地讲，就是我有两条消息，明明发送端的代码是分两次发送的，但是在接收端却一次性就接收到了两条消息。这个情况不管是在嵌入式行业还是在互联网行业，都非常的普遍。

TCP协议为什么粘包？

那就需要先了解 TCP 的定义。TCP（Transmission Control Protocol）传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。

其中跟粘包关系最大的就是基于字节流这个特点。字节流可以理解为一个双向的通道里流淌的数据，这个数据其实就是我们常说的二进制数据，简单来说就是一大堆 01 串。这些 01 串之间没有任何边界。

应用层传到 TCP 协议的数据，不是以消息报为单位向目的主机发送，而是以字节流的方式发送到下游，这些数据可能被切割和组装成各种数据包，接收端接收到这些数据包后没有正确还原之前的消息，因此出现粘包现象。

那为什么会出现不能正确还原的情况呢？主要有两个方面的原因：

1. 发送端的原因

发送端在组装消息的时候，就把几个小包合成一包了，这样接收端自然无法解析出小包。这对应的就是Nagle 算法。因为TCP和Nagle 算法都是上个世纪的产物了，在早期的网络中这样做，可以显著地减小网络的压力。否则频繁地发送仅有几个字节的小包，会严重浪费网络IO性能。

但是在现代互联网中，网络性能已经有了大幅提升，似乎Nagle 算法提升的那么一点IO性能就不是那么重要了，反而由于等待数据来合并的操作，会导致传输延迟变大，在网络游戏应用时，就会非常影响体验。所以现在一般都会关掉它。

2. 接收端的原因

接收端接收到消息以后，应用层总是不能立即取走数据，总是会有接收缓冲区的存在。如果两条独立的消息进入缓冲区的间隔太小，应用层不能在两次消息中间取走上一条消息，那么下次读取的时候，就势必会把两包消息同时读出来，这也会导致粘包。

而且这个情况并不能通过让发送端在时间上均匀发包来避免，因为网络不稳定情况的存在，即使是时间上均匀发送的数据包，在接收端看来也可能是随机出现的。

如何规避粘包的负面影响？

根据以上分析，我们不难发现，想要杜绝粘包的问题出现，基本上是不可能的。即使发送端和接收端都能自己控制，但是网络传输的过程也是很难控制的。

但是即使粘包的问题存在，也不影响我们大规模的使用TCP协议。因为这个问题在应用层非常好处理。大致有两种思路：

1. 在信息中加入特殊的标志作为分隔符

这样，当应用层检测到特殊的分隔符后，便知道这是一包得到开始和结束，就可以进行分片等操作，问题便迎刃而解。

不过这样存在一些弊端。比如定义分隔符为“12345678”，那如果消息内容里面出现“12345678”的字符串呢？这样就会导致消息被异常的切片，导致接收到的消息错误。但假如自己能够控制消息的内容，保证里面不会出现“12345678”的内容，则此方法较为灵活。

2. 加入信息的长度

根据约定好的长度的字段，读取消息长度的信息，再根据消息长度信息读取消息内容。这也是一种非常常用的方法，在很多协议中都有体现。

3. 添加包首部

发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，就可以通过读取包首部的长度字段，知道每一个数据包的实际长度。