一、粘包与半包

1.1、现象分析

1.1.1、粘包、半包情况分析

粘包

现象，发送 abc def，接收 abcdef。（明明是多次发送请求，服务器端一次就全部接收了）

原因：列举三种情况

应用层原因：接收方 ByteBuf 设置太大（Netty 默认 1024），直接将多个请求的数据统一直接处理。

TCP原因：

滑动窗口：假设发送方 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.1.2、滑动窗口、MSS限制、Nagle算法介绍

滑动窗口（可导致黏包、半包）

引用应答的机制，吞吐量就会受到影响，那么消息的发送就是串行的，如何解决问题？tcp中引用了一个滑动窗口解决问题

滑动窗口起到了一个缓冲区作用，能够起到流量控制的作用，不止于让你的数据发送的太快，也不至于让你的数据一问一答的方式太慢。底层就是发送缓冲区和接收缓冲区。窗口内的数据才会被允许发送，应答还没有到达，窗口不会向下滑动了，应答回来之后窗口就可以继续向下了。

发送、接收方都会维护一个窗口，落在窗口内的数据才会被接收

黏包、半包就与滑动窗口有联系：

如果网络比较繁忙，比如接收方的窗口用完了不能够继续向下滑动势必接收到的数据就会发生半包现象。

黏包也有关系：若是滑动窗口比较空闲，有很多的空间还没有使用，这时候客户端发送了好几条数据过来，滑动窗口将这几条数据都接收到了，此时就产生了黏包现象。

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 头后剩余能够作为数据传输的字节数。

MSS值自适应：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.2、粘包、半包现象复现

1.2.1、粘包复现

案例描述：客户端连续发送多条数据，服务端就会产生粘包现象。

server：
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
import io.netty.handler.logging.LoggingHandler;
/**
 * @ClassName Server
 * @Author ChangLu
 * @Date 2022/1/8 14:57
 * @Description Server：黏包现象复现
 */
public class Server {
    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：
import io.netty.bootstrap.Bootstrap;
import io.netty.buffer.ByteBuf;
import io.netty.channel.Channel;
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.nio.NioSocketChannel;
import io.netty.handler.codec.string.StringEncoder;
import lombok.extern.slf4j.Slf4j;
/**
 * @ClassName Client
 * @Author ChangLu
 * @Date 2022/1/8 9:49
 * @Description Client：客户端连接，批量发送数据
 */
@Slf4j
public class Client {
    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);
                                }
                                log.debug("finish!");
                            }
                        });
                    }
                }).connect("127.0.0.1", 8080).sync().channel();
        log.debug("客户端连接成功：{}", channel);
        channel.closeFuture().addListener(future -> {
            group.shutdownGracefully();
        });
    }
}

效果：

1.2.2、半包复现

像这种客户端连续发送多条数据，服务端也会出现半包现象。如何造成呢，我们若是指定系统接收缓冲区接收大小，那么就会不仅仅有粘包现象还有半包现象：

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

此时我们重启服务端，再使用客户端发送一次：

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

1.3、解决方案

方案列举：

短链接：发一个包建立一次连接，这样连接建立到连接断开之间就是消息的边界，缺点效率太低

定长解码器：每一条消息采用固定长度，缺点浪费空间

行解码器：每一条消息采用分隔符，例如 \n，缺点需要转义

LTC解码器：每一条消息分为 head 和 body，head 中包含 body 的长度

①短链接（连接、停止作为边界）

tcp之所以有黏包、半包是因为消息没有边界，那么短链接这种方式可以人为的让消息从连接、建立、断开作为消息边界。

思路：原本一个连接发送10条数据，更改为建立10次连接，每次连接发送一条数据。

若是不进行自己控制窗口的大小，默认接收端与发送端也会进行窗口大小的协商，来进行自适应一个窗口大小。现在操作系统也比较智能，能够自行的进行调整。

优缺点：效率低，虽然能够解决黏包问题，但是还是不能够避免半包问题。其消息边界就是连接-建立-结束。

代码：

server：
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.AdaptiveRecvByteBufAllocator;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelOption;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
import io.netty.handler.logging.LoggingHandler;
/**
 * @ClassName Server
 * @Author ChangLu
 * @Date 2022/1/8 14:57
 * @Description Server：黏包现象复现
 */
