计算机网络之滑动窗口下产生的粘包问题及其解决方案

1、tcp有粘包及udp无粘包

• TCP 是面向连接的，面向流的可靠协议；发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据， 合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制面向流的通信是无消息保护边界的。

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

• 注：tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住

• 而udp是基于数据报的，即便是你输入的是空内容（直接回车），那也不是空消息，udp协议会帮你封装上消息头

2、产生原因

• 接收端不知道消息的界限，不知道一次提取多少字节数据
• TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，
• 通常TCP会根据优化算法(Nagle算法)把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据
• 产生粘包场景：
  • (1)发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据了很小，会合到一起，产生粘包）
  • (2)接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）

3、解决方案

• 为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据
• 本质上是要在应用层维护消息与消息的边界（下文的“包”可以认为是“消息”）
• 定长包
• 包尾加\r\n（ftp）
• 包头加上包体长度
• 更复杂的应用层协议