P粘包发送方接收方应用层

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包从接收缓冲区来看后一包数据的头紧接着前一包数据的尾。

TCP粘包现象的根本原因是TCP采用了面向字节流的传输面向字节流的传输不认为消息是一条一条的它是无保护消息边界的。

具体来说出现粘包的原因是多方面的可能是来自发送方也可能是来自接收方。

发送方原因

发送端为了将多个发往接收端的包更加高效的发给接收端于是采用了优化算法Nagle算法将多次间隔较小、数据量较小的数据合并成一个数据量大的数据块然后进行封包。

TCP默认使用Nagle算法主要作用减少网络中报文段的数量而Nagle算法主要做两件事

只有上一个分组得到确认才会发送下一个分组收集多个小分组在一个确认到来时一起发送

接收方原因

TCP接收到数据包时并不会马上交到应用层进行处理或者说应用层并不会立即处理。

实际上TCP将接收到的数据包保存在接收缓存里然后应用程序主动从缓存读取收到的分组。

这样一来如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度多个包就会被缓存应用程序就有可能读取到多个首尾相接粘到一起的包。

如何处理TCP粘包

如果发送方发送的多组数据本来就是同一块数据的不同部分比如说一个文件被分成多个部分发送这时当然不需要处理粘包现象。

如果多个分组毫不相干甚至是并列关系那么这个时候就一定要处理粘包现象了

发送方

对于发送方造成的粘包问题可以通过关闭Nagle算法来解决使用TCP_NODELAY选项来关闭算法。

接收方

应用层的解决办法简单可行不仅能解决接收方的粘包问题还可以解决发送方的粘包问题。

解决办法循环处理应用程序从接收缓存中读取分组时读完一条数据就应该循环读取下一条数据直到所有数据都被处理完成但是如何判断每条数据的长度呢

格式化数据每条数据有固定的格式开始符结束符这种方法简单易行但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

发送长度发送每条数据时将数据的长度一并发送例如规定数据的前4位是数据的长度应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

为什么UDP没有粘包问题

TCP为了保证可靠传输并减少额外的开销每次发包都要验证采用了基于流的传输基于流的传输不认为消息是一条一条的是无保护消息边界的保护消息边界指传输协议把数据当做一条独立的消息在网上传输接收端一次只能接受一条独立的消息。

UDP则是面向消息传输的是有保护消息边界的接收方一次只接受一条独立的信息所以不存在粘包问题。

举个例子有三个数据包大小分别为2k、4k、6k如果采用UDP发送的话不管接受方的接收缓存有多大我们必须要进行至少三次以上的发送才能把数据包发送完但是使用TCP协议发送的话我们只需要接受方的接收缓存有12k的大小就可以一次把这3个数据包全部发送完毕。