public class Server {
    public static void main(String[] args) throws InterruptedException {
        new ServerBootstrap()
                //设置ByteBuf缓冲区为16字节（调整netty的接收缓冲区后（小于客户端一次发送的大小）：那么也会出现半包情况，但所幸数据是不会丢的。）
                .childOption(ChannelOption.RCVBUF_ALLOCATOR, new AdaptiveRecvByteBufAllocator(16, 16, 16))
                .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：
import io.netty.bootstrap.Bootstrap;
import io.netty.buffer.ByteBuf;
import io.netty.channel.Channel;
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.nio.NioSocketChannel;
import io.netty.handler.codec.string.StringEncoder;
import lombok.extern.slf4j.Slf4j;
/**
 * @ClassName Client
 * @Author ChangLu
 * @Date 2022/1/8 9:49
 * @Description 短链接：发送一次请求数据，就重新断开重启，以连接、重启作为消息分割
 */
@Slf4j
public class Client {
    public static void main(String[] args) throws InterruptedException {
        //每发送一个请求，就需要重新建立连接发送，以建立连接、断开连接作为边界！
        for (int i = 0; i < 10; i++) {
            send();
        }
    }
    private static void send() 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 {
                                //发送16个字节
                                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);
                                ctx.channel().close();
                                group.shutdownGracefully();
                                log.debug("finish!");
                            }
                        });
                    }
                }).connect("127.0.0.1", 8080).sync().channel();
        log.debug("客户端连接成功：{}", channel);
        channel.closeFuture().addListener(future -> {
            group.shutdownGracefully();
        });
    }
}

②定长解码器（指定字节长度解码）

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

思路：客户端给每个发送的数据封装成定长的长度(多余的使用分隔符，统一规定)最后统一通过一个ByteBuf发送出去；服务端的话通过使用FixedLengthFrameDecoder来进行固定长度解析，那么每次自然也就解析到定长的Bytebuf来进行处理。

方案：服务器与客户端作一个长度约定，服务端只有收到固定长度的才会接收完毕，否则也会进行等待直到够一定长度才向下一个handler传递；若是一次接收到的长度过大，ByteBuf也只会截取固定长度的内容并对下一个handler进行传递，多出来的部分会留着后序发来的数据再进行组合。

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

代码：测试使用FixedLengthFrameDecoder固定长度解析器。

server：
/**
 * @ClassName Server
 * @Author ChangLu
 * @Date 2022/1/8 14:57
 * @Description Server：黏包现象复现
 */
public class Server {
    public static void main(String[] args) throws InterruptedException {
        new ServerBootstrap()
                .group(new NioEventLoopGroup(), new NioEventLoopGroup(2))
                .channel(NioServerSocketChannel.class)
                .childHandler(new ChannelInitializer<NioSocketChannel>() {
                    @Override
                    protected void initChannel(NioSocketChannel ch) {
                        //使用定长解码器：固定设置为10个字节，也就是每次读事件都会拿到10个字节长度的ByteBuf
                        ch.pipeline().addLast(new FixedLengthFrameDecoder(10));
                        ch.pipeline().addLast(new LoggingHandler());
                    }
                })
                .bind(8080).sync();
        System.out.println("服务器启动成功！");
    }
}

client：将多个定长的内容写入到一个ByteBuf中并进行一次发出

import io.netty.bootstrap.Bootstrap;
import io.netty.buffer.ByteBuf;
import io.netty.channel.Channel;
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.nio.NioSocketChannel;
import io.netty.handler.codec.string.StringEncoder;
import lombok.extern.slf4j.Slf4j;
import java.util.Arrays;
import java.util.Random;
/**
 * @ClassName Client
 * @Author ChangLu
 * @Date 2022/1/8 9:49
 * @Description 短链接：发送一次请求数据，就重新断开重启，以连接、重启作为消息分割
 */
