1.OSI&TCP/IP参考模型
2.TCP粘包/拆包
TCP是一个面向连接的字节流数据传输控制协议，没有自动插入记录标志或消息边界，TCP并不解读字节流里的字节内容，而是将数据放入接收缓冲区；
1)粘包/拆包现象
假设发送端向接收端连续发送了2个数据报：
-
无粘包/拆包：接收端分两次读取，正常获得两个独立的数据包；
-
粘包：接收端只接受到一个数据包，由于TCP不会出现丢包，所以该数据包包含了发送端发送的2个数据包信息；
-
拆包：接收端接受到了2个数据包，但是这两个数据包要么不完整，要么多出了另一个数据包的部分信息；
(上述图片来源于https://blog.csdn.net/scythe666/article/details/51996268)
2）为什么会出现粘包/拆包？ 待发送的数据大于TCP发送缓冲区可用空间大小，将会发生拆包；
待发送数据大于MSS(最大报文长度)，即TCP报文长度-TCP头部长度>MSS，TCP将在传输前进行拆包；
待发送数据小于SMSS，且存在在传数据(已发送未确认)，由于Nagle算法，这些小的报文段不能被发送，直到所有在传数据都收到ACK后，TCP将收集这些小的报文段，将其整合到一个报文段中发送，从而发送粘包；
接收端的应用层没有及时读取接收缓冲区中的数据，发生粘包；
3）怎么解决粘包/拆包？
- 使用TCP_NODELAY关闭Nagle算法，解决由于发送端Nagke算法导致的粘包；
- 消息定长，空格补位；
- 设置边界，添加特殊符号，如包尾添加回车换行符(FTP)；
- 将消息分为消息头和消息体，消息头中包含消息长度；
Netty提供了不同方法来处理粘包和拆包：
- DelimiterBasedFrameDecoder 基于设置消息边界方式进行粘包/拆包处理；
- FixedLengthFrameDecoder 基于固体长度消息进行粘包/拆包处理；
- LengthFieldBasedFrameDecoder 基于消息头指定消息长度进行粘包/拆包处理；
- LineBasedFrameDecoder 基于换行符进行粘包/拆包处理。
工作原理是：依次遍历ByteBuf中的可读字节，判断是否有"/n"或者"/r/n"，如果有，就以此位置为结束位置，从可读索引到结束位置区间的字节就组成了一行。是以换行符为结束标志的解码器，支持携带结束符或者不携带结束符两种解码方式，同时支持配置单行最大长度，若连续读取到最大长度仍然没有发现换行符，则抛出异常；
