目录
参考:
https://www.cnblogs.com/kex1n/p/6502002.html
粘包
发送方发送的若干数据包到接收方接收时粘成一个包,从接收缓冲区看,后一包数据的头紧接着前一包的数据的尾。粘包的原因有可能是发送方也有可能是接收方导致的。
粘包出现原因
简单得说,在流传输中出现,UDP不会出现粘包,因为它有消息边界(参考Windows网络编程)
1发送端需要等缓冲区满才发送出去,造成粘包
2接收方不及时接收缓冲区的包,造成多个包接收
具体点:
(1)发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少,通常TCP会根据优化算法把这些数据合成一包后一次发送出去,这样接收方就收到了粘包数据。
(2)接收方引起的粘包是由于接收方用户进程不及时接收数据,从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区,用户进程从该缓冲区取数据,若下一包数据到达时前一包数据尚未被用户进程取走,则下一包数据放到系统接收缓冲区时就接到前一包数据之后,而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据,这样就一次取到了多包数据。
粘包情况有两种,一种是粘在一起的包都是完整的数据包,另一种情况是粘在一起的包有不完整的包。
不是所有的粘包现象都需要处理,若传输的数据为不带结构的连续流数据(如文件传输),则不必把粘连的包分开(简称分包)。但在实际工程应用中,传输的数据一般为带结构的数据,这时就需要做分包处理。
在处理定长结构数据的粘包问题时,分包算法比较简单;在处理不定长结构数据的粘包问题时,分包算法就比较复杂。特别是粘在一起的包有不完整的包的粘包情况,由于一包数据内容被分在了两个连续的接收包中,处理起来难度较大。实际工程应用中应尽量避免出现粘包现象。
为了避免粘包现象,可采取以下几种措施
(1)对于发送方引起的粘包现象,用户可通过编程设置来避免,TCP提供了强制数据立即传送的操作指令push,TCP软件收到该操作指令后,就立即将本段数据发送出去,而不必等待发送缓冲区满;
(2)对于接收方引起的粘包,则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施,使其及时接收数据,从而尽量避免出现粘包现象;
(3)由接收方控制,将一包数据按结构字段,人为控制分多次接收,然后合并,通过这种手段来避免粘包。
以上提到的三种措施,都有其不足之处。
(1)第一种编程设置方法虽然可以避免发送方引起的粘包,但它关闭了优化算法,降低了网络发送效率,影响应用程序的性能,一般不建议使用。
(2)第二种方法只能减少出现粘包的可能性,但并不能完全避免粘包,当发送频率较高时,或由于网络突发可能使某个时间段数据包到达接收方较快,接收方还是有可能来不及接收,从而导致粘包。
(3)第三种方法虽然避免了粘包,但应用程序的效率较低,对实时应用的场合不适合。
一种比较周全的对策是:接收方创建一预处理线程,对接收到的数据包进行预处理,将粘连的包分开。对这种方法我们进行了实验,证明是高效可行的。
TCP是面向连接的,TCP的socket编程,收发两端(客户端和服务端)都要有成对的socket,因此,发送端为了将多个发往接收端的包更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小、数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端就很难分辨,必须提供科学的拆包机制。
对于数据传输频繁的程序来说,使用TCP可能会容易粘包。对于接收端程序来说,如果机器负荷很重,也会在接收缓冲里粘包。这样就需要接收端额外拆包,增加了工作量。
消息保护边界
传输协议把数据当作一条独立的消息在网上传输,接收端只能接收独立的消息。即如果存在消息保护边界,接收端一次只能接收发送端发送的一个数据包。
TCP基于流式传输,没有消息保护边界。它把数据当作一串数据流,如果发送端连续发送数据,接收端有可能再一次接收动作中,会接收两个或者更多的数据包。
如果连续发送3个数据包,大小分别是2k,4k,8k。如果使用UDP协议,不管用多大的接收缓冲区去接收数据,都必须有三次接收动作,才能够把数据报接收完。而使用TCP协议,只需要把接收端缓冲区大小设置在14k以上,就能一次把所有的数据包接收下来,只需要一次接收动作。