netty从入门到放弃—消息的粘包和拆包

最新推荐文章于 2024-03-23 10:03:48 发布
最新推荐文章于 2024-03-23 10:03:48 发布
阅读量228 收藏
点赞数
分类专栏： netty 文章标签： java netty 网络
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq171263/article/details/108827493
版权

何为拆包和粘包

在我们计算机使用网络的过程中，计算机可能同时存在多个网络程序，网路上又有无数的网络应用在占用带宽，这就导致了我们的消息在底层的消息发送中，它很有可能是不完整的，在解释拆包和粘包之前，我们先来跑一段程序，代码的只要逻辑是客户端连续给服务端发送100条消息，看看服务端每次接收的结果，主要代码如下：

客户端：

bootstrap.group(nioEventLoopGroup)
//                .option(ChannelOption.SO_BACKLOG, 1024)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到服务器回复 [{}]", msg);
                                }

                                @Override
                                public void channelActive(ChannelHandlerContext ctx) {
                                    for (int i= 0; i < 100; i++) {
                                        String lineStr = "你好欢迎来netty到的世界！";
                                        log.info("发送消息长度: {}", lineStr.getBytes().length);
                                        ctx.channel().writeAndFlush(lineStr);
                                    }
                                }
                            });
                            ch.pipeline().addLast(new StringEncoder());
                        }
                    }).connect("127.0.0.1", 8888);

服务端

serverBootstrap.group(bossGroup, workerGroup)
        .option(ChannelOption.SO_BACKLOG, 1024)
        .childOption(ChannelOption.TCP_NODELAY, true)
        .childOption(ChannelOption.SO_KEEPALIVE, true)
        .channel(NioServerSocketChannel.class)
        .childHandler(new ChannelInitializer<NioSocketChannel>() {
            @Override
            protected void initChannel(NioSocketChannel ch) {
                ch.pipeline().addLast(new StringDecoder());
                ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                    @Override
                    protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
                        log.info("收到客户端消息：[{}]", msg);
                    }
                });
            }
        });
ChannelFuture channelFuture = serverBootstrap.bind(8888).sync();
channelFuture.channel().closeFuture().sync();

打印结果：

...
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！你好欢迎来netty到的世]
 收到客户端消息：[界！你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！]
 收到客户端消息：[你好欢迎来netty到的世界！你好欢迎来netty到的世]
 收到客户端消息：[界！]
 ...

粘包和半包产生的原因

粘包: 多个数据包被放在一起发送，好像被"粘"在了一起
半包: 正常的数据包被拆开了，只有完整包的部分数据
拆包: 正常的数据包被拆成了半包，或者需要把粘包拆成正常数据包的过程

虽然我们在应用中是一个一个包是发送的，但是计算机底层只认tcp协议，在正常情况下我们发送数据包，应该是一个包接一个包的发送，但底层的TCP协议还是按照字节流发送数据包，数据包进入底层缓冲池中，tcp定时发送，假如缓冲池满了，底层会马上发送数据包，一旦出现这种情况下，数据包只能被拆开，或者被拆开的部分跟之前的正常数据包"粘"在一起发送，那么服务端就接收到被"粘"在一起的数据包。如果我们要数据正常使用，服务端就需要把接收到的粘包拆开，得到正常的数据包以及多余的半包，半包需要等待下一次发送过来的半包，根据协议拼接回原来正常的数据包。

在这里插入图片描述

处理粘包和半包的方案

  1. 客户端发送固定长度的包，服务端解析获取到固定长度时再根据协议解析数据，流程如下
    在这里插入图片描述
    发送的数据不是一次性发送约定的长度，可能是一次发送大于约定长度，也可能分为几次发送才发送到约定长度，像下图这样

在这里插入图片描述

  1. 根据特定的分隔符来解析数据，也即读取到某个分隔符时确定该数据包已经读取完整，思路如1

  2. 把数据包分为消息头和消息体进行读取，消息头固定长度，里面有一个字段记录了接下来的消息体的长度，然后再读取到固定的消息体就为一条完整的消息

netty内置的拆包方案

