Netty是如何解决TCP的粘包和拆包问题的？ _netty

TCP是个“流协议”，所谓流，就是没有界限的一连串数据，没有界限。TCP底层不了解业务数据的含义，它会根据TCP缓冲区的实际情况进行包的划分，所以业务上认为，一个完整的包可能被TCP拆分为多个包进行发送，也可能把多个小包封装成一个大的数据包进行发送，这就是所谓的TCP粘包和拆包问题。
Netty如何解决TCP的粘包和拆包问题2. TCP粘包/拆包问题演示 3. Netty解决TCP粘包/拆包问题示例
1. TCP粘包/拆包介绍 1.1 什么是TCP粘包/拆包
为了更加清楚的介绍这个问题，我们使用一个实例来演示。
假设客户端向服务端发送两个数据包：第一个内容为 abc；第二个内容为edf 。
服务端接受一个数据并做相应的业务处理。为了简单起见，服务端将受到的内容添加星号*之后打印。
那么服务端输出结果将会出现下面四种情况：
服务端输出结果结论
abc* def*
正常接受，没有发生粘包/拆包
*
异常接受，发生粘包
abc* d* ef*
异常接受，发生拆包
ab* cdef*
异常接受，发生粘包和拆包
通过这个例子我们可以很好的了解TCP的粘包/拆包，本质上就是多次发送的数据之间发生重叠，或者单次发送的数据会发送拆分。
那为什么会发生这种情况呢？
1.2 TCP为什么会粘包/拆包
我们知道，TCP是以一种流的方式来进行网络转播的，当TCP三次握手简历通信后，客户端服务端之间就建立了一种通讯管道，我们可以想象成自来水管道，流出来的水是连城一片的，是没有分界线的。TCP底层并不了解上层的业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分。
所以对于我们应用层而言。我们直观是发送一个个连续完整TCP数据包的，而在底层就可能会出现将一个完整的TCP拆分成多个包发送或者将多个包封装成一个大的数据包发送。
具体来说，发生这种情况主要有以下三个原因：
1.3 如何解决
主流的协议解决方案可以归纳如下：

文章插图
2. TCP粘包/拆包问题演示
下面我们将基于Netty来演示一下TCP粘包/拆包问题出现的场景以及结果。我们针对服务端和客户端分别进行介绍。
2.1 服务端代码

