01.Netty进阶之粘包与半包现象分析

最新推荐文章于 2023-06-29 16:53:06 发布
最新推荐文章于 2023-06-29 16:53:06 发布
阅读量77 收藏
点赞数
分类专栏： netty 文章标签： .net 网络 tcp/ip
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_38598961/article/details/130246824
版权

01.Netty进阶之粘包与半包现象分析

0、概述

有过tcp编程的伙伴可能都知道，无论是服务端还是客户端，发送或读取消息的时候，都需要考虑粘包/拆包问题。

什么是粘包/拆包

TCP是个“流”式的协议，所谓流，就像河里的水，中间没有边界。TCP传输的数据，在网络上就是一连串的数据，没有分界线。TCP协议的底层，并不了解上层业务的具体定义，它会根据TCP缓冲区的实际情况进行包的划分。在业务层面认为一个完整的包，可能会被TCP拆分成多个小包进行发送，也可能把多个小的包封装成一个大的数据包进行发送，这就是所谓的TCP粘包拆包问题。

粘包/拆包可能发生的情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6YNnBcCk-1681891926739)(D:\文档\2023\md\image\粘包拆包.png)]

客户端发送了两个数据包P1和P2给服务端，服务端一次读取到的字节数是不确定的，可能存在以下4种情况：

（1）服务端分两次读取到了两个独立的数据包P1和P2，没有发送粘包和拆包；
（2）服务端一次读到了两个数据包，P1和P2粘在一起，这就是TCP粘包情况；
（3）服务端分两次读取到了两个数据包，第一次读取了完整的P1包和P2包的一部分，第二次读取到了P2包的剩余部分，这被称为TCP拆包；
（4）服务端分两次读取了两个数据包，第一次读取了P1包的一部分，第二次读取到了P1包的剩余部分，这也是TCP拆包；

一、粘包现象

  • 服务端代码
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.*;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public class HelloWorldServer {
    void start(){
        NioEventLoopGroup boss = new NioEventLoopGroup(1);
        NioEventLoopGroup worker = new NioEventLoopGroup();

        try {
            ServerBootstrap serverBootstrap = new ServerBootstrap();
            serverBootstrap.channel(NioServerSocketChannel.class);
//            serverBootstrap.option(ChannelOption.SO_RCVBUF,10);
            serverBootstrap.group(boss,worker);
            serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
                @Override
                protected void initChannel(SocketChannel ch) throws Exception {
                    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());
            channelFuture.channel().closeFuture().sync();
        } catch (InterruptedException e) {
            log.error("server error", e);
        }finally {
            boss.shutdownGracefully();
            worker.shutdownGracefully();
            log.debug("stoped");
        }

    }

    public static void main(String[] args) {
        new HelloWorldServer().start();
    }
}
  • 客户端代码
import io.netty.bootstrap.Bootstrap;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
import lombok.extern.slf4j.Slf4j;

import java.util.Random;


@Slf4j
public class HelloWorldClient {
    public static void main(String[] args) {
        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("connetted...");
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                        //会在连接channel建立连接后，触发active事件
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
                            log.debug("sending...");
                            Random r = new Random();
                            char c = 'a';
                            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);
                            }
                        }
                    });
                }
            });
            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();
        }

    }
}

运行结果

22:51:18 [DEBUG] [main] c.l.n.p.HelloWorldServer - [id: 0x10e3b18e, L:/0:0:0:0:0:0:0:0:8080] binding...
22:51:18 [DEBUG] [main] c.l.n.p.HelloWorldServer - [id: 0x10e3b18e, L:/0:0:0:0:0:0:0:0:8080] bound...
22:51:25 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x193974e2, L:/127.0.0.1:8080 - R:/127.0.0.1:61906] REGISTERED
22:51:25 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x193974e2, L:/127.0.0.1:8080 - R:/127.0.0.1:61906] ACTIVE
22:51:25 [DEBUG] [nioEventLoopGroup-3-1] c.l.n.p.HelloWorldServer - connected[id: 0x193974e2, L:/127.0.0.1:8080 - R:/127.0.0.1:61906]
22:51:25 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x193974e2, L:/127.0.0.1:8080 - R:/127.0.0.1:61906] READ: 160B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000010| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000020| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000030| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000040| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000050| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000060| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000070| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000080| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000090| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
+--------+-------------------------------------------------+----------------+
22:51:25 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x193974e2, L:/127.0.0.1:8080 - R:/127.0.0.1:61906] READ COMPLETE