@Slf4j
public class Client {
    public static void main(String[] args) throws InterruptedException {
        send();
    }
    private static void send() 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());
                        ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                            @Override
                            public void channelActive(ChannelHandlerContext ctx) throws Exception {
                                ByteBuf buffer = ctx.alloc().buffer();
                                char c = '0';
                                final Random r = new Random();
                                //生成10个定长的字节数组全部写入到一个ByteBuf中，最后发送出去
                                //目的：检验服务器能否每次取到定长ByteBuf
                                for (int i = 0; i < 10; i++) {
                                    final byte[] bytes = fill10Bytes(c, r.nextInt(10) + 1);
                                    buffer.writeBytes(bytes);
                                    c++;
                                }
                                ctx.channel().writeAndFlush(buffer);
                            }
                        });
                    }
                }).connect("127.0.0.1", 8080).sync().channel();
        log.debug("客户端连接成功：{}", channel);
        channel.closeFuture().addListener(future -> {
            group.shutdownGracefully();
        });
    }
    /**
     * 生成len个指定c字符，定长为10，多余部分使用"_"填充
     * @param c 填充字符
     * @param len 字符长度
     * @return 填充好的字节数组
     */
    public static byte[] fill10Bytes(char c, int len){
        final byte[] bytes = new byte[10];
        Arrays.fill(bytes, (byte) '_');
        for (int i = 0; i < len; i++) {
            bytes[i] = (byte) c;
        }
        System.out.println(new String(bytes));
        return bytes;
    }
}

③行解码器（分割符解决）

行解码器（分隔符解决）使用分隔符来作为消息的边界。

在Netty中提供了两个解码器：

LineBasedFrameDecoder：指定以换行符作为分隔符。\n或者\r\n，使用它的时候，会有一个最大长度限制，若是超过了字长长度还没有找到换行符就会抛出一个异常

DelimiterBasedFrameDecoder：可以自定义符号来作为分隔符，在构造方法中有最大长度何一个Bytebuf类型的分隔符.

缺点：效率比较低，需要一个一个字节去找消息的边界！

代码：

import io.netty.buffer.ByteBuf;
import io.netty.buffer.ByteBufAllocator;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.DelimiterBasedFrameDecoder;
import io.netty.handler.codec.LineBasedFrameDecoder;
import io.netty.handler.logging.LoggingHandler;
import java.util.Arrays;
import java.util.Random;
/**
 * @ClassName Test
 * @Author ChangLu
 * @Date 2022/1/9 0:14
 * @Description LineBasedFrameDecoder（默认\n分隔符）、DelimiterBasedFrameDecoder（自定义分隔符）测试
 */
public class Test {
    public static void main(String[] args) {
        //测试一：LineBasedFrameDecoder
        testLineBasedFrameDecoder();
        //测试二：DelimiterBasedFrameDecoder
//        testDelimiterBasedFrameDecoder();
    }
    /**
     * 测试DelimiterBasedFrameDecoder界定符解码器：可自定义界定符（界定符为ByteBuf类型传入）
     */
    public static void testDelimiterBasedFrameDecoder(){
        char delimiter = '_';
        final ByteBuf buffer = getByteBufByDelimiter(delimiter);
        final ByteBuf delimiterByteBuf = ByteBufAllocator.DEFAULT.buffer().writeByte(delimiter);
        // DelimiterBasedFrameDecoder：参数一为检测的最大长度（若是超过最大长度还检测不到指定界定符直接抛异常），参数二为界定符
        final EmbeddedChannel channel = new EmbeddedChannel(new DelimiterBasedFrameDecoder(11, delimiterByteBuf), new LoggingHandler());
        // 模拟入站操作
        channel.writeInbound(buffer);
    }
    /**
     * 测试LineBasedFrameDecoder换行解码器：默认以\n作为分割。（）
     */
    public static void testLineBasedFrameDecoder(){
        final ByteBuf buffer = getByteBufByDelimiter('\n');
        // LineBasedFrameDecoder：换行解码器。这里构造器中填写的是检测最大长度，若是超过最大长度还检测不到直接抛异常
        final EmbeddedChannel channel = new EmbeddedChannel(new LineBasedFrameDecoder(11), new LoggingHandler());
        // 模拟入站操作
        channel.writeInbound(buffer);
    }
    private static ByteBuf getByteBufByDelimiter(char delimiter) {
        final ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
        Random r = new Random();
        char c = 'a';
        for (int i = 0; i < 10; i++) {
            buffer.writeBytes(makeRandomBytes(r, c, delimiter));
            c++;
        }
        return buffer;
    }
    /**
     * 构造随机长度的字节数组末尾添加分隔符"\n"作为区分
     * @param r
     * @param c 随机字符
     * @param delimiter 界定符
     * @return
     */
    public static byte[] makeRandomBytes(Random r, char c, char delimiter){
        final int num = r.nextInt(10) + 1;
        final byte[] data = new byte[num + 1];
        //填充[0, num)区间
        Arrays.fill(data, 0, num, (byte) c);
        data[num] = (byte) delimiter;
        System.out.println(new String(data));
        return data;
    }
}

