Netty学习（二）——黏包半包、协议设计解析、聊天室

最新推荐文章于 2025-04-21 11:26:29 发布

青衫白衣98

最新推荐文章于 2025-04-21 11:26:29 发布

阅读量1.1k

点赞数 25

文章标签： netty 粘包半包协议设计

本文链接：https://blog.youkuaiyun.com/weixin_44630656/article/details/139965443

版权

一、粘包与半包

1.1 粘包和半包复现

1、粘包复现：

Server代码：

public class ProblemServer {
   

    public static void main(String[] args) throws InterruptedException {
   
        new ServerBootstrap()
                //若是指定接收缓冲区大小：就会出现黏包、半包情况
               // .option(ChannelOption.SO_RCVBUF, 10)  //设置指定大小的接收缓冲区（TCP）（定义接收的系统缓冲区buf字节大小）
                .group(new NioEventLoopGroup(), new NioEventLoopGroup(2))
                .channel(NioServerSocketChannel.class)
                .childHandler(new ChannelInitializer<NioSocketChannel>() {
   
                    @Override
                    protected void initChannel(NioSocketChannel ch){
   
                        //添加日志处理器（会打印每次接收包得到的数据）
                        ch.pipeline().addLast(new LoggingHandler());
                    }
                })
                .bind(8080).sync();
        System.out.println("服务器启动成功！");
    }
}

client代码：

public class ProblemClient {
   
    public static void main(String[] args) throws InterruptedException {
   
        NioEventLoopGroup group = new NioEventLoopGroup();
        Channel channel = new Bootstrap()
                .group(group)
                .channel(NioSocketChannel.class)
                .handler(new ChannelInitializer<NioSocketChannel>() {
   
                    @Override
                    protected void initChannel(NioSocketChannel ch) throws Exception {
   
                        ch.pipeline().addLast(new StringEncoder());//String=>ByteBuf
                        ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
   

                            //channelActive：连接建立之后会执行会触发Active事件
                            @Override
                            public void channelActive(ChannelHandlerContext ctx) throws Exception {
   
                                //连续发送10次16字节的内容
                                for (int i = 0; i < 10; i++) {
   
                                    final ByteBuf buffer = ctx.alloc().buffer(16);
                                    buffer.writeBytes(new byte[]{
   1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16});
                                    ctx.writeAndFlush(buffer);
                                }
                                System.out.println("finish!");
                            }
                        });
                    }
                }).connect("127.0.0.1", 8080).sync().channel();
        System.out.println("客户端连接成功：" + channel);
        channel.closeFuture().addListener(future -> {
   
            group.shutdownGracefully();
        });
    }

}

效果：

半包复现：

服务器代码

//对ServerBootstrap进行配置，在server的18行添加接收缓冲区配置
.option(ChannelOption.SO_RCVBUF, 10)  //设置指定大小的接收缓冲区（TCP）（定义接收的系统缓冲区buf字节大小）

说明：由于我们客户端每次发送的数据长度都为16个字节，而服务端每次接收到的有50，有10就说明出现了粘包、半包情况。这里出现这种情况是，对系统接收的网络缓冲区进行了设置，而ByteBuf每次设置的容量没有限制就会出现这种情况。

注意

serverBootstrap.option(ChannelOption.SO_RCVBUF, 10) 影响的底层接收缓冲区（即滑动窗口）大小，仅决定了 netty 读取的最小单位，netty 实际每次读取的一般是它的整数倍

1.2 现象分析

1.2.1 粘包、半包情况分析

粘包：

现象：发送 abc def，接收 abcdef。（明明是多次发送请求，服务器端一次就全部接收了）
原因
- 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024），直接将多个请求的数据统一直接处理。
- 滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大，这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包。
- Nagle 算法：会造成粘包。（出现原因：因为只要是传输层都会加上一个报头，IP层的报头20个字节，tcp的也是20个，此时就会出现一个问题，若是只是发送一个1个字节数据，那么总体也会发送41个字节，此时报头的长度远远大于内容长度，造成了浪费，此时就出现了该算法，其就是尽可能多的发送数据，攒够了一批再发，也就是说若是待发送的数据量太少会先进行积攒，之后攒够了统一再发！）

半包:

