什么是粘包?
在学习粘包之前，先纠正一下读音，很多视频教程中将“粘”读作“nián”。经过调研，个人更倾向于读“zhān bāo”。
如果在百度百科上搜索“粘包”，对应的读音便是“zhān bāo”，语义解释为：网络技术术语。指TCP协议中，发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
TCP是面向字节流的协议，就是没有界限的一串数据，本没有“包”的概念，“粘包”和“拆包”一说是为了有助于形象地理解这两种现象。
为什么UDP没有粘包?
粘包拆包问题在数据链路层、网络层以及传输层都有可能发生。日常的网络应用开发大都在传输层进行，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。
粘包拆包发生场景
因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。
如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。
如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。
关于粘包和拆包可以参考下图的几种情况：
上图中演示了以下几种情况：
- 正常的理想情况，两个包恰好满足TCP缓冲区的大小或达到TCP等待时长，分别发送两个包;
- 粘包：两个包较小，间隔时间短，发生粘包，合并成一个包发送;
- 拆包：一个包过大，超过缓存区大小，拆分成两个或多个包发送;
- 拆包和粘包：Packet1过大，进行了拆包处理，而拆出去的一部分又与Packet2进行粘包处理。
常见的解决方案
对于粘包和拆包问题，常见的解决方案有四种：
- 发送端将每个包都封装成固定的长度，比如100字节大小。如果不足100字节可通过补0或空等进行填充到指定长度;
- 发送端在每个包的末尾使用固定的分隔符，例如rn。如果发生拆包需等待多个包发送过来之后再找到其中的rn进行合并;例如，FTP协议;
- 将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息;
- 通过自定义协议进行粘包和拆包的处理。
Netty对粘包和拆包问题的处理
Netty对解决粘包和拆包的方案做了抽象，提供了一些解码器(Decoder)来解决粘包和拆包的问题。如：
- LineBasedFrameDecoder：以行为单位进行数据包的解码;
- DelimiterBasedFrameDecoder：以特殊的符号作为分隔来进行数据包的解码;
- FixedLengthFrameDecoder：以固定长度进行数据包的解码;
- LenghtFieldBasedFrameDecode：适用于消息头包含消息长度的协议(最常用);
基于Netty进行网络读写的程序，可以直接使用这些Decoder来完成数据包的解码。对于高并发、大流量的系统来说，每个数据包都不应该传输多余的数据(所以补齐的方式不可取)，LenghtFieldBasedFrameDecode更适合这样的场景。
TCP协议粘包拆包问题是因为TCP协议数据传输是基于字节流的，它不包含消息、数据包等概念，需要应用层协议自己设计消息的边界，即消息帧(Message Framing)。如果应用层协议没有使用基于长度或者基于终结符息边界等方式进行处理，则会导致多个消息的粘包和拆包。
虽然很多框架中都有现成的解决方案，比如Netty，但底层的原理我们还是要清楚的，而且还要知道有这么回事，才能更好的结合场景进行使用。
首先粘包产生原因：
先说TCP：由于TCP协议本身的机制（面向连接可靠的协议，三次握手四次挥手）客户段与服务端会建立一个链接，数据在链接不断开的情况下，可以持续不断地将多个数据包发往服务端，相当于一个流，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（当然是可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些，因为需要合并延时发送）然后再发送（超时或者包大小足够）。这样的话，服务端在接收到消息（数据流）的时候就无法区分哪些数据包是客户端自己分开发送的，这样产生了粘包；还有一种情况，服务端在接收到数据后，然后放到缓冲区中，如果消息没有被及时从缓存区取走，下次在取数据的时候可能就会出现一次取出多个数据包的情况，造成粘包现象（确切来讲，对于基于TCP协议的应用，不应用包来描述，而应该用流的概念来描述），个人认为接收端产生的粘包应该与linux内核处理socket的方式 select/poll轮询机制的线性扫描频度或者跟epoll无关。
再说UDP：本身作为无连接的不可靠的传输协议（适合频繁发送较小的数据包），他不会对数据包进行合并发送（也就没有Nagle算法之说了），他直接是一端发送什么数据，直接就发出去了，既然他不会对数据合并，每一个数据包都是完整的（数据 UDP头 IP头等等发一次数据封装一次）也就没有粘包一说了。
分包产生的原因就简单的多：可能是IP分片传输导致的，也可能是传输过程中丢失部分包导致出现的半包，还有可能就是一个包可能被分成了两次传输，在取数据的时候，先取到了一部分（还可能与接收的缓冲区大小有关系），总之就是一个数据包被分成了多次接收。
解决办法：
粘包与分包的处理方法：
我根据现有的一些开源资料做了如下总结（常用的解决方案）：
一个是采用分隔符的方式，即我们在封装要发送的数据包的时候，采用固定的字符作为结尾符（数据中不能含结尾符），这样我们接收到数据包后，如果出现结尾标识，即人为的将粘包分开，如果一个包中没有出现结尾符，认为出现了分包，则等待下个包中出现后 组合成一个完整的数据包，这种方式适合于文本传输的数据，如采用/r/n之类的分隔符；
另一种是采用在数据包中添加长度的方式，即在数据包中的固定位置封装数据包的长度信息（或可计算数据包总长度的信息），服务器接收到数据后，先是解析包长度，然后根据包长度截取数据包（此种方式常出现于自定义协议中），但是有个小问题就是如果客户端第一个数据包数据长度封装的有错误，那么很可能就会导致后面接收到的所有数据包都解析出错（由于TCP建立连接后流式传输机制），只有客户端关闭连接后重新打开才可以消除此问题，我在处理这个问题的时候对数据长度做了校验，会适时的对接收到的有问题的包进行人为的丢弃处理（客户端有自动重发机制，故而在应用层不会导致数据的不完整性）；
另一种不建议的方式是TCP采用短连接处理粘包（这个得根据需要来，所以不建议）；
