今天是2024年12月31日，今年的最后一天，希望所有的努力在新的一年会有回报。❀

无路可退，放弃很难，坚持很酷

TCP传输

是一种面向二进制的，流的传输。在传输过程中最大的问题是消息之间的边界不明确。而在服务端主要的问题就是读取TCP连接的时候，不确定一次会读到多少数据。

TCP会使用某些算法如Nagle，将多个量小，独立的数据包合并为一个报文段(大包)进行发送，以提高效率，而这些独立的数据之间没有明确的边界，服务端会出现几种情况：

假如报文段中有两个独立的数据包AB，较理想的情况是服务端分别读取到了这两个包[A]，[B]。

其次服务端把这两个包作为一个整体读取到了，此时这两个包成为一个整体状态[AB]，即粘包。

服务端读取到了整个A包，以及B包的一部分，此时就发生了拆包。

还可能会有其他原因，比如发送的数据包，超过了最大报文段的长度MSS(1460byte)，此时大包也会被拆包。

说到底都是因为TCP传输是基于字节流进行传输的，不会维护消息之间的边界。

解决方案：

自定义消息传输协议，在消息前加一个长度，服务端按长度读取。

自定义一个消息传输的协议对象，后续的编解码都基于此

配置服务端，客户端启动：依旧是按照Netty那套模型来....省略

主要是需要自定义一个编解码器，因为传输的是自定义的对象，而Netty默认的channelHandler只会传输字节流数据。需要手动编解码进行处理。

出站编码器：

write方法会将对象数据以字节的形式写入byteBuf并发送

（编码器只会对规定的数据类型进行编码，类型外直接发送）

入站解码器：

解码器接收到的是字节流，将它转为消息对象。

readInt会先读取长度，再根据长度去读取字节内容

解码完成后通过list交给下一个handler处理

ReplayingDecoder 会自动缓存字节数据并管理读取指针。如果数据还没读取完，它会在下次调用 decode() 时继续从正确的位置读取，而你不需要手动管理指针的移动。无需手动判断readableBytes了，它会根据协议和读取的字节自动管理数据的边界

 Void 就是一个占位符，表示无需任何状态（如当前解码的消息长度、已读取的字节数等对象，可在后续解码过程中继续处理）来辅助解码过程。

将编码器以及处理器依次加入到channel的pipeLine中

双方处理流程： 

1，处理器发送消息对象，消息传递给下一个handler即编码器，编码为字节流然后网络发送。

2，解码器收到网络二进制消息流，解码为消息对象，传递给下一个handler处理消息。

现在客户端发送了十个消息对象，为了方便看问题，加一个计数器统计消息的数量：

刚好十条。

如果粘包或者拆包的话，就不会打印出十条消息数量，如这种情况：