搞懂Netty（2）使用Netty通信时，遇到TCP粘包问题如何解决？

我就是我 2023-06-12 08:42 41阅读 0赞

在上一篇文章中主要是使用Springboot开发了一个Netty通信的基本案例，这篇文章是在上一篇文章的基础之上进行讲解的，主要是考虑传输数据如果遇到粘包问题该如何解决。

这篇文章会按照一下步骤进行讲解，希望对你有所收获：

> **1、什么是TCP粘包拆包**
> 
> **2、Netty中粘包问题的问题重现**
> 
> **3、Netty中粘包问题的解决方案**

OK，在你心中有这么一个基本的脉络之后就可以开始今天的文章了。本系列所有的文章都会给出完整的代码，且在电脑上真实运行了一遍，确保无误。

**一、什么是TCP拆包和粘包**

我们使用TCP协议在传输数据的时候，如果数据块比较大，就会考虑将其切分。把一个大的数据包进行切割成一个个小的数据包发送。这时候就会遇到拆包和粘包的问题。

比如说在这里客户端发送了两个数据包D1和D2到服务端，在传输的时候就可能会遇到下列问题：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70]

通过上面这张图相信你基本上能够理解了。不过我们在这里还是需要稍微解释一下：

情况1：D1和D2正常发送，每次发送一个整包。

情况2：D1数据包比较大，D2比较小。第一次发送D1的一部分，第二次发送D1剩下的和D2整包。这叫拆包。

情况2：D1和D2数据包都比较小，一次发送两个整包，这就叫做粘包。

情况4：D1数据包比较小，D2比较大。第一次发送D1整包和D2一部分，第二次发送D2剩下的。这叫拆包。

情况5：D1和D2数据包都比较大，这时候分开发。

为什么会出现这样的问题呢？想要解释清楚，就必须要考虑到计算机网络的相关知识了，TCP在接受数据的时候，有一个滑动窗口来控制接受数据的大小，这个滑动窗口你就可以理解为一个缓冲区的大小。缓冲区满了就会把数据发送。数据包的大小是不固定的，有时候比缓冲区大，有时候小。这时候就会出现上面的现象。

下面我们使用代码来重现这个现象。

**二、问题重现**

**1、前提准备**

我们是基于Springboot开发的，因此还是和上一节一样，首先创建一个Springboot的web工程，添加一下依赖：

<dependency>
          <groupId>io.netty</groupId>
          <artifactId>netty-all</artifactId>
          <version>5.0.0.Alpha1</version>
    </dependency>

如果你没有使用maven，下载相关jar包，直接导入IDE中即可。

**2、服务端代码开发**

**步骤一：创建server类**

这个server类，在上一篇文章中提到，是一个模板类，直接拿来用即可。

@Component
    public class NettyServer { 
        EventLoopGroup boss = new NioEventLoopGroup();
        EventLoopGroup work = new NioEventLoopGroup();
        @PostConstruct
        public void start() throws InterruptedException { 
                ServerBootstrap bootstrap = new ServerBootstrap();
                bootstrap.group(boss, work)
                        .channel(NioServerSocketChannel.class)
                        .option(ChannelOption.SO_BACKLOG, 1024)
                        .childOption(ChannelOption.SO_KEEPALIVE, true)
                        .handler(new LoggingHandler(LogLevel.INFO))
                        .childHandler(new ChannelInitializer<SocketChannel>() { 
                            public void initChannel(SocketChannel sc) throws Exception { 
                                sc.pipeline().addLast(new ServerUAVHandler());
                            }
                         });
                ChannelFuture cf = bootstrap.bind(8881).sync();
                System.out.println("启动成功");
        }
        @PreDestroy
        private void destory() throws Exception{ 
            boss.shutdownGracefully();
            work.shutdownGracefully();
        }
    }

在上面的这个代码中同样我们最主要的是关注ServerUAVHandler的实现。

**步骤二：Handler的实现**

public class ServerUAVHandler extends ChannelHandlerAdapter { 
        private int counter=0;
        @Override
        public 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("客户端信息是："+body);
            System.out.println(body+",counter:"+ ++counter);
            ByteBuf resp=Unpooled.copiedBuffer(("A"
                   +System.getProperty("line.separator")).getBytes());
            ctx.writeAndFlush(resp);
        }
    }

在这个类中，使用channelRead方法来读取客户端发送过来的信息。

（1）首先定义了一个counter，用于计算客户端发送了多少条消息。

（2）在channelRead内部，首先将msg转化为ByteBuf。

（3）将buf的数据转化为字节byte

（4）将buf的字节数据转化为String类型，然后输出。

（5）使用ctx的writeAndFlush方法，每收到一个客户端的数据，给对方回复一个A。别忘了还有一个换行符。

在上面的这个代码中，最主要的就是服务端每收到一条客户端的信息，就给其回复一条。也就是说客户端和服务端的消息数量应该是一样的。

**3、客户端代码开发**

**步骤一：创建client类**

