《Netty权威指南》笔记 —— 第四章, 第五章

第4章 TCP粘包/拆包问题的解决之道

TCP 粘包/拆包

一个完整会被TCP会根据TCP缓冲区的实际情况进行包的划分

四种情况

假设发送两个数据包 D1, D2给服务端, 会出现4种情况:

1. 分两次读取了两个独立的数据包, D1和D2
2. 一次收两个, D1和D2粘合在一起, TCP粘包
3. 服务器分两次读取到了两个数据报,
   1. 读取了完整的 D1 和 部分D2
   2. 第二次读取了D2包的剩余内容, TCP拆包
4. 两次读取到了两个数据包,
   1. D1包的部分内容
   2. D1的剩余内容 和 D2包的整包
      也有可能多次拆包

发生原因

1. Write写入的字节大小大于套接口发送缓冲区大小
2. 进行MSS大小的TCP分段
3. 以太网帧的payload大于MTU进行IP分片
   

解决方式

1. 消息定长
2. 在包尾增加回车换行符进行分割, 例如FTP协议
3. 消息分头和体, 消息头包含消息总长度
4. 更复杂的应用层协议

利用LineBasedFrameDecoder解决TCP粘包问题

Netty默认提供了多种编码器用于处理半包.
在TimeClientHandler之前新增了LineBasedFrameDecoder 和 StringDecoder解码器. 通过使用LineBasedFrameDecoder和StringDecoder成功解决了TCP粘包导致的读半包问题.

LineBasedFrameDecoder 和 StringDecoder的原理

LineBasedFrameDecoder 依次遍历ByteBuf中刻度字节(类似换行符), 有则代表结束.
StringDecoder 将接收到的对象转换成字符串, 然后继续调用后面的Handler.
加起来两样东西,其实就是按行切换的文本解码器, 拿来支持TCP的粘包和拆包.

第5章 分隔符和定长解码器的应用

TCP以流的方式进行数据传输, 上层的应用协议为了对消息进行区分

1. 消息长度固定, 累计读取到长度综合为定长LEN的报文后, 就认为读取到了一个完整的消息; 将计数器置位, 重新开始读取下一个数据报
2. 将回车换行符作为消息结束符, 例如FTP协议, 这种方式在文本协议中应用比较广泛
3. 将特殊的分隔符作为消息的结束标志, 回车换行符就是一种特殊的结束分隔符
4. 通过消息头定义长度字段来表示消息的总长度

DelimiterBasedFrameDecoder应用开发

自动完成以分隔符作为代码流结束标识的消息的解码

DelimiterBasedFrameDecoder 服务端

echoServer

// 首先创建分割符缓冲对象ByteBuf, 使用"$_"作为分隔符
ByteBuf delimiter = Unpooled.copiedBuffer