Tcp是个“流协议”，所谓流，就是没有界限的一连串数据，没有界限。TCP底层不了解业务数据的含义，它会根据TCP缓冲区的实际情况进行包的划分，所以业务上认为，一个完整的包可能被TCP拆分为多个包进行发送，也可能把多个小包封装成一个大的数据包进行发送，这就是所谓的TCP粘包和拆包问题。
粘包/拆包问题说明
image
假设客户端分别发送了两个数据包，D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下情况：
服务端分别收到了D1和D2，没有粘包和拆包
服务端一次性收到了D1和D2，称为TCP粘包
服务端两次读取到了两个数据包，第一次读到了D1的完整部分和D2的部分数据，第二次读到了D2的剩余部分。 这称为TCP拆包
服务端两次读取到两个数据包，第一次是D1的部分，第二次是D1的剩余部分和D2的完整部分
也有可能D1和D2非常大，期间发生多次拆包。
粘包/拆包原因
- 应用程序write写入的字节大小大于套接口缓冲区的大小
- 进行MSS大小的TCP分段
- 以太网帧的payload大于MTU进行IP分片
image
粘包问题解决方案
由于底层无法理解上层的业务数据，所以底层是无法保证数据不被拆分和重组的。只能通过设计上层的协议栈来解决，业界的方案可归纳如下：
- 消息定长，例如每个报文固定200字节，如果不够，空位补空格
- 在包尾增加回车换行符进行分割，如FTP协议
- 将消息分为消息头和消息体，消息头中包含消息的长度，字段等信息
- 更复杂的应用层协议
最后
在学习Netty，这里摘抄《Netty权威指南》