package netty.frame.tcpzjb.error;import io.netty.bootstrap.ServerBootstrap;import io.netty.channel.ChannelFuture;import io.netty.channel.ChannelInitializer;import io.netty.channel.ChannelOption;import io.netty.channel.nio.NioEventLoopGroup;import io.netty.channel.socket.SocketChannel;import io.netty.channel.socket.nio.NioServerSocketChannel;/*** created by LMR on 2020/5/20*/public class TimeServer {public static void main(String[] args) throws Exception{int port = 8080;new TimeServer().bind(port);}public void bind(int port) throws Exception{//配置服务端NIO线程组NioEventLoopGroup bossGroup = new NioEventLoopGroup();NioEventLoopGroup workerGroup = new NioEventLoopGroup();try {ServerBootstrap serverBootstrap = new ServerBootstrap();serverBootstrap.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class).option(ChannelOption.SO_BACKLOG, 1024).childHandler(new ChildChannelHandler());//绑定端口，同步等待成功ChannelFuture f = serverBootstrap.bind(port).sync();//等待服务端监听端口关闭f.channel().closeFuture().sync();}finally {//优雅退出，释放资源bossGroup.shutdownGracefully();workerGroup.shutdownGracefully();}}private class ChildChannelHandler extends ChannelInitializer>{@Overrideprotected void initChannel(SocketChannel socketChannel) throws Exception {socketChannel.pipeline().addLast(new TimeServerHandler());}}}

是服务端的启动类，该类与博客中的代码相同，在这里就不进行介绍，下面主要介绍其中实现服务端处理的类。

package netty.frame.tcpzjb.error;import io.netty.buffer.ByteBuf;import io.netty.buffer.Unpooled;import io.netty.channel.ChannelHandlerContext;import io.netty.channel.ChannelInboundHandlerAdapter;/*** created by LMR on 2020/5/20*/public class TimeServerHandler extends ChannelInboundHandlerAdapter {private int counter;@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg)throws Exception {//将消息转为bufByteBuf buf=(ByteBuf) msg;//创建一个buf长度的数组byte [] requestbyte=new byte[buf.readableBytes()];buf.readBytes(requestbyte);String request=new String(requestbyte,"utf-8").substring(0, requestbyte.length - System.getProperty("line.separator").length());System.out.println("The time server receive order : " + request+ " ; the counter is : " + ++counter);String currentTime = "QUERY TIME ORDER".equalsIgnoreCase(request) ? newjava.util.Date(System.currentTimeMillis()).toString() : "BAD ORDER";currentTime = currentTime + System.getProperty("line.separator");//响应给客户端ByteBuf resBuf= Unpooled.copiedBuffer(currentTime.getBytes());ctx.writeAndFlush(resBuf);}@Overridepublic void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {ctx.close();}}

在中我们可以看到，服务端每读到一条消息，就计数一次，然后大宋消息给客户端。理论上来说，服务端受到的消息总数应该和客户端发送的数目相同，并且请求消息删除回车换行符后就不会换行。下面看看客户端的实现代码。
2.2 客户端代码
在这里我们就不再给出，客户端启动类代码，具体嗲吗可以见上一篇博客。下面给出客户端处理类的代码。

package netty.frame.tcpzjb.error;import io.netty.buffer.ByteBuf;import io.netty.buffer.Unpooled;import io.netty.channel.ChannelHandlerContext;import io.netty.channel.ChannelInboundHandlerAdapter;/*** created by LMR on 2020/5/20*/public class TimeClientHandler extends ChannelInboundHandlerAdapter {private int counter;private byte[] req;public TimeClientHandler(){req = "QUERY TIME ORDER".getBytes();}@Overridepublic void channelActive(ChannelHandlerContext ctx) throws Exception {ByteBuf message = null;for (int i = 0; i < 100; i++){message = Unpooled.buffer(req.length);message.writeBytes(req);ctx.writeAndFlush(message);}}@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {ByteBuf buf = (ByteBuf) msg;byte[] req = new byte[buf.readableBytes()];buf.readBytes(req);String body = new String(req, "UTF-8");System.out.println("Now is : " + body + " ; the counter is :" + ++counter);}@Overridepublic void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {ctx.close();}}

在上述代码中，当客户端与服务端建立连接之后，会向服务端发送100条消息，并且每次都会刷新，保证每条消息都会被写入中，理论上服务端会受到100条请求查询事件的请求消息。当客户端接收到服务器端的响应消息之后，就会打印一次计数器，理论上来说客户端会打印100次时间。下面我们来看看实际的运行结果。
2.3 运行结果
服务端运行结果：
客户端运行结果：
从上述结果可以看出，服务端收到了61条消息，但没有一条是查询时间的指令。客户端实际上也只接受到了3条从服务端返回的指令。
正是由于我们的程序没有考虑TCP的粘包/拆包问题，才会导致实际结果与理论上不符合。那么下面我们给出正确的代码。
3. Netty解决TCP粘包/拆包问题示例
为了解决TCP粘包/拆包问题，Netty提供了多种编码器，在本节中我们将利用Netty中的r和来解决上面出现的问题，我们同样分服务端和客户端介绍。
3.1 服务端代码

package netty.frame.tcpzjb.right;import io.netty.bootstrap.ServerBootstrap;import io.netty.channel.ChannelFuture;import io.netty.channel.ChannelInitializer;import io.netty.channel.ChannelOption;import io.netty.channel.nio.NioEventLoopGroup;import io.netty.channel.socket.SocketChannel;import io.netty.channel.socket.nio.NioServerSocketChannel;import io.netty.handler.codec.LineBasedFrameDecoder;import io.netty.handler.codec.string.StringDecoder;/*** created by LMR on 2020/5/20*/public class TimeServer {public static void main(String[] args) throws Exception{int port = 8080;new TimeServer().bind(port);}public void bind(int port) throws Exception{//配置服务端NIO线程组NioEventLoopGroup bossGroup = new NioEventLoopGroup();NioEventLoopGroup workerGroup = new NioEventLoopGroup();try {ServerBootstrap serverBootstrap = new ServerBootstrap();serverBootstrap.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class).option(ChannelOption.SO_BACKLOG, 1024).childHandler(new ChildChannelHandler());//绑定端口，同步等待成功ChannelFuture f = serverBootstrap.bind(port).sync();//等待服务端监听端口关闭f.channel().closeFuture().sync();}finally {//优雅退出，释放资源bossGroup.shutdownGracefully();workerGroup.shutdownGracefully();}}private class ChildChannelHandler extends ChannelInitializer>{@Overrideprotected void initChannel(SocketChannel socketChannel) throws Exception {socketChannel.pipeline().addLast(new LineBasedFrameDecoder(1024));socketChannel.pipeline().addLast(new StringDecoder());socketChannel.pipeline().addLast(new TimeServerHandler());}}}

与上面代码不同点在于，我们在初始化过程中，往的中添加了r和两种编码器。

package netty.frame.tcpzjb.right;import io.netty.buffer.ByteBuf;import io.netty.buffer.Unpooled;import io.netty.channel.ChannelHandlerContext;import io.netty.channel.ChannelInboundHandlerAdapter;/*** created by LMR on 2020/5/20*/public class TimeServerHandler extends ChannelInboundHandlerAdapter {private int counter;@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg)throws Exception {String body = (String) msg;System.out.println("The time server receive order : " + body+ " ; the counter is : " + ++counter);String currentTime = "QUERY TIME ORDER".equalsIgnoreCase(body) ? newjava.util.Date(System.currentTimeMillis()).toString() : "BAD ORDER";currentTime = currentTime + System.getProperty("line.separator");//响应给客户端ByteBuf resBuf= Unpooled.copiedBuffer(currentTime.getBytes());ctx.writeAndFlush(resBuf);}@Overridepublic void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {ctx.close();}}

而代码相对于上一节中的代码更为简洁，不需要对消息进行编码。这是因为我们设置了字符串解码器，不需要在进行手动解码，我们收到的消息就是字符串。
3.2 客户端代码

package netty.frame.tcpzjb.right;import io.netty.bootstrap.Bootstrap;import io.netty.channel.ChannelFuture;import io.netty.channel.ChannelInitializer;import io.netty.channel.ChannelOption;import io.netty.channel.nio.NioEventLoopGroup;import io.netty.channel.socket.SocketChannel;import io.netty.channel.socket.nio.NioSocketChannel;import io.netty.handler.codec.LineBasedFrameDecoder;import io.netty.handler.codec.string.StringDecoder;/*** created by LMR on 2020/5/20*/public class TimeClient {public static void main(String[] args) throws Exception{int port = 8080;new TimeClient().connect("127.0.0.1", port);}public void connect(String host, int port) throws Exception{NioEventLoopGroup group = new NioEventLoopGroup();try {Bootstrap bootstrap = new Bootstrap();bootstrap.group(group).channel(NioSocketChannel.class).option(ChannelOption.TCP_NODELAY, true).handler(new ChannelInitializer>() {@Overrideprotected void initChannel(SocketChannel ch) throws Exception {ch.pipeline().addLast(new LineBasedFrameDecoder(1024));ch.pipeline().addLast(new StringDecoder());ch.pipeline().addLast(new TimeClientHandler());}});//发起异步连接操作ChannelFuture f = bootstrap.connect(host, port).sync();//等待客户端连接关闭f.channel().closeFuture().sync();}finally {group.shutdownGracefully();}}}

同样与之前的代码相比也仅仅增加了r和两种解码器。

package netty.frame.tcpzjb.right;import io.netty.buffer.ByteBuf;import io.netty.buffer.Unpooled;import io.netty.channel.ChannelHandlerContext;import io.netty.channel.ChannelInboundHandlerAdapter;import java.util.logging.Logger;/*** created by LMR on 2020/5/20*/public class TimeClientHandler extends ChannelInboundHandlerAdapter {private static final Logger logger = Logger.getLogger(TimeClientHandler.class.getName());private int counter;private byte[] req;public TimeClientHandler(){req = ("QUERY TIME ORDER" + System.getProperty("line.separator")).getBytes();}@Overridepublic void channelActive(ChannelHandlerContext ctx) throws Exception {ByteBuf message = null;for (int i = 0; i < 100; i++){message = Unpooled.buffer(req.length);message.writeBytes(req);ctx.writeAndFlush(message);}}@Overridepublic void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {String body = (String) msg;System.out.println("Now is : " + body + " ; the counter is :" + ++counter);}@Overridepublic void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {logger.warning("Unexpected exception from downstream : " + cause.getMessage());ctx.close();}}

在中，我们同样不需要对服务端返回的消息进行解码，相比于之前的代码更加简洁。
下面我们看看运行结果。
3.3 运行结果
服务端结果：
客户端结果：
从结果上看来，没有发生TCP的粘包和拆包问题，那为什么会出现这样的情况呢，接下来我们简单解释下原因。
3.4 工作原理
r的工作原理是它一次遍历中的可读字节，判断看是否有“\n”或者“\r\n”，如果有，就以此位置为结束位置，从可读索引到结束位置区间的字节就组成了一行。它是以换行符为结束标志的解码器，支持携带结束符或者不携带结束符两种解码方式，同时支持配置单行的最大长度。如果连续读取到最大长度后仍然没有出现换行符，就会抛出异常，同时忽略掉之前读到的异常码流。
的功能非常简单，就是将接收到的对象转换成字符串，然后继续调用后面的。r + 组合就是按行切换的文本解码器，它被设计用来支持TCP的粘包和拆包。
如果发送的消息不是以换行符结束的，该怎么办呢？或者没有回车换行符，靠消息头中的长度字段来分包怎么办？是不是需要自己写半包解码器？
答案是否定的，Netty提供了多种支持TCP粘包/拆包的解码器用来满足用户的不同诉求。在后续博客中我将继续介绍Netty提供的几种解码器的使用。
写在后面的话：
本文是我阅读《Netty权威指南》的笔记，代码是基于该书中的用例实现的，由于Netty版本不一致，我对代码中的部分进行了修改。
【Netty是如何解决TCP的粘包和拆包问题的？】参考博客：