可见虽然客户端是分别以16字节为单位，通过channel向服务器发送了10次数据，可是服务器端却只接收了一次，接收数据的大小为160B，即客户端发送的数据总大小，这就是粘包现象。

二、半包现象

将客户端-服务器之间的channel容量进行调整,将服务端注释掉的代码打开

  • 服务端代码
// 调整channel的容量
serverBootstrap.option(ChannelOption.SO_RCVBUF, 10);

注意

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

运行结果

22:56:15 [DEBUG] [main] c.l.n.p.HelloWorldServer - [id: 0x3185dbfc, L:/0:0:0:0:0:0:0:0:8080] binding...
22:56:15 [DEBUG] [main] c.l.n.p.HelloWorldServer - [id: 0x3185dbfc, L:/0:0:0:0:0:0:0:0:8080] bound...
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] REGISTERED
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] ACTIVE
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] c.l.n.p.HelloWorldServer - connected[id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994]
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ: 36B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000010| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000020| 00 01 02 03                                     |....            |
+--------+-------------------------------------------------+----------------+
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ COMPLETE
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ: 40B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000010| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000020| 04 05 06 07 08 09 0a 0b                         |........        |
+--------+-------------------------------------------------+----------------+
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ COMPLETE
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ: 40B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 0c 0d 0e 0f 00 01 02 03 04 05 06 07 08 09 0a 0b |................|
|00000010| 0c 0d 0e 0f 00 01 02 03 04 05 06 07 08 09 0a 0b |................|
|00000020| 0c 0d 0e 0f 00 01 02 03                         |........        |
+--------+-------------------------------------------------+----------------+
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ COMPLETE
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ: 40B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000010| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000020| 04 05 06 07 08 09 0a 0b                         |........        |
+--------+-------------------------------------------------+----------------+
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ COMPLETE
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ: 4B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 0c 0d 0e 0f                                     |....            |
+--------+-------------------------------------------------+----------------+
22:56:24 [DEBUG] [nioEventLoopGroup-3-1] i.n.h.l.LoggingHandler - [id: 0x206018a7, L:/127.0.0.1:8080 - R:/127.0.0.1:61994] READ COMPLETE

从结果可知客户端每次发送的数据，因channel容量不足，无法将发送的数据一次性接收，便产生了半包现象。

三、现象分析

3.1 粘包
  • 现象，发送 abc def，接收 abcdef
  • 原因
    • 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024）
    • 滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大，这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包
    • Nagle 算法：会造成粘包
3.2 半包
  • 现象，发送 abcdef，接收 abc def
  • 原因
    • 应用层：接收方 ByteBuf 小于实际发送数据量
    • 滑动窗口：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时放不下了，只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包
    • MSS 限制：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包

本质是因为 TCP 是流式协议，消息无边界

3.3 滑动窗口
  • TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差

01.Netty粘包与半包分析01.png

  • 为了解决此问题，引入了窗口概念，窗口大小即决定了无需等待应答而可以继续发送的数据最大值

01.Netty粘包与半包分析02.png

  • 窗口实际就起到一个缓冲区的作用，同时也能起到流量控制的作用
    • 图中深色的部分即要发送的数据，高亮的部分即窗口
    • 窗口内的数据才允许被发送，当应答未到达前，窗口必须停止滑动
    • 如果 1001~2000 这个段的数据 ack 回来了，窗口就可以向前滑动
    • 接收方也会维护一个窗口，只有落在窗口内的数据才能允许接收
3.4 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

01.Netty粘包与半包分析03.jpg