1 固定长度的拆包器 FixedLengthFrameDecoder

这个拆包器对应我们讲的第一种拆包方案，都是读取到固定长度的数据时才开始解析，如果对应的需求的消息协议非常简单，可以使用这个拆包器实现

客户端

@Slf4j
public class NettyClientStr {
    public static void main(String[] args) {
        Bootstrap bootstrap = new Bootstrap();
        NioEventLoopGroup nioEventLoopGroup = new NioEventLoopGroup();

        try {
            bootstrap.group(nioEventLoopGroup)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到服务器回复 [{}]", msg);
                                }

                                @Override
                                public void channelActive(ChannelHandlerContext ctx) {
                                    for (int i= 0; i < 1000; i++) {
                                        String fixedLengthStr = "你好，欢迎来到netty的世界！";
                                        ctx.channel().writeAndFlush(fixedLengthStr);
                                    }
                                }
                            });
                            ch.pipeline().addLast(new StringEncoder());
                        }
                    }).connect("127.0.0.1", 8888).addListener(
                    future -> {
                        if (future.isSuccess()) {
                            log.info("链接服务器成功");
                        } else {
                            log.info("链接服务器失败");
                            System.exit(0);
                        }
                    }
            ).channel().closeFuture().sync();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            nioEventLoopGroup.shutdownGracefully();
        }
    }
}

服务端

@Slf4j
public class NettyServerFixedLengthFrameDecoder {

    public static void main(String[] args) {
        ServerBootstrap serverBootstrap = new ServerBootstrap();
        NioEventLoopGroup bossGroup = new NioEventLoopGroup();
        NioEventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            serverBootstrap.group(bossGroup, workerGroup)
                    .option(ChannelOption.SO_BACKLOG, 1024)
                    .childOption(ChannelOption.TCP_NODELAY, true)
                    .childOption(ChannelOption.SO_KEEPALIVE, true)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer<NioSocketChannel>() {
                        @Override
                        protected void initChannel(NioSocketChannel ch) {
                            ch.pipeline().addLast(new FixedLengthFrameDecoder(35));
                            ch.pipeline().addLast(new StringDecoder());
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {
                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到客户端消息：[{}]", msg);
                                }
                            });
                        }
                    });
            ChannelFuture channelFuture = serverBootstrap.bind(8888).sync();
            channelFuture.channel().closeFuture().sync();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            // 优雅关闭
            workerGroup.shutdownGracefully();
            bossGroup.shutdownGracefully();
        }
    }
}

客户端在启动时，向服务端重复发送1000条一样的消息，服务端收到并且解析，可以看到，这1000条消息都能被服务端正确的打印，服务端已经能够正常的解析到数据了，通过读取固定长度的消息包解决了粘包或者半包的问题

2 分隔符拆包器 DelimiterBasedFrameDecoder

对应上面第二种方式解码，netty内置了分隔符拆包器，可以自定义分隔符，当服务端接收到约定的分隔符时，就认为一条消息已经读取完毕了，对应的代码如下

客户端

@Slf4j
public class NettyClientStr {
    public static void main(String[] args) {
        Bootstrap bootstrap = new Bootstrap();
        NioEventLoopGroup nioEventLoopGroup = new NioEventLoopGroup();

        try {
            bootstrap.group(nioEventLoopGroup)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到服务器回复 [{}]", msg);
                                }

                                @Override
                                public void channelActive(ChannelHandlerContext ctx) {
                                    for (int i= 0; i < 1000; i++) {
                                        String delimiterStr = "你好，欢迎来到[demo]netty的世界！[demo]";
                                        ctx.channel().writeAndFlush(delimiterStr);
                                    }
                                }
                            });
                            ch.pipeline().addLast(new StringEncoder());
                        }
                    }).connect("127.0.0.1", 8888).addListener(
                    future -> {
                        if (future.isSuccess()) {
                            log.info("链接服务器成功");
                        } else {
                            log.info("链接服务器失败");
                            System.exit(0);
                        }
                    }
            ).channel().closeFuture().sync();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            nioEventLoopGroup.shutdownGracefully();
        }
    }
}

