粘包和拆包
粘包和拆包
-
产生粘包和拆包问题的主要原因是，操作系统在发送TCP数据的时候，底层会有一个缓冲区，例如1024个字节大小，如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。如下图展示了粘包和拆包的一个示意图
-
-
1.图一是正常的情况下包的发送和接受，客户端发送p1，p2包，服务端先后接受到p1，p2包，没有发生粘包和拆包。
-
.图二是发生了拆包的现象。客户端发送p1，p2包，客户端对p1拆包分成p1_1和p1_2，服务端先后收到p1_1，p1_2和p2包。 拆包发生原因分2种情况：
-
发送的数据大于套接字缓冲区剩余大小。
发送的数据大于MTU(最大传输单元)大小。
在TCP通讯协议中TCP的每个包的头的长度都是固定的，总长度不能超过MTU(最大传输单元)，且数据长度不能超过MSS(MSS=MTU-20bytes(IP包头)-20bytes(TCP包头))。如果超过了MTU系统会进行拆包处理。以图二举个例子： -
假设MTU设置的长度为1500bytes则MSS为1460bytes。客户端发送了p1包数据大小2000bytes。系统判断总长度超过了MTU大小，需要拆包处理。拆成2个包p1_1和p1_2，p1_1的总长度=1460+20+20=1500，p1_2的总长度=2000-1460+20+20=580。
发送包p1_1和包p1_2。
-
-
3.图三是发生了粘包的现象。客户端发送p1，p2包，p1，p2包到达接收端的缓存，服务端应用读取缓存时无法区分p1，p2各自的大小。因为在TCP通讯协议中TCP是面向流的，包和包之间没有界限。粘包可发生在发送端也可发生在接收端以图三各举例子：
-
发送端原因导致的粘包，客户端在发送p1包时，先将p1包放入发送缓存，由于Nagle算法判断其发送的可用数据（去头数据）过小等待一小段时间，这时又发送了p2包，系统将p1和p2合成一个大包发送给服务端。服务端读到大包，无法区分p1和p2包。
接收端原因导致的粘包，服务端缓存接收到客户端发送的p1包，服务端应用未能及时读取缓存，此时服务端缓存又接收到客户端发送的p2包，服务端应用读取缓存，无法区分p1和p2包。
业务数据的大小<TCP 套接字缓冲区大小
- 如果需要写入的应用数据大于当前设置的TCP套接字缓冲区，则需要对应用数据进行分次写入。
SO_SNDBUF：发送缓冲区大小。
SO_RCVBUF：接收缓冲区大小。 - 应用首先将数据写入TCP套接字缓冲区，然后等待发送。默认情况下，多数操作系统支持动态调节SO_SNDBUF大小以进行自适应，但是如果有主动设置，则自动调节会失效。
2、MSS大小传输线制
- 标识TCP传往另一段的最大数据长度，建立连接时，双发通告自己允许的MSS（只能出现在SYN报文中）。
3、MTU大小限制
- 网路中主机之间的MTU不是一个常数，取决于所选择的路由，而且路径不一定对称（A到B的选路，B到A的选路）.
- 因为每一次发送报文都会包含IP及TCP首部，所以，发送的报文段越大，效率越高，但是以不发生报文分段及双方都接受为基础。否则以较小的MTU发送。
UDP不存在粘包和拆包问题。
- 将消息分为消息头和消息尾两部分，消息头指定数据长度，根据消息长度来读取完整的消息。例如UDP协议是这么设计的，用两个字节来表示消息长度，所以UDP不存在粘包和拆包问题。
