LengthFieldBasedFrameDecoder 详解
疯狂创客圈 Java 分布式聊天室【 亿级流量】实战系列之 -31【 博客园 总入口 】
写在前面
大家好，我是作者尼恩。目前和几个小伙伴一起，组织了一个高并发的实战社群【疯狂创客圈】。正在开始高并发、亿级流程的 IM 聊天程序 学习和实战
有的小伙伴对帧解码器FrameDecoder ，尤其是LengthFieldBasedFrameDecoder（自定义长度帧解码器） 不是太了解，尤其是觉得LengthFieldBasedFrameDecoder 参数多，不理解。
这里单独撰文，对LengthFieldBasedFrameDecoder 的参数，进行重点介绍。看完之后，就会彻底的了解了。
1.1.1. 解码器：FrameDecoder
前面所讲的解码器，在获取入站数据时，都是通过ByteBuf的基础类型读取方法，读取到是基础的数据类型，比如int整数。如果在解码时，读取的不是基础类型，而是非常基础的二进制数据，该如何处理呢？
大家都知道，TCP协议是个“流”性质协议，它的底层根据二进制缓冲区的实际情况进行包的划分，会把上层（Netty层）的ByteBuf包，进行重新的划分和重组，组成一帧一帧的二进制数据。换句话说，一个上层Netty中的 ByteBuf包，可能会被TCP底层拆分成多个二进制数据帧进行发送；也有可能，底层将多个小的ByteBuf包，封装成一个大的底层数据帧发送出去。
问题来了：如何从底层的二进制数据帧中，界定出来上层数据包的边界，也即是上层包的起点和末尾呢？别急，界定的办法，还是很多的。比如说，简单一点方法就是规定上层数据包的长度。例如，规定每个上层数据包的长度为100byte。再比如说，可以规定上层包的分割符号，比如换行符。无论采用什么方法，最为重要的是，发送方和接收方，在界定方法上必须保持一致。
Netty中，提供了几个重要的可以直接使用的帧解码器。这里先介绍一个最为基础的，它就是LineBasedFrameDecoder。LineBasedFrameDecoder的工作原理很简单，依次遍历原始ByteBuf（代表底层帧）中的可读字节，判断看是否存在“\n”或者“\r\n”换行符，也就是上层包的边界的分割符。如果有，就以此位置为结束位置，从可读索引到结束位置区间的字节就组成了一行。同时，它支持配置上层包的最大长度。如果连续读取到最大长度后仍然没有发现换行符，就会抛出异常。
下面演示一下LineBasedFrameDecoder的使用，代码如下：
/**
* create by 尼恩 @ 疯狂创客圈
**/
package com.crazymakercircle.NettyTest;
//...
public class TestDecoder {
@Test
public void testLineBasedFrameDecoder() {
//...
ChannelInitializer i = new ChannelInitializer<EmbeddedChannel>() {
protected void initChannel(EmbeddedChannel ch) {
ch.pipeline().addLast(new LineBasedFrameDecoder(1024));
ch.pipeline().addLast(new StringDecoder());
ch.pipeline().addLast(new StringProcessHandler());
}
};
EmbeddedChannel channel = new EmbeddedChannel(i);
for (int j = 0; j < 100; j++) {
ByteBuf buf = Unpooled.buffer();
String s = "I am " + j;
buf.writeBytes(s.getBytes("UTF-8"));
buf.writeBytes("\r\n".getBytes("UTF-8"));
channel.writeInbound(buf);
}
//...
}
实例中，向channel写入100个入站数据包，每一个入站包都以"\r\n"回车换行符作为结束。channel的LineBasedFrameDecoder 解码器，会将"\r\n"作为分割符，分割出一个一个的入站ByteBuf，然后发送给StringDecoder。StringDecoder会将分割好的ByteBuf二进制数据，转成字符串，发送给StringProcessHandler 。最后，由StringProcessHandler负责将字符串展示出来。
这里，LineBasedFrameDecoder 和StringDecoder 都是Netty自带的类。特别要说下的，就是StringDecoder，它的作用是将接收到ByteBuf二进制数据，转换成字符串。另外，LineBasedFrameDecoder ，是一个非常简单的帧解码器，包含此解码器在内，Netty中比较常用的帧解码器，大致如下：
（1）固定长度帧解码器 - FixedLengthFrameDecoder
适用场景：每个上层数据包的长度，都是固定的，比如 100。在这种场景下，只需要把这个解码器加到 pipeline 中，Netty 会把底层帧，拆分成一个个长度为 100 的数据包 (ByteBuf)，发送到下一个 channelHandler入站处理器。
（2）行分割帧解码器 - LineBasedFrameDecoder
适用场景：每个上层数据包，使用换行符或者回车换行符做为边界分割符。发送端发送的时候，每个数据包之间以换行符/回车换行符作为分隔。在这种场景下，只需要把这个解码器加到 pipeline 中，Netty 会使用换行分隔符，把底层帧分割成一个一个完整的应用层数据包，发送到下一站。前面的例子，已经对这个解码器进行了演示。
（3）自定义分隔符帧解码器 - DelimiterBasedFrameDecoder
DelimiterBasedFrameDecoder 是LineBasedFrameDecoder的通用版本。不同之处在于，这个解码器，可以自定义分隔符，而不是局限于换行符。如果使用这个解码器，在发送的时候，末尾必须带上对应的分隔符。
（4）自定义长度帧解码器 - LengthFieldBasedFrameDecoder
这是一种基于灵活长度的解码器。在数据包中，加了一个长度字段（长度域），保存上层包的长度。解码的时候，会按照这个长度，进行上层ByteBuf应用包的提取。
1.1.1. 难点：自定义长度帧解码器
在前面的四个帧解码器中，第四个解码器LengthFieldBasedFrameDecoder（自定义长度帧解码器）的参数比较多，比较难，同时也比较重要，这里对其进行重点介绍。
下面是一个简单的使用实例，代码如下：
/**
* create by 尼恩 @ 疯狂创客圈
**/
package com.crazymakercircle.NettyTest;
public class TestDecoder {
//...
@Test
public void testLengthFieldBasedFrameDecoder() {
try {
LengthFieldBasedFrameDecoder spliter=new LengthFieldBasedFrameDecoder(1024,0,4,0,4);
ChannelInitializer i = new ChannelInitializer<EmbeddedChannel>() {
protected void initChannel(EmbeddedChannel ch) {
ch.pipeline().addLast(spliter);
ch.pipeline().addLast(new StringDecoder(Charset.forName("UTF-8")));
ch.pipeline().addLast(new StringProcessHandler());
}
};
EmbeddedChannel channel = new EmbeddedChannel(i);
for (int j = 0; j < 100; j++) {
ByteBuf buf = Unpooled.buffer();
String s = "呵呵,I am " + j;
byte[] bytes = s.getBytes("UTF-8");
buf.writeInt(bytes.length);
buf.writeBytes(bytes);
channel.writeInbound(buf);
}
//...
}
上面用到的自定义长度解码器LengthFieldBasedFrameDecoder构造器，涉及5个参数，都与长度域（数据包中的长度字段）相关，具体介绍如下：
（1） maxFrameLength - 发送的数据包最大长度；
（2） lengthFieldOffset - 长度域偏移量，指的是长度域位于整个数据包字节数组中的下标；
（3） lengthFieldLength - 长度域的自己的字节数长度。
（4） lengthAdjustment – 长度域的偏移量矫正。 如果长度域的值，除了包含有效数据域的长度外，还包含了其他域（如长度域自身）长度，那么，就需要进行矫正。矫正的值为：包长 - 长度域的值 – 长度域偏移 – 长度域长。
（5） initialBytesToStrip – 丢弃的起始字节数。丢弃处于有效数据前面的字节数量。比如前面有4个节点的长度域，则它的值为4。
在上面的例子中，自定义长度解码器的构造参数值如下：
LengthFieldBasedFrameDecoder spliter=new LengthFieldBasedFrameDecoder(1024,0,4,0,4);
第一个参数为1024，表示数据包的最大长度为1024；第二个参数0，表示长度域的偏移量为0，也就是长度域放在了最前面，处于包的起始位置；第三个参数为4，表示长度域占用4个字节；第四个参数为0，表示长度域保存的值，仅仅为有效数据长度，不包含其他域（如长度域）的长度；第五个参数为4，表示最终的取到的目标数据包，抛弃最前面的4个字节数据，长度域的值被抛弃。
为了更加清楚的说明一下上面的规则，调整一下例子中的代码。在写入通道前，在数据包的最前面，加上两个字节，作为包头Head。另外，写入的长度值，包含长度域自身的长度，也就是加上4。 修改后的代码如下：
/**
* create by 尼恩 @ 疯狂创客圈
**/
//...
for (int j = 0; j < 100; j++) {
ByteBuf buf = Unpooled.buffer();
String s = j+ " is me ,呵呵" ;
byte[] bytes = s.getBytes("UTF-8");
buf.writeChar(100);
buf.writeInt(bytes.length+4);
buf.writeBytes(bytes);
}
为了完成正确的解码，需要调整自定义长度解码器的构造参数值，调整如下：
LengthFieldBasedFrameDecoder spliter=new LengthFieldBasedFrameDecoder(1024,2,4,-4,6);
第一、第二、第三个参数比较简单，不再啰嗦。
第四个参数长度域的矫正值为 -4，为什么呢？ 它计算的方法是：包长（X+2）- 长度域的值（X） – 长度域偏移（2） – 长度域长（4）= -4 。
这里假定长度域的值为X，那么包长为X+2。因为在这个例子中，长度域的值，已经包括了长度域的长度值。长度域值与整个包长度相比，就少了前面的Header的2个字节。按照公式进行计算，最终的值为 2-2-4 = -4 。
第五个参数丢弃的起始字节数为6，为什么呢？ 因为，最终的有效的应用层数据，需要去掉前面的6个字节。其中，包括2个字节的Header，4个字节的长度域长。
来源：https://www.cnblogs.com/xuxinstyle/p/10998524.html