四、使用包定长FixedLengthFrameDecoder解决半包粘包
4.1 试验
由于客户端发给服务器端的是hello server,im a client字符串,该字符串占用24字节,所以在服务器端channelpipeline里面添加一个长度为24的定长解码器和二进制转换为string的解码器:
然后修改NettyServerHandler的channelRead如下:
由于服务器发给客户端的是hello client ,im server字符串,该字符串占用23字节,所以在客户端端channelpipeline里面添加一个长度为23的定长解码器和二进制转换为string的解码器:
然后修改NettyClientHandler的channelRead如下:
然后重新启动服务器客户端,结果如下:
服务器端结果:
----Server Started----
--- accepted client---
0receive client info: hello server,im a client
send info to client:hello client ,im server
1receive client info: hello server,im a client
send info to client:hello client ,im server
2receive client info: hello server,im a client
send info to client:hello client ,im server
3receive client info: hello server,im a client
send info to client:hello client ,im server
4receive client info: hello server,im a client
send info to client:hello client ,im server
5receive client info: hello server,im a client
send info to client:hello client ,im server
6receive client info: hello server,im a client
send info to client:hello client ,im server
7receive client info: hello server,im a client
send info to client:hello client ,im server
8receive client info: hello server,im a client
send info to client:hello client ,im server
9receive client info: hello server,im a client
send info to client:hello client ,im server
客户端结果:
--- client already connected----
0receive from server:hello client ,im server
1receive from server:hello client ,im server
2receive from server:hello client ,im server
3receive from server:hello client ,im server
4receive from server:hello client ,im server
5receive from server:hello client ,im server
6receive from server:hello client ,im server
7receive from server:hello client ,im server
8receive from server:hello client ,im server
9receive from server:hello client ,im server
可知使用FixedLengthFrameDecoder已经解决了半包粘包问题。
4.2 FixedLengthFrameDecoder的原理
顾名思义是使用包定长方式来解决粘包半包问题,假设服务端接受到下面四个包分片:
那么使用FixedLengthFrameDecoder(3)会将接受buffer里面的上面数据解码为下面固定长度为3的3个包
FixedLengthFrameDecoder是继承自 ByteToMessageDecoder类的,当服务器接受buffer数据就绪后会调用ByteToMessageDecoder的channelRead方法进行读取,下面我们从这个函数开始讲解:
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
//4.2.1
if (msg instanceof ByteBuf) {
CodecOutputList out = CodecOutputList.newInstance();
try {
...
//4.2.2
callDecode(ctx, cumulation, out);
} catch (DecoderException e) {
throw e;
} catch (Throwable t) {
throw new DecoderException(t);
} finally {
...
}
} else {
//4.2.3
ctx.fireChannelRead(msg);
}
}
如上代码4.2.2具体是方法callDecode进行数据读取的,其代码如下:
protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List
如上代码callDecode中4.2.4是使用循环进行读取,这是因为可能出现粘包情况,使用循环可以逐个对单包进行处理。
其中4.2.4.1判断如果读取了包则调用fireChannelRead激活channelpipeline里面的其它handler的channelRead方法,因为这里,FixedLengthFrameDecoder只是channelpipeline中的一个handler。
代码4.2.4.2的decodeRemovalReentryProtection方法作用是调用FixedLengthFrameDecoder的decode方法具体从接受buffer读取数据,后者代码如下:
protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List
如上代码4.2.6如果发现接受buffer里面的字节数小于我们设置的固定长度frameLength则说明出现了半包情况,则直接返回null;否者读取固定长度的字节数。
然后执行代码4.2.4.3,其判断outSize == out.size()说明代码4.2.6没有读取一个包(说明出现了半包),则看当前buffer缓存的字节数是否变化了,如果没有变化则结束循环读取,如果变化了则可能之前的半包已经变成了全包,则需要再次调用4.2.6进行读取判断。
代码4.2.4.4判断是否只需要读取单个包(默认false),如果是则读取一个包后就跳出循环,也就是如果出现了粘包现象,在一次channelRead事件到来后并不会循环读取所有的包,而是读取最先到的一个包,那么buffer里面剩余的包要等下一次channelRead事件到了时候在读取。
最后
想了解JDK NIO和更多Netty基础的可以单击我
想了解更多关于粘包半包问题单击我
更多关于分布式系统中服务降级策略的知识可以单击 单击我
想系统学dubbo的单击我
想学并发的童鞋可以 单击我