现象，发送 abcdef，接收 abc def。（明明是一次发送的请求，服务器端却使用了两次或多次接收到请求的一部分数据）
原因
- 应用层：接收方 ByteBuf 小于实际发送数据量
- TCP(滑动窗口)：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时放不下了，只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包。
- 链路层(MSS限制)：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包。
  - 网络层网卡设备对于数据包的大小是有限制的，（MTU）笔记本普通的网卡是1500个字节，抛开TCP、IP的报文头，那么最大能够传1460个字节，超过这个数据就会将数据切分发送。MTU是数据链路层最大载荷长度，其中MTU包含了MSS。
  - 在自己电脑上一般都是使用localhost（回环地址）来进行测试的，而回环地址对于MSS没有限制，大小为65535，所以本地开发时不好复现。若是向局域网的另一台电脑发送，就会有限制了

所以黏包、半包是在网络编程时必须要解决的问题！本质是因为TCP是流式协议，消息无边界。

1.2.2 滑动窗口、MSS限制、Nagle算法介绍

滑动窗口：

TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差
为了解决此问题，引入了窗口概念，窗口大小即决定了无需等待应答而可以继续发送的数据最大值
窗口实际就起到一个缓冲区的作用，同时也能起到流量控制的作用
- 图中深色的部分即要发送的数据，高亮的部分即窗口
- 窗口内的数据才允许被发送，当应答未到达前，窗口必须停止滑动
- 如果 1001~2000 这个段的数据 ack 回来了，窗口就可以向前滑动
- 接收方也会维护一个窗口，只有落在窗口内的数据才能允许接收

MSS 限制：

链路层对一次能够发送的最大数据有限制，这个限制称之为 MTU（maximum transmission unit），不同的链路设备的 MTU 值也有所不同，例如
以太网的 MTU 是 1500
FDDI（光纤分布式数据接口）的 MTU 是 4352
本地回环地址的 MTU 是 65535 - 本地测试不走网卡
MSS 是最大段长度（maximum segment size），它是 MTU 刨去 tcp 头和 ip 头后剩余能够作为数据传输的字节数
ipv4 tcp 头占用 20 bytes，ip 头占用 20 bytes，因此以太网 MSS 的值为 1500 - 40 = 1460
TCP 在传递大量数据时，会按照 MSS 大小将数据进行分割发送
MSS 的值在三次握手时通知对方自己 MSS 的值，然后在两者之间选择一个小值作为 MSS

Nagle 算法：

即使发送一个字节，也需要加入 tcp 头和 ip 头，也就是总字节数会使用 41 bytes，非常不经济。因此为了提高网络利用率，tcp 希望尽可能发送足够大的数据，这就是 Nagle 算法产生的缘由
该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送
- 如果 SO_SNDBUF 的数据达到 MSS，则需要发送
- 如果 SO_SNDBUF 中含有 FIN（表示需要连接关闭）这时将剩余数据发送，再关闭
- 如果 TCP_NODELAY = true，则需要发送
- 已发送的数据都收到 ack 时，则需要发送
- 上述条件不满足，但发生超时（一般为 200ms）则需要发送
- 除上述情况，延迟发送

1.3 解决办法

方法列举：

短链接，发一个包建立一次连接，这样连接建立到连接断开之间就是消息的边界，缺点效率太低
每一条消息采用固定长度，缺点浪费空间
每一条消息采用分隔符，例如 \n，缺点需要转义
每一条消息分为 head 和 body，head 中包含 body 的长度

1.3.1 短链接

客户端每次向服务器发送数据以后，就与服务器断开连接，此时的消息边界为连接建立到连接断开。这时便无需使用滑动窗口等技术来缓冲数据，则不会发生粘包现象。但如果一次性数据发送过多，接收方无法一次性容纳所有数据，还是会发生半包现象，所以短链接无法解决半包现象

客户端代码改进ctx.channel().close();

public class StudyClient {
   
    static final Logger log = LoggerFactory.getLogger(StudyClient.class);
    public static void main(String[] args) {
   
       for (int i = 0;i < 10;i++) {
   
           send();
       }
        System.out.println("finish");
    }

    public static void send() {
   
        NioEventLoopGroup worker = new NioEventLoopGroup();
        try {
   
            Bootstrap bootstrap = new Bootstrap();
            bootstrap.channel(NioSocketChannel.class);
            bootstrap.group(worker);
            bootstrap.handler(new ChannelInitializer<SocketChannel>() {
   
                @Override
                protected void initChannel(SocketChannel ch) throws Exception {
   
                    log.debug("connected...");
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
   
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
   
                            log.debug("sending...");
                            // 每次发送16个字节的数据，共发送10次
                            for (int i = 0; i < 10; i++) {
   
                                ByteBuf buffer = ctx.alloc().buffer();
                                buffer.writeBytes(new byte[]{
   0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15});
                                ctx.writeAndFlush(buffer);
                                // 使用短链接，每次发送完毕后就断开连接
                                ctx.channel().close();
                            }
                        }
                    });
                }
            });
            ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 8080).sync();
            channelFuture.channel().closeFuture().sync();

        } catch (InterruptedException e) {
   
            log.error("client error", e);
        } finally {
   
            worker.shutdownGracefully();
        }
    }

}

