04、Netty学习笔记—(黏包半包及协议设计解析)
文章目录
- 一、粘包与半包
-
- 1.1、现象分析
-
- 1.1.1、粘包、半包情况分析
- 1.1.2、滑动窗口、MSS限制、Nagle算法介绍
- 1.2、粘包、半包现象复现
-
- 1.2.1、粘包复现
- 1.2.2、半包复现
- 1.3、解决方案
-
- ①短链接（连接、停止作为边界）
- ②定长解码器（指定字节长度解码）
- ③行解码器（分割符解决）
- ④LTC解码器（基于长度字段的帧解码器，长度+内容组成）
-
- 四个基础字段分析
- 实际案例
- 二、协议设计与解析
-
- 2.1、redis协议示例
- 2.2、HTTP协议示例
-
- 2.2.1、认识HttpServerCodec
- 2.2.2、案例
- 2.3、自定义协议
-
- 2.3.1、自定义协议要求
- 2.3.2、自定义消息对象（编解码器、消息抽象类、具体消息类）
- 2.3.3、案例测试（自定义编解码测试、半包问题出现及解决）
- 2.4、@Sharable：可共享handler（引出+案例demo）
netty笔记汇总：Netty学习指南(资料、文章汇总)
根据黑马程序员netty视频教程学习所做笔记，部分内容图例来源黑马笔记
笔记demo案例仓库地址： Github-【netty-learn】、Gitee-【netty-learn】
一、粘包与半包
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：
二、协议设计与解析
TCP/IP 中消息传输基于流的方式，没有边界。
协议的目的就是划定消息的边界，制定通信双方要共同遵守的通信规则。例如HTTP协议、redis通信协议、websocket协议等等。
如何设计协议呢？其实就是给网络传输的信息加上“标点符号”。但通过分隔符来断句不是很好，因为分隔符本身如果用于传输，那么必须加以区分。因此，下面一种协议较为常用
定长字节表示内容长度 + 实际内容
2.1、redis协议示例
介绍
redis对于整个命令会看成一个数组。
例：set key value
//举例：set name changlu //下面每个命令都由一个回车符、换行符分割 字节对应13,10
*3
$3
set
$4
name
$7
changlu
*3：首先需要让你发送数组的长度*表示的是命令的数量，3则是命令组成的长度。$3：$表示的是某个命令参数的长度，3表示该命令参数长度为3。- 每个命令参数都由
\r\n来进行分割
案例
案例目的：使用redis协议模拟与redis服务端进行通信，执行一条set、get命令。
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 lombok.extern.slf4j.Slf4j;
import java.nio.charset.Charset;
/**
* @ClassName Test
* @Author ChangLu
* @Date 2022/1/9 13:32
* @Description 模拟Redis客户端来向redis服务端发送一条命令
*/
@Slf4j
public class Test {
public static void main(String[] args) throws InterruptedException {
byte[] LINE = {13, 10};//两个字节表示回车，换行
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 ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx){
//向redis服务端发送一个写指令：set name changlu
set(ctx);
//向redis服务端发送一个读指令：get name
get(ctx);
}
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ByteBuf buf = (ByteBuf) msg;
log.debug("收到 {} , 消息为：{}", ctx.channel(), buf.toString(Charset.defaultCharset()));
super.channelRead(ctx, msg);
}
//执行set命令：set name changlu
private void set(ChannelHandlerContext ctx){
final ByteBuf buffer = ctx.alloc().buffer();
buffer.writeBytes("*3".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("$3".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("set".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("$4".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("name".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("$7".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("changlu".getBytes());
buffer.writeBytes(LINE);
ctx.writeAndFlush(buffer);
}
//执行get命令：get name
private void get(ChannelHandlerContext ctx){
final ByteBuf buffer = ctx.alloc().buffer();
buffer.writeBytes("*2".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("$3".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("get".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("$4".getBytes());
buffer.writeBytes(LINE);
buffer.writeBytes("name".getBytes());
buffer.writeBytes(LINE);
ctx.writeAndFlush(buffer);
}
});
}
}).connect("127.0.0.1", 6379).sync().channel();
log.debug("客户端连接成功：{}", channel);
channel.closeFuture().addListener(future -> {
group.shutdownGracefully();
});
}
}
效果：
2.2、HTTP协议示例
2.2.1、认识HttpServerCodec
HttpServerCodec：是一个编解码处理器，处理入站、出站处理器。入站处理器会对http请求进行解码
//CombinedChannelDuplexHandler组合其他两个handler，分别是InBound和OutBound 编解码处理器
public final class HttpServerCodec extends CombinedChannelDuplexHandler<HttpRequestDecoder, HttpResponseEncoder>
implements HttpServerUpgradeHandler.SourceCodec {
使用方式：
ch.pipeline().addLast(new HttpServerCodec());
浏览器发送一次请求(无论什么方法请求)实际上会解析成两部分：
若是我们重写channelRead方法，那么一个http请求就会走两次该handler方法，每次执行方法其中的Object msg分别为不同部分的解析对象
DefaultHttpRequest：解析出来请求行和请求头。LastHttpContent$1：表示请求体。（即便是get请求，请求体内容为空也会专门解析一个请求体对象）
情况一：若是想区分请求头、请求行走的handler那么就需要写一个简单的判断：
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
//DefaultHttpRequest实现了HttpRequest接口
if (msg instanceof HttpRequest){
System.out.println("请求行、头");
//LastHttpContent实现了HttpContent接口
}else if (msg instanceof HttpContent){
System.out.println("请求体");
}
super.channelRead(ctx, msg);
}
});
情况二：若是我们只对某个特定类型感兴趣的话，例如只对解析出来的DefaultHttpRequest请求体对象感兴趣，可以实现一个SimpleChannelInboundHandler
//②若是只对HTTP请求的请求头感兴趣，那么实现SimpleChannelInboundHandler实例,指明感兴趣的请求对象为HttpRequest（实际就是DefaultHttpRequest）
ch.pipeline().addLast(new SimpleChannelInboundHandler<HttpRequest>() {
@Override
protected void channelRead0(ChannelHandlerContext ctx, HttpRequest msg) throws Exception {
log.debug("解析对象类型：{}", msg.getClass());
log.debug(msg.uri());
//进行响应返回
//①构建响应对象
final DefaultFullHttpResponse response =
new DefaultFullHttpResponse(msg.protocolVersion(), HttpResponseStatus.OK);
// 响应内容
final byte[] content = "Hello,world!
".getBytes();
//设置响应头：content-length：内容长度。不设置的话浏览器就不能够知道确切的响应内容大小则会造成一直没有处理完的现象
response.headers().setInt(HttpHeaderNames.CONTENT_LENGTH, content.length);
response.content().writeBytes(content);
//②写会响应
ctx.writeAndFlush(response);
}
});
效果：
若是不设置请求头content-length指明内容长度就会出现下面问题：hello，world是能够正常显示出来的
-
应该是由于没有指定Content-length，浏览器不能够保证当前内容是全部内容，就会出现一直转圈圈等待的效果，并且响应结果也不会出现。
若是设置了的话就不会出现转圈圈现象以及检查response也会有内容：
2.2.2、案例
案例目的：服务器响应http请求并返回helloworld标签对。
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.*;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
import io.netty.handler.codec.http.*;
import lombok.extern.slf4j.Slf4j;
/**
* @ClassName Test
* @Author ChangLu
* @Date 2022/1/9 14:01
* @Description HTTP协议示例：测试协议的编解码
*/
@Slf4j
public class Test {
public static void main(String[] args) throws InterruptedException {
NioEventLoopGroup boss = new NioEventLoopGroup();
NioEventLoopGroup worker = new NioEventLoopGroup(2);
new ServerBootstrap()
.group(boss, worker)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
// ch.pipeline().addLast(new LoggingHandler());
//netty提供的对HTTP协议编解码处理器类
ch.pipeline().addLast(new HttpServerCodec());
//②若是只对HTTP请求的请求头感兴趣，那么实现SimpleChannelInboundHandler实例,指明感兴趣的请求对象为HttpRequest（实际就是DefaultHttpRequest）
ch.pipeline().addLast(new SimpleChannelInboundHandler<HttpRequest>() {
@Override
protected void channelRead0(ChannelHandlerContext ctx, HttpRequest msg) throws Exception {
log.debug("解析对象类型：{}", msg.getClass());
log.debug(msg.uri());
//进行响应返回
//①构建响应对象
final DefaultFullHttpResponse response =
new DefaultFullHttpResponse(msg.protocolVersion(), HttpResponseStatus.OK);
// 响应内容
final byte[] content = "Hello,world!
".getBytes();
//设置响应头：content-length：内容长度。不设置的话浏览器就不能够知道确切的响应内容大小则会造成一直没有处理完的现象
response.headers().setInt(HttpHeaderNames.CONTENT_LENGTH, content.length);
response.content().writeBytes(content);
//②写会响应
ctx.writeAndFlush(response);
}
});
//①对于HTTP一次请求会解析成两个对象，每个对象会走一次channelRead方法（也就是说该方法会执行两次，每次得到的msg是一个对象）
// ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
// @Override
// public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("msg.getClass() => {}", msg.getClass());
// if (msg instanceof HttpRequest){
// System.out.println("请求行、头");
// }else if (msg instanceof HttpContent){
// System.out.println("请求体");
// }
// super.channelRead(ctx, msg);
// }
// });
}
}).bind(8080);
log.debug("服务器启动成功！");
}
}
效果：
2.3、自定义协议
2.3.1、自定义协议要求
下面是自定义协议案例的协议内容：
魔数(四个字节)：用来在第一时间判定是否是无效数据包
版本号(一个字节)：可以支持协议的升级
序列化算法(一个字节)：消息正文到底采用哪种序列化反序列化方式，可以由此扩展，例如：json、protobuf、hessian、jdk
指令类型(一个字节)：是登录、注册、单聊、群聊... 跟业务相关
请求序号(四个字节)：为了双工通信，提供异步能力
对齐填充(一个字节)：除正文长度和消息正文凑满16个字节，也就是2的n次方
正文长度(四个字节)：正文的长度
消息正文：正文内容（根据序列化算法进行序列化成字节）
- 魔数：一般发送的头几个都是数字都是魔数，例如Java的二进制字节码的起始8个字节就是魔数。
- 版本号：一般用于支持协议的升级，若是协议升级可能其中的字段或者其他内容有所更改。
- 序列化算法：一般指的是消息正文，对消息正文采用特殊的格式。JDK的话缺点就是不能跨平台；谷歌出品的protobuf，其与hession都是二进制的，其可读性不好，但是字节数占用最少性能更高。
- 指令类型：消息是个什么类型，这与业务相关。
- 请求序号：例如发送是1 2 3，但是由于网络或其他因素受到的时候不是1 2 3顺序。
- 正文长度：通过正文长度知道正文接下来需要读取多少字节。
2.3.2、自定义消息对象（编解码器、消息抽象类、具体消息类）
Message：消息抽象类，定义了消息相关的一些字段内容。LoginRequestMessage：一条业务消息，实现了Message抽象类，是登陆请求消息的抽象。MessageCodec：实现了ByteToMessageCodec执行器，需要传入一个泛型，该泛型就是你要将Bytebuf转换的对象，并且其中需要你重写编解码方法，也就是解析、封装你自定义的一些协议。
Message：
import lombok.Data;
import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;
@Data
public abstract class Message implements Serializable {
/**
* 根据消息类型字节，获得对应的消息 class
* @param messageType 消息类型字节
* @return 消息 class
*/
public static Class<? extends Message> getMessageClass(int messageType) {
return messageClasses.get(messageType);
}
private int sequenceId;
private int messageType;
public abstract int getMessageType();
public static final int LoginRequestMessage = 0;
private static final Map<Integer, Class<? extends Message>> messageClasses = new HashMap<>();
}
LoginRequestMessage：
import lombok.Data;
import lombok.ToString;
/**
* @ClassName OwnMessage
* @Author ChangLu
* @Date 2022/1/9 18:07
* @Description 登陆请求消息类
*/
@Data
@ToString(callSuper = true)
public class LoginRequestMessage extends Message{
private String username;
private String password;
public LoginRequestMessage() {
}
public LoginRequestMessage(String username, String password) {
this.username = username;
this.password = password;
}
@Override
public int getMessageType() {
return LoginRequestMessage;
}
}
MessageCodec：实现了对自定义协议的编解码
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.ByteToMessageCodec;
import lombok.extern.slf4j.Slf4j;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.List;
/**
* @ClassName MessageCodec
* @Author ChangLu
* @Date 2022/1/9 15:27
* @Description 实现ByteToMessageCodec：将ByteBuf转为指定的一个对象类型（可自己指定）
*/
@Slf4j
public class MessageCodec extends ByteToMessageCodec<Message> {
/**
* 出站前将封装好的Message对象写入到ByteBuf中
* @param ctx
* @param msg 封装好的消息对象
* @param out 写入到消息对象中
* @throws Exception
*/
@Override
protected void encode(ChannelHandlerContext ctx, Message msg, ByteBuf out) throws Exception {
//1、4个字节的魔数
out.writeBytes(new byte[]{1,2,3,4});
//2、1个字节版本号：1 表示版本1
out.writeByte(1);
//3、1个字节序列化算法：0 jdk；1 json
out.writeByte(0);
//4、1个字节指令类型：在Message对象中定义
out.writeByte(msg.getMessageType());
//5、4个字节：表示请求序号
out.writeInt(msg.getSequenceId());
//获取内容的字节数组（默认直接采用JDK对象序列化方式）
final ByteArrayOutputStream baos = new ByteArrayOutputStream();
final ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(msg);
final byte[] data = baos.toByteArray();
//（额外）：为了满足2的N次方倍，要再加入一个字节凑满16个字节(除实际内容)
// 仅仅目的是为了对齐填充
out.writeByte(0xff);
//6、4个字节length内容长度
out.writeInt(data.length);
//7、写入内容
out.writeBytes(data);
}
/**
* 进行解码：之前怎么封装的就怎么取
* @param ctx
* @param in
* @param out
* @throws Exception
*/
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
final int magicNum = in.readInt();//魔术字
final byte version = in.readByte();//版本号
final byte serializerType = in.readByte();//序列号
final byte messageType = in.readByte();//消息类型
final int sequencedId = in.readInt();//请求序号
in.readByte();//填充号
final int length = in.readInt();//内容长度
final byte[] data = new byte[length];
// in.readBytes(data, 0, length);//内容（字节数组）
in.readBytes(data, 0, in.readableBytes());//内容（字节数组）
Message message = null;
//进行jdk序列化（字节数组转为对象）
if (serializerType == 0) {
final ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
message = (Message) ois.readObject();
}
out.add(message);
log.debug("{}, {}, {}, {}, {}, {}", magicNum, version, messageType, sequencedId);
log.debug("{}", message);
}
}
2.3.3、案例测试（自定义编解码测试、半包问题出现及解决）
案例1：自定义编解码器测试
/**
* 案例1：自定义编解码器测试
*/
public static void test01() throws Exception {
final EmbeddedChannel channel = new EmbeddedChannel(new LoggingHandler(), new MessageCodec());
//入站方法测试（编码）：encode()
final LoginRequestMessage message = new LoginRequestMessage("changlu", "123456");
channel.writeOutbound(message);
//出站方法测试（解码）：decode
final ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
new MessageCodec().encode(null, message, buffer);//根据协议来进行编码到ByteBuf中
final ArrayList<Object> list = new ArrayList<>();
new MessageCodec().decode(null, buffer, list);//之后对按照协议进行编码的ByteBuf进行解码取得一系列参数及对象
log.debug("解码得到的对象是：{}", list.get(0));
}
对于取出来的四个字节魔术字为16909060，原因是当时存储是一个一个字节存的1 2 3 4，有对应一个字节为8位，取得时候是直接取四个字节转为整数如下，那么整体就得到值为16909060：
案例2：解码出现半包问题及解决方案
半包问题出现原因：若是我们将一个编码过后的ByteBuf分为两个包来入站，那么每发一个包就会走一个decode()也就是解码方法，那么此时可以肯定的是由于包没有发完整，序列化字符串肯定也不完整，那么此时进行解序列化肯定就会报错出现异常！
解决半包思路：我们可以使用LTC解码器来进行解决，按照指定的长度规则来进行解码，那么之前半包会走两次handler再使用了解码器之后，由于半包不完整就会进行等待继续接收包，直到取到完整的包才会走handler那么此时执行decode解码自然不会出现序列化问题！
/**
* 案例2：解码出现半包问题及解决方案，这里仅演示解码情况
* 问题描述：若是出现半包问题，那么可能就会出现接解析序列化异常！
* 解决方案：使用LTC（基于长度的帧解码器）来解决半包、黏包问题。
*/
public static void test02() throws Exception {
final EmbeddedChannel channel = new EmbeddedChannel(
new LoggingHandler(),
//使用LTC解码器 12就是用于找到确认正文长度的字节数 4则是表示正文长度数字的字节数
new LengthFieldBasedFrameDecoder(1024, 12, 4, 0, 0),
new MessageCodec() //自定义的编解码器
);
final LoginRequestMessage message = new LoginRequestMessage("changlu", "123456");
final ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer();
new MessageCodec().encode(null, message, buffer);//根据协议来进行编码到ByteBuf中
//进行切片将数据切分为两块（问题产生源头：此时就会出现半包问题，那么接序列化就会失败）
final ByteBuf firBuf = buffer.slice(0, 100);
final ByteBuf secBuf = buffer.slice(100, buffer.readableBytes() - 100);
final ArrayList<Object> list = new ArrayList<>();
buffer.retain();
//模拟入站操作，此时就会执行decode方法
channel.writeInbound(firBuf);//执行一次writeInbound实际上就会执行release()进行释放内存，由于这里切片所以为了避免释放，在此之前进行引用计数+1
channel.writeInbound(secBuf);
}
上述对第10行进行注释时，就会出现解序列化对象失败异常：
对第10行不进行注释来使用解码器并指定长度字段：
2.4、@Sharable：可共享handler（引出+案例demo）
引出@sharable
我们之前编写代码时都会在初始化channel时添加执行器handler，添加的方式如下，我们可以看到每次都是添加到channel的pipeline管道对象中，那么就会有一个疑问：每个channel在创建之初都会添加新的handler到管道中吗？
//实际写服务端的handler
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new LoggingHandler()）
ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){}）
}
}
//EmbeddedChannel添加handler方式
final EmbeddedChannel channel = new EmbeddedChannel(
new LoggingHandler(),
new LengthFieldBasedFrameDecoder(1024, 12, 4, 0, 0),
new MessageCodec() //自定义的编解码器
);
通过debug测试可以得出结论：若是我们直接在addLast()中添加新的handler，那么就是每初始化一个连接就会创建多个新的handler对象！
那么我们可以想到一个优化思路，既然如此那么为什么我们不提前直接new出来一个handler作为多个channel的共享执行器？对的确实可以，对于我们自定义的一些执行器我们可以清楚的知道有没有使用一些共享对象，有没有线程安全问题，而对于netty提供给我们的我们不能够确定，这时候nettty给了我们思路来看其提供的handler是否是可共享、是线程安全的：实际上就是@Sharable。
结论：如果netty提供给我们的handler是可共享的，就会标注该类为@Sharable，我们可以放心大胆的创建一个公共handler来被多个channel共同使用！
- 对于LoggingHandler是有该注解的，表示是可共享的！
初使用
先学现卖，对于我们在2.3.2中自定义的编解码器就不会有线程安全问题，那么其就可以标注为@Sharable，这样其他人使用我们定义的handler也可以放心使用！
@ChannelHandler.Sharable
public class MessageCodec extends ByteToMessageCodec<Message> {
问题描述：ByteToMessageCodec这个类在初始化方法中有检测该注解的逻辑代码，一旦其实现类有@Sharable就会直接抛出异常：
分析：netty框架设计者在设计ByteToMessageCodec类时设定就是实现该类的一些编解码器正常来说都会使用到一个公共变量存储及操作，其认为本该是不可共享的，如下代码注释说明，该类不允许被标注
解决方案：那么若是我们自定义的编解码器确实没有使用到公共变量，我们想将其标注为@Sharable呢？可以将原本实现ByteToMessageCodec更改为MessageToMessageCodec
import com.changlu.No4Netty进阶.No2协议设计与解析.No1常用协议示例.No3自定义协议示例.Test.Message;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.MessageToMessageCodec;
import java.util.List;
/**
* @ClassName MessageCodec2
* @Author ChangLu
* @Date 2022/1/9 23:30
* @Description 可标注共享注解@ChannelHandler.Sharable的编解码器抽象类MessageToMessageCodec
*/
@ChannelHandler.Sharable //可以看到这里的话泛型有两个，分别用于编解码
public class MessageCodec extends MessageToMessageCodec<ByteBuf, Message> {
@Override
protected void encode(ChannelHandlerContext ctx, Message msg, List<Object> out) throws Exception {
//...
}
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf msg, List<Object> out) throws Exception {
//...
}
}
这里提供2.3.2中编解码器使用@ChannelHandler.Sharable示例：
import com.changlu.No4Netty进阶.No2协议设计与解析.No1常用协议示例.No3自定义协议示例.Test.Message;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandler;
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.MessageToMessageCodec;
import lombok.extern.slf4j.Slf4j;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.List;
/**
* @ClassName MessageCodec2
* @Author ChangLu
* @Date 2022/1/9 23:30
* @Description 可标注共享注解@ChannelHandler.Sharable的编解码器抽象类MessageToMessageCodec
*/
@Slf4j
@ChannelHandler.Sharable
public class MessageCodec2 extends MessageToMessageCodec<ByteBuf, Message> {
@Override
protected void encode(ChannelHandlerContext ctx, Message msg, List<Object> out) throws Exception {
final ByteBuf buffer = ctx.alloc().buffer();
//1、4个字节的魔数
buffer.writeBytes(new byte[]{1,2,3,4});
//2、1个字节版本号：1 表示版本1
buffer.writeByte(1);
//3、1个字节序列化算法：0 jdk；1 json
buffer.writeByte(0);
//4、1个字节指令类型：在Message对象中定义
buffer.writeByte(msg.getMessageType());
//5、4个字节：表示请求序号
buffer.writeInt(msg.getSequenceId());
//获取内容的字节数组（默认直接采用JDK对象序列化方式）
final ByteArrayOutputStream baos = new ByteArrayOutputStream();
final ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(msg);
final byte[] data = baos.toByteArray();
//（额外）：为了满足2的N次方倍，要再加入一个字节凑满16个字节(除实际内容)
// 仅仅目的是为了对齐填充
buffer.writeByte(0xff);
//6、4个字节length内容长度
buffer.writeInt(data.length);
//7、写入内容
buffer.writeBytes(data);
out.add(buffer);
}
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
final int magicNum = in.readInt();//魔术字
final byte version = in.readByte();//版本号
final byte serializerType = in.readByte();//序列号
final byte messageType = in.readByte();//消息类型
final int sequencedId = in.readInt();//请求序号
in.readByte();//填充号
final int length = in.readInt();//内容长度
final byte[] data = new byte[length];
// in.readBytes(data, 0, length);//内容（字节数组）
in.readBytes(data, 0, in.readableBytes());//内容（字节数组）
Message message = null;
//进行jdk序列化（字节数组转为对象）
if (serializerType == 0) {
final ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
message = (Message) ois.readObject();
}
out.add(message);
log.debug("{}, {}, {}, {}, {}, {}", magicNum, version, messageType, sequencedId);
log.debug("{}", message);
}
}
最后再附上引子引出案例的改进代码：此时之后每来临一个channel就都直接该指定的一个执行器
//抽离出来logginghandler
final LoggingHandler loggingHandler = new LoggingHandler();
//...
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(loggingHandler)
ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){}）
}
}
//对于EmbeddedChannel也是同理
final LoggingHandler loggingHandler = new LoggingHandler();
final MessageCodec2 messageCodec2 = new MessageCodec2();
final EmbeddedChannel channel = new EmbeddedChannel(
loggingHandler,
new LengthFieldBasedFrameDecoder(1024, 12, 4, 0, 0),
messageCodec2 //自定义的编解码器
);
整理者：长路 时间：2021.1.8-1.9
我是长路，感谢你的耐心阅读。如有问题请指出，我会积极采纳！
欢迎关注我的公众号【长路Java】，分享Java学习文章及相关资料
Q群：851968786 我们可以一起探讨学习
注明：转载可，需要附带上文章链接