@Component
    public class NettyClient { 
        private SocketChannel socketChannel;
        EventLoopGroup group = new NioEventLoopGroup();
        @PostConstruct
        public void start() throws Exception { 
            try{ 
                Bootstrap b = new Bootstrap();
                b.group(group).channel(NioSocketChannel.class)
                        .option(ChannelOption.TCP_NODELAY, true)
                        .option(ChannelOption.SO_KEEPALIVE,true)
                        .handler(new ChannelInitializer<SocketChannel>() { 
                            public void initChannel(SocketChannel ch) throws Exception { 
                                ch.pipeline().addLast(new ClientHandler());
                            }
                        });
                ChannelFuture cf = b.connect("127.0.0.1",8881).sync();
                System.out.println("链接成功");
                cf.channel().closeFuture().sync();
            }finally{ 
               group.shutdownGracefully();
            }
        }
    }

同样的代码的逻辑在上一篇文章中已经说了，我们还是最关注的事件处理类Handler。

**步骤二：Handler实现**

public class ClientHandler extends ChannelHandlerAdapter { 
        @Override
        public void channelActive(ChannelHandlerContext ctx) throws Exception { 
            ByteBuf resp = null;
            for (int i=0;i<100;i++){ 
                resp=Unpooled.copiedBuffer(("我爱你"
                    +System.getProperty("line.separator")).getBytes());
                ctx.writeAndFlush(resp);
            }
        }
        @Override
        public 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(body+" ");
        }
    }

这个客户端的Handler看起来有点多，一共有两个方法，channelActive和channelRead。

（1）channelActive里面使用for循环给服务器发送了100条，我爱你。每次发送还有在末尾添加一个换行符。

（2）channelRead里面接受服务器返回的消息。

按道理来讲，客户端给服务端发送了100条数据，那么服务端也会返回回来100条。我们来验证一下。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 1]

这里输出的是服务端的信息，从上面的输出结果你就会发现，其实客户端的“我爱你”都被黏在了一块。本来100条但是现在却只有17条了，这就是发生了粘包现象。

如何来解决呢？下面我们看看。

**三、粘包问题解决**

解决的思路很简单，也就是每次发送一个数据包的时候，添加一个标识符，读的时候一直读到这个标识符才表示一个完整的数据包。在上面我们添加的是line.separator，也就是换行符“\\n”。

**1、服务端server类更改。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 2]

**2、服务端Handler类更改**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 3]

**3、客户端Client更改**

![在这里插入图片描述][20191101105134288.png]

**4、客户端Handler更改**

![在这里插入图片描述][20191101105141851.png]

客户端和服务端改的地方都一样，不过还是贴了出来，现在我们再运行一波。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 4]

看到没是不是很神奇。我们来分析一下我们都修改了什么。

好像我们就只是在server和client类添加了两个类，一个是LineBasedFrameDecoder，一个是StringDecoder，其他的都是直接删除，这两个类有什么作用呢？

（1）LineBasedFrameDecoder的作用是在读取数据的时候，一直读到是否含有换行符“\\n”或者是“\\r\\n”。如果读到了就表示该结束了。因此就拿到了这一行的数据包。

（2）StringDecoder用于对之前LineBasedFrameDecoder读取的这一行数据包进行解码。将对象转换为字符串。

OK，好像他们俩搭配，干活真不累，现在我们终于可以解决粘包的问题了，但是同时也出现了一个新的问题，那就是如果我们的标识符不是换行符“\\n”或者是“\\r\\n”又该怎么办呢？幸好Netty同样为我们提供了几种其他的解码器，叫做DelimiterBasedFrameDecoder和FixedLengthFrameDecoder，前面这个可以自动完成以分隔符做结束标志的消息，后面这个可以自动完成对定长消息的解码。都可以解决粘包拆包问题。

现在我们解决了一个大问题，但是同时也出现了一个新的大问题，那就是我们的数据都是通过网络进行传输的，因此就需要编码和解码的操作。netty又为我们提供了什么编码解码技术呢？下篇文章更精彩。感谢大家。

ty同样为我们提供了几种其他的解码器，叫做DelimiterBasedFrameDecoder和FixedLengthFrameDecoder，前面这个可以自动完成以分隔符做结束标志的消息，后面这个可以自动完成对定长消息的解码。都可以解决粘包拆包问题。

现在我们解决了一个大问题，但是同时也出现了一个新的大问题，那就是我们的数据都是通过网络进行传输的，因此就需要编码和解码的操作。netty又为我们提供了什么编码解码技术呢？下篇文章更精彩。感谢大家。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 5]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70]: /images/20230531/b712474441204ad7ad4679ff505c26d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 1]: /images/20230531/ec9a69b1ec5f4319b23c0d1214c54f01.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 2]: /images/20230531/1963fa8896aa44fe95afe26a668c6fc1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 3]: /images/20230531/22d2595a95614fab887f64e61b163679.png
[20191101105134288.png]: /images/20230531/aac8d8e5a5c84dfd96d1b7c07466ec15.png
[20191101105141851.png]: /images/20230531/d2122d2b45384d12b2564cd305a02914.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 4]: /images/20230531/a5719d4bb1de46208de121d0ceb358e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NERERMTEw_size_16_color_FFFFFF_t_70 5]: /images/20230531/a3d1156c5ee84289a83873c7140d07a7.png