服务端

@Slf4j
public class NettyServerDelimiterBasedFrameDecoder {

    public static void main(String[] args) {
        ServerBootstrap serverBootstrap = new ServerBootstrap();
        NioEventLoopGroup bossGroup = new NioEventLoopGroup();
        NioEventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            serverBootstrap.group(bossGroup, workerGroup)
                    .option(ChannelOption.SO_BACKLOG, 1024)
                    .childOption(ChannelOption.TCP_NODELAY, true)
                    .childOption(ChannelOption.SO_KEEPALIVE, true)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer<NioSocketChannel>() {
                        @Override
                        protected void initChannel(NioSocketChannel ch) {
                            ch.pipeline().addLast(new DelimiterBasedFrameDecoder(Integer.MAX_VALUE, Unpooled.copiedBuffer("[demo]".getBytes())));
                            ch.pipeline().addLast(new StringDecoder());
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到客户端消息：[{}]", msg);
                                }
                            });
                        }
                    });
            ChannelFuture channelFuture = serverBootstrap.bind(8888).sync();
            channelFuture.channel().closeFuture().sync();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            // 优雅关闭
            workerGroup.shutdownGracefully();
            bossGroup.shutdownGracefully();
        }
    }
}

根据分隔符"[demo]"进行分隔消息，服务端也都解析到了这1000次发送的消息

3 行拆包器 LineBasedFrameDecoder

行拆包器也是一种分隔符拆包器，只不过它约定了读取到换行符时就认为这是一条消息的结束

客户端

@Slf4j
public class NettyClientStr {
    public static void main(String[] args) {
        Bootstrap bootstrap = new Bootstrap();
        NioEventLoopGroup nioEventLoopGroup = new NioEventLoopGroup();

        try {
            bootstrap.group(nioEventLoopGroup)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到服务器回复 [{}]", msg);
                                }

                                @Override
                                public void channelActive(ChannelHandlerContext ctx) {
                                    for (int i= 0; i < 1000; i++) {
                                        String lineStr = "你\n好\n欢\n迎\n来\n到\n的\n世\n界！";
                                        ctx.channel().writeAndFlush(lineStr);
                                    }
                                }
                            });
                            ch.pipeline().addLast(new StringEncoder());
                        }
                    }).connect("127.0.0.1", 8888).addListener(
                    future -> {
                        if (future.isSuccess()) {
                            log.info("链接服务器成功");
                        } else {
                            log.info("链接服务器失败");
                            System.exit(0);
                        }
                    }
            ).channel().closeFuture().sync();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            nioEventLoopGroup.shutdownGracefully();
        }
    }
}

服务端

@Slf4j
public class NettyServerLineBasedFrameDecoder {

    public static void main(String[] args) {
        ServerBootstrap serverBootstrap = new ServerBootstrap();
        NioEventLoopGroup bossGroup = new NioEventLoopGroup();
        NioEventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            serverBootstrap.group(bossGroup, workerGroup)
                    .option(ChannelOption.SO_BACKLOG, 1024)
                    .childOption(ChannelOption.TCP_NODELAY, true)
                    .childOption(ChannelOption.SO_KEEPALIVE, true)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer<NioSocketChannel>() {
                        @Override
                        protected void initChannel(NioSocketChannel ch) {
                            ch.pipeline().addLast(new LineBasedFrameDecoder(Integer.MAX_VALUE));
                            ch.pipeline().addLast(new StringDecoder());
                            ch.pipeline().addLast(new SimpleChannelInboundHandler<String>() {

                                @Override
                                protected void channelRead0(ChannelHandlerContext ctx, String msg) {
                                    log.info("收到客户端消息：[{}]", msg);
                                }
                            });
                        }
                    });
            ChannelFuture channelFuture = serverBootstrap.bind(8888).sync();
            channelFuture.channel().closeFuture().sync();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            // 优雅关闭
            workerGroup.shutdownGracefully();
            bossGroup.shutdownGracefully();
        }
    }
}

4 基于长度域拆包器 LengthFieldBasedFrameDecoder