效果：

demo1，测试换行界定符解码器

demo2：测试指定界定符解码器

可以看到每次读取到的内容并不包含界定符，直接给我们过滤掉了。

④LTC解码器（基于长度字段的帧解码器，长度+内容组成）

四个基础字段分析

LTC解码器：LengthFieldBasedFrameDecoder（基于长度字段的帧解码器）

两个部分组成：[长度，内容]。其中要设置一些值。四个参数：①偏记录长度的偏移量；②长度本身占用的字节数；③调整长度，长度之后有几个字节才是内容；④从头开始省略掉的字节数量。

lengthFiedldOffest：长度字段偏移量
lengthFieldLength：长度字段长度
lengthAdjustment：长度字段为基准，还有几个字节是内容
initialBytesToStrip：从头剥离几个字节

源码demo分析：

// 整条消息是14个字节，头部占了2个字节表示内容的长度。
// lengthFieldLength=2：意思是告知该解码器，我的head头部占用了两个字节去解析它拿到内容的长度，那么就能够解析指定边界的一条消息。
* <b>lengthFieldOffset</b>   = <b>0</b>
 * <b>lengthFieldLength</b>   = <b>2</b>
 * lengthAdjustment    = 0
 * initialBytesToStrip = 0 (= do not strip header)
 *
 * BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)
 * +--------+----------------+      +--------+----------------+
 * | Length | Actual Content |----->| Length | Actual Content |
 * | 0x000C | "HELLO, WORLD" |      | 0x000C | "HELLO, WORLD" |
 * +--------+----------------+      +--------+----------------+
// 0202：基于第一个demo，initialBytesToStrip=2也就是最后解析出来过滤掉前2个字节，也就是head头部，最终直接取得对应内容。
 * BEFORE DECODE (14 bytes)         AFTER DECODE (12 bytes)
 * +--------+----------------+      +----------------+
 * | Length | Actual Content |----->| Actual Content |
 * | 0x000C | "HELLO, WORLD" |      | "HELLO, WORLD" |
 * +--------+----------------+      +----------------+
// 2300：实际上有些协议还会带上一些魔术字以及其他内容，该案例里多增加了一个head 1部分(length左边)，lengthFieldOffset=2表示的是最前面多增加了2个字节长度的字段，lengthFieldLength=3则是表示内容长度的值所占用的字节数，这里的话最终解析出来就是完整的一条 新字段+内容长度+内容的一条消息
 * BEFORE DECODE (17 bytes)                      AFTER DECODE (17 bytes)
 * +----------+----------+----------------+      +----------+----------+----------------+
 * | Header 1 |  Length  | Actual Content |----->| Header 1 |  Length  | Actual Content |
 * |  0xCAFE  | 0x00000C | "HELLO, WORLD" |      |  0xCAFE  | 0x00000C | "HELLO, WORLD" |
 * +----------+----------+----------------+      +----------+----------+----------------+
//0320：lengthAdjustment=2，表示在长度Length之后偏移指定字节开始读取指定长度的内容。你可以看到此时header1在length长度的右边，这就是lengthAdjustment用处。
 * BEFORE DECODE (17 bytes)                      AFTER DECODE (17 bytes)
 * +----------+----------+----------------+      +----------+----------+----------------+
 * |  Length  | Header 1 | Actual Content |----->|  Length  | Header 1 | Actual Content |
 * | 0x00000C |  0xCAFE  | "HELLO, WORLD" |      | 0x00000C |  0xCAFE  | "HELLO, WORLD" |
 * +----------+----------+----------------+      +----------+----------+----------------+
//综合案例
 * BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)
 * +------+--------+------+----------------+      +------+----------------+
 * | HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
 * | 0xCA | 0x000C | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |
 * +------+--------+------+----------------+      +------+----------------+
