LengthFieldBasedFrameDecoder

原文链接:https://www.cnblogs.com/crazymakercircle/p/10294745.html

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个字节的长度域长。