3.5 Nagle 算法
  • 即使发送一个字节，也需要加入 tcp 头和 ip 头，也就是总字节数会使用 41 bytes，非常不经济。因此为了提高网络利用率，tcp 希望尽可能发送足够大的数据，这就是 Nagle 算法产生的缘由
  • 该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送
    • 如果 SO_SNDBUF 的数据达到 MSS，则需要发送
    • 如果 SO_SNDBUF 中含有 FIN（表示需要连接关闭）这时将剩余数据发送，再关闭
    • 如果 TCP_NODELAY = true，则需要发送
    • 已发送的数据都收到 ack 时，则需要发送
    • 上述条件不满足，但发生超时（一般为 200ms）则需要发送
      头和 ip 头，也就是总字节数会使用 41 bytes，非常不经济。因此为了提高网络利用率，tcp 希望尽可能发送足够大的数据，这就是 Nagle 算法产生的缘由
  • 该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送
    • 如果 SO_SNDBUF 的数据达到 MSS，则需要发送
    • 如果 SO_SNDBUF 中含有 FIN（表示需要连接关闭）这时将剩余数据发送，再关闭
    • 如果 TCP_NODELAY = true，则需要发送
    • 已发送的数据都收到 ack 时，则需要发送
    • 上述条件不满足，但发生超时（一般为 200ms）则需要发送
    • 除上述情况，延迟发送
