转载自 https://www.cnblogs.com/quqinchao/p/9290646.html 如有侵权 联系删除
1 tcp有粘包及udp无粘包
- TCP 是面向连接的，面向流的可靠协议；发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，
合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制面向流的通信是无消息保护边界的。 - UDP(用户数据报协议)是无连接的，面向消息的，提供高效率服务。不会使用块的合并优化算法，, 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来
记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
注：tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，
而udp是基于数据报的，即便是你输入的是空内容（直接回车），那也不是空消息，udp协议会帮你封装上消息头
2 产生原因：
1、接收端不知道消息的界限，不知道一次提取多少字节数据
2、TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，
通常TCP会根据优化算法(Nagle算法)把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据
产生粘包场景：(1)发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据了很小，会合到一起，产生粘包）
(2)接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）
3 解决方案
为字节流加上自定义固定长度报头，报头中包含字节流长度，然后一次send到对端，对端在接收时，先从缓存中取出定长的报头，然后再取真实数据
本质上是要在应用层维护消息与消息的边界（下文的“包”可以认为是“消息”）
1、定长包
2、包尾加\r\n（ftp）
3、包头加上包体长度
4、更复杂的应用层协议