这个拆包器是使用得最多的一个消息处理器，它能够处理各种通用的消息协议，下面来看看该类的构造函数以及每个构造函数的参数

public LengthFieldBasedFrameDecoder(
        ByteOrder byteOrder, int maxFrameLength, int lengthFieldOffset, int lengthFieldLength,
        int lengthAdjustment, int initialBytesToStrip, boolean failFast) {
    ...
}

我们自定义消息协议的编解码，基本上都是按照以上几个参数进行的

  1. maxFrameLength - 解析的最大帧长度，也即接收到客户端消息时，消息头和消息体长度所允许的最大长度；
  2. lengthFieldOffset - 长度域所在数据包字节数组中的下标，也就是说表示消息体长度的字段起始位置所在下下标；
  3. lengthFieldLength - 表示长度域的长度，也就是说长度域在消息头中所占的字节数；
  4. lengthAdjustment - 长度域的偏移量矫正。 如果长度域的值，除了包含有效数据域的长度外，还包含了其他域（如长度域自身）长度，那么，就需要进行矫正。它们之间的算法为：byteLength(发送的数据包长度) = lengthFieldLengthValue(长度域的值) + lengthFieldOffset(长度字段偏移量) + lengthFieldLength(长度域的长度) + lengthAdjustment
  5. initialBytesToStrip - 接收到的数据包，去除前initialBytesToStrip位
  6. failFast - true: 读取到长度域超过maxFrameLength，就抛出一个 TooLongFrameException。false: 只有真正读取完长度域的值表示的字节之后，才会抛出 TooLongFrameException，默认情况下设置为true，建议不要修改，否则可能会造成内存溢出;
  7. byteOrder - 数据存储采用大端模式还是小端模式，默认采用大端模式，没有特殊的需求，建议不要修改。

下面举例说明每个参数的用法

客户端发送的内容为 “你好,欢迎来到netty的世界”

场景一

数据包大小: 35Byte = 2Byte(一个short大小的数据长度域) + 33Byte(数据包长度)
在这里插入图片描述
由看图可以看出，解码后，数据格式以及长度没有发生变化，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=0

