粘包和拆包是TCP网络编程中不可避免的，无论是服务端还是客户端，当我们读取或者发送消息的时候，都需要考虑TCP底层的粘包/拆包机制。TCP是个“流”协议，所谓流，就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。
如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。
如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就形成了拆包问题。
如图所示，假设客户端分别发送了两个数据包msg1和msg2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下4种情况。
2、 代码复现粘包/拆包问题
客户端
服务端
问题:服务端一次读取了客户端发送过来的消息,应该读取10次. 因此发生粘包。
3、粘包拆包解决方案
3.1业内解决方案
由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，可以归纳如下：
1.消息长度固定，累计读取到长度和为定长LEN的报文后，就认为读取到了一个完整的信息。
2.将换行符作为消息结束符。
3.将特殊的分隔符作为消息的结束标志，回车换行符就是一种特殊的结束分隔符。
4.通过在消息头中定义长度字段来标识消息的总长度。
3.2 Netty解决粘包拆包方案
1.固定长度的拆包器 FixedLengthFrameDecoder，每个应用层数据包的都拆分成都是固定长度的大小。
2.行拆包器 LineBasedFrameDecoder，每个应用层数据包，都以换行符作为分隔符，进行分割拆分。
3.分隔符拆包器 DelimiterBasedFrameDecoder，每个应用层数据包，都通过自定义的分隔符，进行分割拆分。
4.基于数据包长度的拆包器 LengthFieldBasedFrameDecoder，将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度。
3.3 代码实现
1.使用LineBasedFrameDecoder解决粘包问题，其会根据"\n"或"\r\n"对二进制数据进行拆分
客户端:添加换行符
服务端:添加LineBasedFrameDecoder解码器
运行结果:发送了10次，也读取了10次，解决了粘包的问题
2.使用DelimiterBasedFrameDecoder解码器，以特殊的符号作为分隔来进行数据包的解码
服务端:
3. 使用FixedLengthFrameDecoder解码器，使用固定长度处理消息
服务端:
4.使用LenghtFieldBasedFrameDecode解码器
服务端:
1024 是最大帧长度，0 是长度字段的偏移量，2 是长度字段的长度，0 是长度调整值，2 是初始需要去掉的字节数。这样就可以正确地解码出数据帧了。
4、总结
造成TCP协议粘包/拆包问题的原因是TCP协议数据传输是基于字节流的，它不包含消息、数据包等概念，是无界的，需要应用层协议自己设计消息的边界，即消息帧（Message Framing）。如果应用层协议没有使用基于长度或者基于分隔符（终结符）划分边界等方式进行处理，则会导致多个消息的粘包和拆包。
