TCP粘包&拆包问题与Netty解决方案

什么是粘包与拆包

TCP是流式协议，业务上的数据可能被TCP拆分成多个包进行发送，下面是TCP传输过程中可能出现的数据包状态：第一行包数据隔离较好，第二行为粘包，第三行未拆包，第四行是D2与D1的部分组成了新包。



（图片来自Netty权威指南）

产生的原因

1. 应用程序write的字节大小大于套接口发送的数据缓冲区大小；

2. 进行MSS大小的TCP分段

最大报文段长度MSS选项是TCP协议定义的一个选项，MSS选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。

3. 以太网帧的payload大于MTU进行的IP分片

最大传输单元（Maximum Transmission Unit，MTU）是指一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位）

以以太网传送IPv4报文为例。MTU表示的长度包含IP包头的长度，如果IP层以上的协议层发送的数据报文的长度超过了MTU，则在发送者的IP层将对数据报文进行分片，在接收者的IP层对接收到的分片进行重组。

举一个具体的例子说明IP包分片的原理。以太网的MTU值是1500 bytes，假设发送者的协议高层向IP层发送了长度为3008 bytes的数据报文，则该报文在添加20 bytes的IP包头后IP包的总长度是 3028 bytes，因为3028 > 1500，所以该数据报文将被分片，分片过程如下：

1. 首先计算最大的IP包中IP净荷的长度 =MTU-IP包头长度=1500-20= 1480 bytes。

2. 然后把3028 bytes按照1480 bytes的长度分片，将要分为3片，3028= 1480+1480+68。

3. 最后发送者将为3个分片分别添加IP包头，组成3个IP包后再发送，3个IP包的长度分别为1500 bytes、1500 bytes和 88 bytes。

业界主流的解决方案

消息定长，若长度不够空格补位；

包未添加回车换行符的字符（FTP协议）

消息包含消息头和消息体，消息头包含消息体长度，如使用消息头的一个字节存放int32表示消息总长度；

更复杂的应用层协议；

Netty解决方案

ByteToMessageDecoder+MessageToMessageDecoder实现解码，两者接口，具体实现类可根据需要使用。

ByteToMessageDecoder常见实现类有

io.netty.handler.codec.FixedLengthFrameDecoder    固定长度拆包

io.netty.handler.codec.LineBasedFrameDecoder    行拆包

MessageToMessageDecoder常见有

io.netty.handler.codec.string.StringDecoder

Demo

protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new FixedLengthFrameDecoder(4));
ch.pipeline().addLast(new StringDecoder());

}