今天是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处理消息。
现在客户端发送了十个消息对象，为了方便看问题，加一个计数器统计消息的数量：
刚好十条。
如果粘包或者拆包的话，就不会打印出十条消息数量，如这种情况：
