Socket TCP粘包拆包

TCP(transport control protocol,传输控制协议)是面向连接的,面向流的,提供高可靠性服务。收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。即面向流的通信是无消息保护边界的

UDP(user datagram protocol,用户数据报协议)是无连接的,面向消息的,提供高效率服务。不会使用块的合并优化算法,, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的

由于TCP无消息保护边界, 需要在消息接收端处理消息边界问题。也就是为什么我们以前使用UDP没有此问题。反而使用TCP后,出现少包的现象。


粘包拆包分析

具体分析一下,少包,多包的情况。

正常情况,发送及时每消息发送,接收也不繁忙,及时处理掉消息。像UDP一样.

Socket TCP粘包拆包_第1张图片

发送粘包,多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包. 这种情况和客户端处理繁忙,接收缓存区积压,用户一次从接收缓存区多个数据包的接收端处理一样。



发送粘包或接收缓存区积压,但用户缓冲区大于接收缓存区数据包总大小。此时需要考虑处理一次处理多数据包的情况,但每个数据包都是完整的。



发送粘包或接收缓存区积压, 用户缓存区是数据包大小的整数倍。此时需要考虑处理一次处理多数据包的情况,但每个数据包都是完整的。



发送粘包或接收缓存区积压, 用户缓存区不是数据包大小的整数倍。此时需要考虑处理一次处理多数据包的情况,同时也需要考虑数据包不完整。



粘包拆包发生原因

Socket TCP粘包拆包_第2张图片


  • 应用程序write写入的字节大小 大于 套接字发送缓冲区大小
  • 进行MSS大小的TCP分段
  • 以太网桢的paylaod大于MTU进行IP分片


解决粘包拆包

如何应对

  • 不是所有的粘包都需要处理。 我们先列举一下,免得在编码过程中,因为知道了粘包的情况下,都处理粘包。
  • 连续的数据流不需要处理。如一个在线视频,它是一个连续不断的流, 不需要考虑分包。 
  • 每发一个消息,建一次连接的情况。 
  • 发送端使用了TCP强制数据立即传送的操作指令push。 
  • UDP, 前面已说明白了。在这在强调一下,UDP不需要处理,免的忘记了。

你可能感兴趣的:(网络编程,IO)