TCP粘包及拆包详解 古城微笑少年丶 2023-07-03 10:51 51阅读 0赞 # 一、 TCP粘包 # **TCP粘包** 就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。 正常情况： ![在这里插入图片描述][20200205222248103.png] 出现粘包现象： ![在这里插入图片描述][20200205222148531.png] # 二、出现TCP粘包的原因 # ## 发送方原因 ## TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事： * 只有上一个分组得到确认，才会发送下一个分组 * 收集多个小分组，在一个确认到来时一起发送 **Nagle算法造成了发送方可能会出现粘包问题**。 Nagle 算法是指发送方发送的数据不会立即发出,而是先放在缓冲区, 等缓存区满了再发出. 发送完一批数据后, 会等待接收方对这批数据的回应,然后再发送下一批数据. Nagle 算法适用于发送方需要发送大批量数据, 并且接收方会及时作出回应的场合, 这种算法通过减少传输数据的次数来提高通信效率. ## 接收方原因 ## TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，**如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度**，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。 # 三、 什么时候需要处理粘包现象？ # 如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象 **如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了。** # 四、如何处理粘包现象？ # （1）发送方 对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP\_NODELAY选项来关闭算法。 （2）接收方 接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。 （2）应用层 应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。 解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？ 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。 # 五、UDP不会产生粘包问题 # TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是**无保护消息边界**的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。 UDP则是面向消息传输的，是**有保护消息边界**的，接收方一次只接受一条独立的信息，所以不存在粘包问题。 UDP不存在粘包问题，是由于UDP发送的时候，没有经过Negal算法优化，不会将多个小包合并一次发送出去。另外，在UDP协议的接收端，采用了链式结构来记录每一个到达的UDP包，这样接收端应用程序一次recv只能从socket接收缓冲区中读出一个数据包。也就是说，发送端send了几次，接收端必须recv几次（无论recv时指定了多大的缓冲区）。 举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。 # 六、TCP拆包 # 这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的 ![在这里插入图片描述][20200205223554718.png] ![在这里插入图片描述][20200205223604553.png] **发生拆包的原因：** * 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。 * 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。 TCP拆包同样可以通过添加边界信息或者数据包长度信息来解决 [20200205222248103.png]: https://img-blog.csdnimg.cn/20200205222248103.png [20200205222148531.png]: https://img-blog.csdnimg.cn/20200205222148531.png [20200205223554718.png]: https://img-blog.csdnimg.cn/20200205223554718.png [20200205223604553.png]: https://img-blog.csdnimg.cn/20200205223604553.png
还没有评论，来说两句吧...