《Netty权威指南》笔记——走进JavaNIO
第4章 TCP粘包/拆包问题的解决之道
TCP 粘包/拆包
一个完整会被TCP会根据TCP缓冲区的实际情况进行包的划分
四种情况
假设发送两个数据包 D1
, D2
给服务端, 会出现4种情况:
- 分两次读取了两个独立的数据包,
D1
和D2
- 一次收两个,
D1
和D2
粘合在一起, TCP粘包 - 服务器分两次读取到了两个数据报,
- 读取了完整的
D1
和 部分D2
- 第二次读取了
D2
包的剩余内容, TCP拆包
- 读取了完整的
- 两次读取到了两个数据包,
D1
包的部分内容D1
的剩余内容 和D2
包的整包
也有可能多次拆包
发生原因
- Write写入的字节大小大于套接口发送缓冲区大小
- 进行MSS大小的TCP分段
- 以太网帧的payload大于MTU进行IP分片
解决方式
- 消息定长
- 在包尾增加回车换行符进行分割, 例如FTP协议
- 消息分头和体, 消息头包含消息总长度
- 更复杂的应用层协议
利用LineBasedFrameDecoder解决TCP粘包问题
Netty默认提供了多种编码器用于处理半包.
在TimeClientHandler
之前新增了LineBasedFrameDecoder
和 StringDecoder
解码器. 通过使用LineBasedFrameDecoder
和StringDecoder
成功解决了TCP粘包导致的读半包问题.
LineBasedFrameDecoder 和 StringDecoder的原理
LineBasedFrameDecoder
依次遍历ByteBuf
中刻度字节(类似换行符), 有则代表结束.
StringDecoder
将接收到的对象转换成字符串, 然后继续调用后面的Handler.
加起来两样东西,其实就是按行切换的文本解码器, 拿来支持TCP的粘包和拆包.
第5章 分隔符和定长解码器的应用
TCP以流的方式进行数据传输, 上层的应用协议为了对消息进行区分
- 消息长度固定, 累计读取到长度综合为定长LEN的报文后, 就认为读取到了一个完整的消息; 将计数器置位, 重新开始读取下一个数据报
- 将回车换行符作为消息结束符, 例如FTP协议, 这种方式在文本协议中应用比较广泛
- 将特殊的分隔符作为消息的结束标志, 回车换行符就是一种特殊的结束分隔符
- 通过消息头定义长度字段来表示消息的总长度
DelimiterBasedFrameDecoder应用开发
自动完成以分隔符作为代码流结束标识的消息的解码
DelimiterBasedFrameDecoder 服务端
echoServer
// 首先创建分割符缓冲对象ByteBuf, 使用"$_"作为分隔符
ByteBuf delimiter = Unpooled.copiedBuffer