为什么TCP 会粘包
先来分析一下通信协议TCP/UDP：
TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
UDP（user datagram protocol，用户数据报协议）是无连接的，面向消息的，提供高效率服务。不会使用块的合并优化算法，, 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
由于TCP无消息保护边界, 需要在消息接收端处理消息边界问题。也就是为什么我们以前使用UDP没有此问题。 反而使用TCP后，出现少包的现象。
粘包的分析
上面说了原理，但可能有人使用TCP通信会出现多包/少包，而一些人不会。那么我们具体分析一下，少包，多包的情况。
- 正常情况，发送及时每消息发送，接收也不繁忙，及时处理掉消息。像UDP一样.
- 发送粘包,多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包. 这种情况和客户端处理繁忙，接收缓存区积压，用户一次从接收缓存区多个数据包的接收端处理一样。
- 发送粘包或接收缓存区积压，但用户缓冲区大于接收缓存区数据包总大小。此时需要考虑处理一次处理多数据包的情况，但每个数据包都是完整的。
- 发送粘包或接收缓存区积压， 用户缓存区是数据包大小的整数倍。 此时需要考虑处理一次处理多数据包的情况，但每个数据包都是完整的。
- 发送粘包或接收缓存区积压， 用户缓存区不是数据包大小的整数倍。 此时需要考虑处理一次处理多数据包的情况，同时也需要考虑数据包不完整。
我们的情况就属于最后一种，发生了数据包不完整的情况。
啰嗦了这么多，总结 一下， 就两种情况下会发生粘包。
- 发送端需要等缓冲区满才发送出去，造成粘包
- 接收方不及时处理接收缓冲区的包，造成多个包接收
如何应对
先卖个关子， 不是所有的粘包都需要处理。 我们先列举一下：
- 连续的数据流不需要处理。如一个在线视频，它是一个连续不断的流， 不需要考虑分包。
- 每发一个消息，建一次连接的情况。
- 发送端使用了TCP强制数据立即传送的操作指令push。
- UDP, 前面已说明白了。在这在强调一下，UDP不需要处理，免的忘记了。
一般所谓的TCP粘包是在一次接收数据不能完全地体现一个完整的消息数据。TCP通讯为何存在粘包呢？主要原因是TCP是以流的方式来处理数据，再加上网络上MTU的往往小于在应用处理的消息数据，所以就会引发一次接收的数据无法满足消息的需要，导致粘包的存在。处理粘包的唯一方法就是制定应用层的数据通讯协议，通过协议来规范现有接收的数据是否满足消息数据的需要。在应用中处理粘包的基础方法主要有两种分别是以4节字描述消息大小或以结束符，实际上也有两者相结合的如HTTP,redis的通讯协议等。
在平时交流过程发现一些朋友即使做了这些协议的处理，但有时在处理数据的时候也会出现数据不对的情况。这主要原因他们在一些个别情况下没有处理好。因为当一系列的消息发送过来的时候，对于4节字头或结束符分布位置都是不确定的。一种简单的情况就是当前消息处理完成后，紧接着就是处理一下个消息的4节字描述，但在实际情况下当前接收的buffer剩下的内容有可能不足4节字的。如果你想通过通讯的程序来测这情况相对来说触发的机率性不高，所以对于协议分析的功能最好通过单元测试来模拟。
另外在netty中主要也提供了上面描述的解决方案：
LineBasedFrameDecoder可以基于换行符解决。DelimiterBasedFrameDecoder可基于分隔符解决。FixedLengthFrameDecoder可指定长度解决。