客户端每次向服务器发送了16B的数据，发送后断开连接，未出现粘包现象

1.3.2 定长解码器

Netty中提供了一个FixedLengthFrameDecoder(固定长度解析器)，是一个特殊的handler，只不过是专门用来进行解码的。

客户端给每个发送的数据封装成定长的长度(多余的使用分隔符，统一规定)最后统一通过一个ByteBuf发送出去；服务端的话通过使用FixedLengthFrameDecoder来进行固定长度解析，那么每次自然也就解析到定长的Bytebuf来进行处理。
服务器与客户端作一个长度约定，服务端只有收到固定长度的才会接收完毕，否则也会进行等待直到够一定长度才向下一个handler传递；若是一次接收到的长度过大，ByteBuf也只会截取固定长度的内容并对下一个handler进行传递，多出来的部分会留着后序发来的数据再进行组合。

优缺点：虽然能够解决黏包、半包问题，但是客户端要构成定长长度有时候无效内容占用的字节数比较多（若是传递的内容比较少，则为了构成定长长度那么就会产生资源浪费）。

代码示例：

server:

/**
 * 使用定长解码器解决黏包、半包
 */
public class StudyServerV2 {
   
    static final Logger log = LoggerFactory.getLogger(StudyServerV2.class);
    void start() {
   
        NioEventLoopGroup boss = new NioEventLoopGroup(1);
        NioEventLoopGroup worker = new NioEventLoopGroup();
        try {
   
            ServerBootstrap serverBootstrap = new ServerBootstrap();
            serverBootstrap.channel(NioServerSocketChannel.class);
            serverBootstrap.group(boss, worker);
            serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
   
                @Override
                protected void initChannel(SocketChannel ch) {
   
                    // 使用FixedLengthFrameDecoder对粘包数据进行拆分，该handler需要添加在LoggingHandler之前，保证数据被打印时已被拆分
                    ch.pipeline().addLast(new FixedLengthFrameDecoder(16));
                    ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
   
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
   
                            // 连接建立时会执行该方法
                            log.debug("connected {}", ctx.channel());
                            super.channelActive(ctx);
                        }

                        @Override
                        public void channelInactive(ChannelHandlerContext ctx) throws Exception {
   
                            // 连接断开时会执行该方法
                            log.debug("disconnect {}", ctx.channel());
                            super.channelInactive(ctx);
                        }
                    });
                }
            });
            ChannelFuture channelFuture = serverBootstrap.bind(8080);
            log.debug("{} binding...", channelFuture.channel());
            channelFuture.sync();
            log.debug("{} bound...", channelFuture.channel());
            // 关闭channel
            channelFuture.channel().closeFuture().sync();
        } catch (InterruptedException e) {
   
            log.error("server error", e);
        } finally {
   
            boss.shutdownGracefully();
            worker.shutdownGracefully();
            log.debug("stopped");
        }
    }

    public static void main(String[] args) {
   
        new StudyServerV2().start();
    }
}

Client：

public class StudyClientV2 {
   
    static final Logger log = LoggerFactory.getLogger(StudyClientV2.class);
    public static void main(String[] args) {
   
        send();
        System.out.println("finish");
    }

    public static void send() {
   
        NioEventLoopGroup worker = new NioEventLoopGroup();
        try {
   
            Bootstrap bootstrap = new Bootstrap();
            bootstrap.channel(NioSocketChannel.class);
            bootstrap.group(worker);
            bootstrap.handler(new ChannelInitializer<SocketChannel>() {
   
                @Override
                protected void initChannel(SocketChannel ch) throws Exception {
   
                    log.debug("connected...");
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
   
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
   
                            log.debug("sending...");
                            // 约定最大长度为16
                            final int maxLength = 16;
                            // 被发送的数据
                            char c = 'a';
                            // 向服务器发送10个报文
                            for (int i = 0; i < 10; i++) {
   
                                ByteBuf buffer = ctx.alloc().buffer(maxLength);
                                // 定长byte数组，未使用部分会以0进行填充
                                byte[] bytes = new byte[maxLength];
                                // 生成长度为0~15的数据

最低0.47元/天解锁文章