前言

TCP是一个流协议，就是没有界限的一长串二进制数据。TCP作为传输层协议并不不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。面向流的通信是无消息保护边界的。

UDP：本身作为无连接的不可靠的传输协议（适合频繁发送较小的数据包），他不会对数据包进行合并发送（也就没有 Nagle 算法之说了），他直接是一端发送什么数据，直接就发出去了，既然他不会对数据合并，每一个数据包都是完整的（数据+UDP 头+IP 头等等发一 次数据封装一次）也就没有粘包一说了。

1、客户端要发送的数据小于TCP发送缓冲区的大小，TCP为了提升效率，将多个写入缓冲区的数据包一次发送出去，多个数据包粘在一起，造成粘包；

2、服务端的应用层没有及时处理接收缓冲区中的数据，再次进行读取时出现粘包问题；

3、数据发送过快，数据包堆积导致缓冲区积压多个数据后才一次性发送出去；

4、拆包一般由于一次发送的数据包太大，超过MSS的大小，那么这个数据包就会被拆成多个TCP报文分开进行传输。

发生粘包与半包现象的本质是因为 TCP 是流式协议，消息无边界。

解决方案

通过上文我们知道，底层的的TCP协议负责数据传输，它是无法理解上层的业务数据的具体语义的，所以在底层我们没有办法进行解决。那么我们只能通过上层的协议设计来解决粘包、拆包问题，主要有以下几种方法：

1、消息定长

客户端于服务器约定一个最大长度，保证客户端每次发送的数据长度都不会大于该长度。若发送数据长度不足则需要补齐至该长度。服务器接收数据时，将接收到的数据按照约定的最大长度进行拆分，即使发送过程中产生了粘包，也可以通过定长解码器将数据正确地进行拆分。服务端需要用到FixedLengthFrameDecoder对数据进行定长解码，具体使用方法如下

2、明确消息边界

行解码器的是通过分隔符对数据进行拆分来解决粘包半包问题的。

可以通过LineBasedFrameDecoder(int maxLength)来拆分以换行符(\n)为分隔符的数据，也可以通过DelimiterBasedFrameDecoder(int maxFrameLength, ByteBuf... delimiters)来指定通过什么分隔符来拆分数据（可以传入多个分隔符）。

两种解码器都需要传入数据的最大长度，若超出最大长度，会抛出TooLongFrameException异常。

3、长度字段解码器

在传送数据时可以在数据中添加一个用于表示有用数据长度的字段，在解码时读取出这个用于表明长度的字段，同时读取其他相关参数，即可知道最终需要的数据是什么样子的。

LengthFieldBasedFrameDecoder解码器可以提供更为丰富的拆分方法。