lengthFieldLength: 约定了为一个short类型的长度, lengthFieldLength=2(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 35 - 33 - 0 - 2 = 0

initialBytesToStrip: 由于解码前后没有改变数据包长度，此处为0

场景二

解码后去除长度域，只保留消息体(33Byte)
在这里插入图片描述
由看图可以看出，解码后，只保留了具体的消息体数据，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=0

lengthFieldLength: 约定了为一个short类型的长度, lengthFieldLength=2(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 35 - 33 - 0 - 2 = 0

initialBytesToStrip: 由于解码后丢失了2个byte的长度，所以此处为2

场景三

解码前后数据包不变，但是长度域中多存了两个字节

在这里插入图片描述
由看图可以看出，解码后，保留了完整数据包，但是长度域中被添加了一个多余的长度，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=0

lengthFieldLength: 约定了为一个short类型的长度, lengthFieldLength=2(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 35 - 35 - 0 - 2 = -2

initialBytesToStrip: 由于解码前后没有改变数据包长度，此处为0

场景四

解码前后数据包大小不变，数据包前面是一个固定大小的消息头

在这里插入图片描述
由看图可以看出，增加了一个没有使用到的消息头，解码后，保留了完整数据包，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=2

lengthFieldLength: 约定了为一个int类型的长度, lengthFieldLength=4(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 39 - 33 - 2 - 4 = 0

initialBytesToStrip: 由于解码前后没有改变数据包长度，此处为0

场景五

解码前后数据包大小不变，但是消息头在长度域和消息体中间

在这里插入图片描述
由看图可以看出，消息头在长度域和消息体之间，消息头占2个byte的长度，解码后，保留了完整数据包，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=0

lengthFieldLength: 约定了为一个int类型的长度, lengthFieldLength=4(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 39 - 33 - 0 - 4 = 2

initialBytesToStrip: 由于解码前后没有改变数据包长度，此处为0

场景六

数据包前面是消息头1，中间是长度域，再后面是消息头2，接下来才是消息体，解码后只保留消息头2和消息体
在这里插入图片描述
由看图可以看出，解码后，去除了消息头1和长度域，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=1

lengthFieldLength: 约定了为一个int类型的长度, lengthFieldLength=2(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 37 - 33 - 1 - 2 = 1

initialBytesToStrip: 由于解码后去除了消息头1(1byte)和长度域(2byte)，此处为3

场景七

数据包结构跟场景六是一样的，唯一的区别是此处的长度域的值是整个数据包的长度
在这里插入图片描述
由看图可以看出，解码后，去除了消息头1和长度域，那么，LengthFieldBasedFrameDecoder 的参数值为

maxFrameLength: 大于该数据包长度的任意值，这里给了Integer.MAX_VALUE的长度

lengthFieldOffset: 长度域的起始位置就在消息的头部，offset=1

lengthFieldLength: 约定了为一个int类型的长度, lengthFieldLength=2(byte)

lengthAdjustment: byteLength - lengthFieldLengthValue - lengthFieldOffset - lengthFieldLength = 37 - 37 - 1 - 2 = -3

initialBytesToStrip: 由于解码后去除了消息头1(1byte)和长度域(2byte)，此处为3

源码地址

@芋头@
关注
专栏目录
Netty权威指南（四）TCP粘包/拆包问题
DreamsArchitects的博客
04-05 256
TCP粘包/拆包问题解决之道一、介绍1.1 TCP粘包/拆包问题说明1.2 TCP粘包/拆包发生的原因1.3 粘包问题的解决策略二、未考虑TCP粘包导致的功能异常案例2.1 TimeServerHandler的改造2.2 TimeClientHandler的改造2.3 运行三、利用LineBasedFrameDecoder解决TCP粘包问题3.1 支持TCP粘包的TimeServer3.2 支持TCP粘包的TimeClient3.3 运行3.4 LineBasedFrameDecoder和StringDec
Netty从入门到精通三——TCP粘包/拆包
qq_44244993的博客
10-09 58
是一个网络通信框架，支持 TCP 和 UDP 两种套接字协议，在这里我主要介绍Netty对TCP的支持，首先来介绍一下TCP中的粘包拆包。④服务端两次读取到两个数据包，分别是整个D2和D1的一部分，D1的剩余部分，也发生了TCP拆包。③服务端两次读取到两个数据包，分别是D2的一部分，整个D1和剩余的D2部分，发生TCP拆包。③将特殊的分隔符作为消息结束的标志，回车换行符就是一种特殊的结束分隔符。， 进行MSS（最大报文长度）大小的TCP分段，当。③进行MSS大小的TCP分段，也要进行拆包。
消息粘包 和 消息不完整 问题
qq_34285557的博客
03-30 329
消息粘包 和 消息不完整 问题 消息粘包 和 消息不完整问题 其实都是应用层会带来的问题，和TCP 没关系，TCP 是能够保证消息的顺序 和 完整性的 本篇只是简单说明一下 什么是 消息粘包 和 消息不完整问题 1.复现消息粘包 和 消息不完成 问题 先来看看 出现了什么问题导致 需要去处理 消息粘包 和 消息完整 问题 ，前面通过NIO改造了聊天室的案例中，我们开复现一下 消息粘包 和 消息不完整 1.1 复现 消息粘包问题 Client端发送多条数据 代码还是原来的Clien
消息拆包
fengyunxiao
05-13 125
7E.....7E public static List&lt;byte[]&gt; msgUnPkg(final byte[] msg){           List&lt;byte[]&gt; msgBytes=new LinkedList&lt;byte[]&gt;();           int i=0;           int k=0,index=0;           w...
Netty——ByteBuffer（ByteBuffer消息粘包、半包示例）
小志的博客
07-26 413
Netty——ByteBuffer（ByteBuffer消息粘包、半包示例）
粘包的解决-消息定界（转）
weixin_33884611的博客
04-23 119
一.引子与协议说明 之前开发了一个项目——车载导航系统。遇到的第一个问题就是硬件设备如何与服务器通信。 关键在于通信协议！ 众所周知：要想实现通信，首先通信双方就要达成通信协议。 话不多说，且看协议： ————————————————华丽的分割线————————————————— 以上的这些协议说明是不是看得很头大呢？ 遵循如此这般的通信协议的硬件设备又如何才能与服...
关于消息封包和拆包
gongbenwen的专栏
10-17 2014
消息有多种，在应用层、传输层、
Netty入门（四） --- 编码和解码，Netty的handler调用机制，TCP粘包和拆包原理和解决
化身强盗的博客
01-25 1077
文章目录七、Google Protobuf7.1 编码和解码简介7.2 Netty本身的编解码机制和问题分析7.3 Protobuf基本介绍7.4 Protobuf发送单对象7.5 Protobuf发送多对象八、Netty编解码器和handler调用机制8.1 基本说明8.2 编解码器基本原理8.3 Netty的handler链调用机制8.4 一些简单的解码器8.4.1 ByteToMessageDecoder 解码器8.4.2 ReplayingDecoder解码器8.4.3 其他的编解码器九、TCP粘包
Netty入门（二）：TCP粘包与拆包问题处理
u010391342的博客
10-11 332
TCP粘包与拆包是什么？ Netty入门（一）：HelloWorld程序编写 上一章的demo中客户端发送了三条数据 服务端收到确是合并在一起的一条数据 这就是是TCP粘包 TCP是一个&quot;流&quot;协议，就像河流中的溪流一样，没有严格的分界线。 当我们客户端向服务端发送数据时（比如以下发送了三条数据A,B,C），原本的想法就是三条数据单独发送，服务端接收时也是接收到三条单独的数据，但是ABC会变成一...
Netty自定义通信协议(粘包拆包)
XiChuan的博客
11-07 3273
Netty自定义通信协议主要是在解码器与编码器，其他的变动不大。netty入门实例：https://blog.csdn.net/zc_ad/article/details/83824911，此处将测试的demo共享出来，现在对netty没办法到用语言组织的程度，只能先将demo贡献出来，到时候学的更加深入了，会将添加上讲解。 此demo的形成的效果是：当客户端连接服务端时，会向服务端发送自定义协...
【硬件传输数据被Netty分包】
GBK_8的博客
11-05 682
该操作应该是Netty节省内存开销设计的机制，非常有参考价值。如果之前读取完全填满了分配的缓冲区，它会逐渐增加预期的可读字节数。如果读操作不能连续两次填充分配的缓冲区的一定数量，则会逐渐减少预期的可读字节数。Netty分配的缓冲区大小不是固定的。虽然Channel被创建时回去指定的缓冲区大小默认为 1024。为什么说被Netty拆包了，因为TCP报文段的最大长度为65495字节，字节肯定没有超过这个数。硬件上报数据到系统时，数据包大小不是固定，有时对于超长的数据包，被Netty进行拆包发送了。
解决Netty消息超长导致拆成多条消息（拆包）
分享技术，记录问题，努力学习
08-24 3313
解决Netty消息超长导致拆成多条消息（拆包） 遇到问题的场景 问题的起源是因为帮朋友用socket做一个消息中转，然后就发现了他每次发送的消息都特别长导致channelread会读到多次，最开始图了省事手动去处理的拆包（这种比较恶心，要协定好消息的前缀和后缀才能去灵活的拼接消息，代码写起来也比较恶心，但是好在可以实现），然后研究了一下正常的解决方案，自定义协议 解决问题 首先双方需要协商一下协议...
JavaDemo——简单解决Netty分包问题
FlyLikeButterfly的博客
08-24 6982
  使用netty的tcp收发消息的时候发现会出现分包问题，发送三次短数据后，再发送长数据就会分包。 查询后发现大致有两种方法：一种是手动拼接包，一种是重写编解码。然后就各种百度，选择了重写编解码，自己写两个编解码，然后发现发送数据还是有问题，服务端收到的包还是少数据，未知原因。 后来在公司发现有本叫《Netty权威指南（第2版）》，翻了翻，发现可以不用重写编解码，用已经有的也可以解决分包问...
如何解决netty发送消息截断问题
weixin_30725315的博客
11-30 1127
　　 在netty开发过程中我遇到过长的消息被分割成多个小消息的问题。如下图所示： 其实这两条消息应该是一条消息，它们两个才是一个完整的json字符串。查看代码原来是客户端与服务器端都没有考虑TCP粘包与拆包机制。业界主流的解决方案包括： （1）消息定长，例如每个报文的大小固定为200字节，如果不够，空位补空格; ...
netty 接收不到客户端传来的消息_Netty客户端发送消息并同步获取结果
weixin_39658019的博客
12-20 1850
客户端发送消息并同步获取结果，其实是违背Netty的设计原则的，但是有时候不得不这么做的话，那么建议进行如下的设计：比如我们的具体用法如下：NettyRequest request = new NettyRequest();request.setRequestId(UUID.randomUUID().toString());request.setClassName(method.getDeclar...
网络通讯中粘包的处理
justlpf的专栏
11-07 1617
TCP 传输中，客户端发送数据，实际是把数据写入到了 TCP 的缓存中，由于传输的过程为数据流，经过TCP传输后，多条数据被合并成了一条，这就是数据粘包了。在网络通讯中，不仅仅是TCP通讯，也包括串口通讯中，我们经常会遇到数据包粘连的问题，本文详细介绍粘包问题产生的原因和解决办法。就像上面说的，UDP 之所以不会产生粘包和半包问题，主要是因为消息有边界，因此，我们也可以采取类似的思路。优点就是实现很简单，缺点就是空间有极大的浪费，如果传递的消息中大部分都比较短，这样就会有很多空间是浪费的。
Netty_03_ByteBuf和网络中拆包粘包问题及其解决
毛毛的专栏
12-10 1232
Netty
什么是TCP粘包/拆包？发生的原因？
最新发布
qq_73185160的博客
03-23 1010
一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题。1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.2、进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)3、以太网的payload大于MTU进行IP分片。（ MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。1、消息定长。2、在包尾部增加回车或者空格符等特殊字符进行分割3、将消息分为消息头和消息尾。
【Netty】Netty 异步任务模型 及 Future-Listener 机制
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
06-04 2732
一、 Netty 模型 、 二、 异步模型 、 三、 Future-Listener 机制 、 四、 Future-Listener 机制代码示例 、
netty tcp粘包和拆包
07-30
Netty中的TCP粘包和拆包问题是由于底层的TCP协议无法理解上层的业务数据而导致的。为了解决这个问题，Netty提供了几种解决方案。其中，常用的解决方案有四种[1]： 1. 固定长度的拆包器（FixedLengthFrameDecoder）：将每个应用层数据包拆分成固定长度的大小。这种拆包器适用于应用层数据包长度固定的情况。 2. 行拆包器（LineBasedFrameDecoder）：将每个应用层数据包以换行符作为分隔符进行分割拆分。这种拆包器适用于应用层数据包以换行符作为结束符的情况。 3. 分隔符拆包器（DelimiterBasedFrameDecoder）：将每个应用层数据包通过自定义的分隔符进行分割拆分。这种拆包器适用于应用层数据包以特定分隔符作为结束标志的情况。 4. 基于数据包长度的拆包器（LengthFieldBasedFrameDecoder）：将应用层数据包的长度作为接收端应用层数据包的拆分依据。根据应用层协议中包含的数据包长度进行拆包。这种拆包器适用于应用层协议中包含数据包长度的情况。 除了使用这些拆包器，还可以根据业界主流协议的解决方案来解决粘包和拆包问题[3]： 1. 消息长度固定：累计读取到长度和为定长LEN的报文后，就认为读取到了一个完整的信息。 2. 使用特殊的分隔符：将换行符或其他特殊的分隔符作为消息的结束标志。 3. 在消息头中定义长度字段：通过在消息头中定义长度字段来标识消息的总长度。 综上所述，Netty提供了多种解决方案来解决TCP粘包和拆包问题，可以根据具体的业务需求选择合适的解决方案[1][3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值