Netty的拆包与粘包简介

TCP的粘包/拆包问题

不管是服务端仍是客户端，当咱们读取或者发送消息的时候，都须要考虑TCP底层的粘包/拆包机制。 TCP是一个“流”协议，所谓流，就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，他会根据TCP缓冲区的实际状况进行包的划分，因此在业务上认为，一个完整的包可能被TCP拆分红多个包进行发送，也可能把多个小的包封装成一个大的数据包发送，这就是所谓的粘包和拆包问题

TCP粘包/拆包问题发生的缘由

问题产生的缘由有三个，以下：

• 应用程序write写入的字节大于套接口发送缓冲区的大小
• 进行MSS大小的TCP分段
• 以太网帧的payload大于MTU进行IP分片

---

粘包问题的解决策略

TCP以流的方式进行数据传输，因为底层TCP没法理解上层的业务数据，因此在底层是没法保证数据包不被拆分和重组的，这个问题只能经过上层的应用协议栈设计来解决，上层的应用协议为了对消息进行区分，业界主流的解决方案能够概括以下：

• 消息固定长度，累计读取到长度总和为定长LEN的报文后，就认为读取到了一个完整的消息，若是不够，空位补空格；将计数器置位，从新开始读取下一个数据
• 将回车换行符做为消息结束符，例如FTP协议，这种方式在文本协议中应该比较普遍
• 将特殊的分隔符做为消息结束标志，回车换行符就是一种特殊的结束分隔符
• 经过在消息头中定义长度字段来标识消息的总长度
• 更复杂的应用层协议

---

Netty处理粘包/拆包问题

Netty对上面的前四种应用作了统一的抽象，提供了Decoder来解决对应的问题，使用起来很是方便。有了这些Decoder，用户不须要对本身读取的报文进行人工解码，也不须要考虑TCP的粘包和拆包。Decoder以下：

• LineBasedFrameDecoder
• StringDecoder
• DelimiterBasedFrameDecoder
• FixedLengthFrameDecoder

参考文献：《Netty权威指南》