//分析：总共有四个部分(各个部分字节长度为1 3 1 12)，那么想要读取到内容长度为多少需要一开始就偏移1个字节(lengthFieldOffset)，接着我们需要确定内容的真实长度就需要解析3个字节(lengthFieldLength)的表示长度的数字(解析出来知道了有12字节为内容)，紧接着由于Length之后还有一个额外字段，想要读取到内容还需要基于Length之后再偏移1个字节(lengthAdjustment)开始读取。最终实际读取写入到ByteBuf是Length之后的内容，那么我们需要剥离HDR1 和 Length部分，也就是3个字节(initialBytesToStrip)
//最终：为1213

实际案例

有了这四个部分其实我们就可以自己去定义一些协议了！

案例目的：测试LengthFieldBasedFrameDecoder对指定内容长度的解析！

包含两个demo

组合一：length msg，最终取出msg。
组合二：head1 length head2 msg，最终取出msg。
import io.netty.buffer.ByteBuf;
import io.netty.buffer.ByteBufAllocator;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.LengthFieldBasedFrameDecoder;
import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler;
import static com.changlu.No3Netty入门.No2Netty组件.ByteBuf.ByteBufTest.log;
/**
 * @ClassName Test
 * @Author ChangLu
 * @Date 2022/1/9 8:54
 * @Description LengthFieldBasedFrameDecoder测试：基于长度字段帧解码器，指定内容长度
 */
public class Test {
    public static void main(String[] args) {
//        test01();
        test02();
    }
    /**
     * demo2：读取（head1 length head2 msg）组合中的msg
     */
    public static void test02(){
        LengthFieldBasedFrameDecoder decoder = new LengthFieldBasedFrameDecoder(1024, 1, 4, 1, 6);
        EmbeddedChannel channel = new EmbeddedChannel(decoder, new LoggingHandler(LogLevel.DEBUG));
        ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
        //插入三条数据
        writeMsg2(buffer, "changlu");
        writeMsg2(buffer, "liner");
        writeMsg2(buffer, "love");
        System.out.println("\n---------------------------发送数据-----------------------------");
        log(buffer);
        System.out.println("---------------------------发送数据-----------------------------\n");
        channel.writeInbound(buffer);
    }
    /**
     * demo1：读取（length msg）组合中的msg
     */
    public static void test01(){
        //构造参数：1024 0 4 0 4，参数一指的是检测最大容量，之后则是基础四个配置参数
        LengthFieldBasedFrameDecoder decoder = new LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4);
        EmbeddedChannel channel = new EmbeddedChannel(decoder, new LoggingHandler(LogLevel.DEBUG));
        ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
        //插入两条数据
        writeMsg1(buffer, "changlu");
        writeMsg1(buffer, "liner");
        System.out.println("\n---------------------------发送数据-----------------------------");
        log(buffer);
        System.out.println("---------------------------发送数据-----------------------------\n");
        channel.writeInbound(buffer);
    }
    /**
     * 内容组成：length msg
     * @param buffer
     * @param msg
     */
    private static void writeMsg1(ByteBuf buffer, String msg) {
        final int length = msg.length();
        buffer.writeInt(length);//实际长度：注意这里writeint写的是int类型，占用四个字节
        buffer.writeBytes(msg.getBytes());//实际内容
    }
    /**
     * 内容组成 head1 length head2 msg
     * @param buffer
     * @param msg
     */
    private static void writeMsg2(ByteBuf buffer, String msg) {
        final int length = msg.length();
        int head1 = 1;
        int head2 = 2;
        //写入四个内容：head1 length head2 msg，最终要读取到msg信息
        buffer.writeByte(head1);
        buffer.writeInt(length);//实际长度：注意这里writeint写的是int类型，占用四个字节
        buffer.writeByte(head2);
        buffer.writeBytes(msg.getBytes());//实际内容
    }
}

demo1：

demo2：

04、Netty学习笔记—(黏包半包及协议设计解析)（一）

一、粘包与半包

1.1、现象分析

1.1.1、粘包、半包情况分析

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

1.2、粘包、半包现象复现

1.2.1、粘包复现

1.2.2、半包复现

1.3、解决方案

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

04、Netty学习笔记—(黏包半包及协议设计解析)（一）

一、粘包与半包

1.1、现象分析

1.1.1、粘包、半包情况分析

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

1.2、粘包、半包现象复现

1.2.1、粘包复现

1.2.2、半包复现

1.3、解决方案

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像