oneMonthOneBook
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
《Netty进阶之路 跟着案例学Netty》.rar
11-22
Java进阶技术-netty进阶之路
Netty进阶之路-跟着案例学Netty
05-16
Netty进阶之路，跟着案例学Netty，李林峰大神新作。值得一读。
Netty应用之粘包半包问题
weixin_46120888的博客
05-05 2282
文章目录1.粘包现象演示2.半包现象演示3.粘包半包现象分析3.1 粘包3.2 半包4.粘包半包解决方案4.1短连接4.2 定长解码器4.3 行解码器4.4 LengthFieldBasedFrameDecoder4.5 LengthFieldBasedFrameDecoder演示 参考黑马程序员 1.粘包现象演示 我们通过一段代码演示一个这个粘包现象，首先我们来看服务端 void start() { NioEventLoopGroup boss = new NioEventLoop
Netty 进阶学习（九）-- 粘包与半包
weixin_43989102的博客
09-07 317
链路层对一次能够发送的最大数据有限制，这个限制称之为 MTU（maximum transmission unit），不同的链路设备的 MTU 值也有所不同，例如。TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差。消息边界就是分隔符，不再浪费空间，但是内容使用分隔符就需要进行转义，效率也不是很高。消息边界也就是固定长度，这种方式实现简单，但是空间有极大的浪费，不推荐使用。字节的数据，查看结果，存在接收到。
Netty进阶：粘包、半包
weixin_41377877的博客
10-13 697
发生粘包、半包现象的本质是因为TCP是流式协议，消息无边界。
Netty进阶——粘包/半包
weixin_52315708的博客
06-29 875
TCP（Transmission Control Protocol）是一种面向连接的可靠传输协议，广泛应用于网络通信领域。在TCP协议中，数据被分割成一个一个的报文段进行传输。然而，由于网络传输的不可靠性，TCP协议会面临一些数据传输问题，如粘包和半包问题。在网络通信中，当发送方连续发送多个小数据包时，接收方可能会将它们合并成一个大的数据包，这就是粘包问题；而当发送方发送的数据包长度大于接收方的缓冲区长度时，接收方无法完整接收数据包，导致数据的接收不完整，这就是半包问题。
带你理解netty中 粘包 半包的处理方法
热爱技术，享受生活
08-08 253
我们在网络编程中，处理粘包，半包是避免不了的问题，那今天就有一个小例子，带大家了解下netty中粘包，半包的处理方法
高清_书签_Netty进阶之路 跟着案例学Netty.zip
06-16
精选自1000多个一线业务实际案例，从原理到实践全景式讲解Netty项目实践，快速领悟Netty专家花大量时间积累的经验，提高编程水平及分析解决问题的能力，《Netty木又威指南》作者力作，众专家力荐 Netty将Java NIO...
《Netty进阶之路 跟着案例学Netty》_李林锋_
05-30
Netty进阶之路 跟着案例学Netty 整本书无密码，Netty进阶之路 跟着案例学Netty
Netty进阶——粘包与半包（现象分析)
小志的博客
11-29 341
Netty进阶——粘包与半包（现象分析)
Netty 粘包/半包原理与拆包实战 【源代码 新】
11-11
- 本实例是《Netty 粘包/半包原理与拆包实战》 一文的源代码工程。 大家好，我是作者尼恩。 在前面的文章中，完成了一个高性能的 Java 聊天程序，尼恩已经再一次的进行了通讯协议的选择。放弃了大家非常熟悉的json 格式，选择了性能更佳的 Protobuf协议。 本实例，解决粘包和半包问题
netty粘包半包问题常见解决方案及总结
weixin_38312719的博客
09-26 436
解决粘包半包主要目的 解决粘包半包问题其实就是围绕一个主题，那就是从TCP包中，通过一定字节作为标记，然后标记前字节 必定是一个可反序列化的字节Buff, 这样就可以解决粘包半包问题 解决粘包方案 1.通过指定固定字节数作为分隔标准 2.指定特殊字符作为分隔标准 3.默认使用换行符作为分隔标准（指定特殊字符作为分隔标准一种情况） 解决粘包方案图解 FixedLengthFrameDecoder //截取固定长度的字节作为一个包 //子类解码实现，由ByteToMessageDecoder主流程的chan
Netty--原理--TCP--粘包与拆包
IT利刃出鞘的博客
06-01 1208
本文介绍Netty是如何解决TCP的粘包与拆包问题的。
(十)Netty进阶篇：漫谈网络粘包、半包问题、解码器与长连接、心跳机制实战
BASK2312的博客
02-06 884
这不是违背了长连接的初衷吗？答案并非如此，因为前面在咱们的客户端中，在通道长时间未触发写事件的情况下，会主动向服务端发送心跳包，而心跳包也是一种特殊的数据包，依旧会触发服务端上的读事件，所以但凡正常发送心跳包的连接，都不会被服务端主动关闭。既然无法在底层从根源上解决问题，那此时可以换个思路，也就是从应用层出发，粘包、半包问题都是由于数据包与包之间，没有边界分割导致的，那想要解决这样的问题，发送方可以在每个数据包的尾部，自己拼接一个特殊分隔符，接收方读取到数据时，再根据对应的分隔符读取数据即可。
Netty 解决TCP粘包/半包使用
Charge8的博客
05-03 3562
Netty 解决TCP粘包/半包使用
Netty：解决粘包、半包问题，实现ByteToMessageDecoder解码器分包
Oxye
03-20 995
开发时使用netty的解码器解析协议报文时，出现StringIndexOutOfBoundsException报错，debug发现是协议头总长度和当次读取的数据总长度不一致，看来是遇到半包问题了，所以通过下面的代码解决，供参考。核心手段是使用ByteBuf 的markReaderIndex、resetReaderIndex来控制对ByteBuf对象的读取，长度不够就攒着，够了就读走想要的部分。我们约定协议的byte数组结构为 3位长度+1位id+对应长度的数据。
Netty黏包半包解决方案
前者已逝，后者未至。
03-24 1514
了解黏包半包发生的原因，了解各个解决方案适用的场景。
Netty使用篇：半包&粘包
热门推荐
七叔的博客
11-13 2万+
Netty使用篇：半包&粘包
Netty_03_ByteBuf和网络中拆包粘包问题及其解决
毛毛的专栏
12-10 1097
Netty
netty进阶之路 pdf
最新发布
07-08
《Netty进阶之路》是一本关于Netty网络编程框架的进阶指南，它主要介绍了如何在实际项目中应用Netty来构建高效、稳定的网络应用。 首先，该书从Netty的基础概念和核心组件开始介绍，如Channel、EventLoop、...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值