数据包编解码过程中主要的工作就是:在编码过程中进行序列化,在解码过程中从Byte流中分离出数据包然后反序列化。在MessageToByteEncoder中,已经解决了序列化之后的问题,ByteToMessageDecoder中已经部分第解决了从Byte流中分离出数据包的问题。实现具体的数据包编解码,只需要实现MessageToByteEncoder的encode和ByteToMessageDecoder的decode方法即可。

  为了方便开发者使用Netty,在io.netty.handler.codec包中已经实现了一些开箱即用的编解码ChannelHandler,这些Handler包括:

  1. FixedLengthFrameDecoder : 固定长度的数据包解码。
  2. LengthFieldPrepender, LengthFieldBasedFrameDecoder: 带有长度字段的数据包编解码。
  3. LineBasedFrameDecoder: 以行字符串为一个数据包解码。
  4. StringEncoder, StringDecoder: 字符集转换器。
  5. Base64Encoder, Base64Decoder: Base64编码转换器。
  6. ProtobufEncoder, ProtobufDecoder: protoBuf序列化格式数据包的编解码。
  7. ZlibEncoder,ZlibDecoder: zlib压缩格式数据包的编解码。
  8. SnappyFramedEncoder,SnappyFramedDecoder: Snappy压缩格式数据包的编解码。

  接下来让我们来分析几个关键ChannelHandler的实现代码。

带有长度字段的数据解码: LengthFieldBasedFrameDecoder

  之所以先从LengthFieldBasedFrameDecoder开始,是因为这个类的实现非常典型,它向我们展示了解码二进制数据包的一些常用方法:

  • 从Byte流中反序列化出一个整数。
  • 利用整数表示一个数据包的长度。
  • 使用偏移量得到数据包的开始位置。
  • 使用数据包的开始位置和长度从Byte流中提取数据包。

  这个类解码的数据包可能有三中格式:

   | length | content | : 其中length是长度字段,它表示content的长度。但是这样格式无法明确地找到数据包的开始位置,需要一个表示开始位置的字段。

   | header | length | conent | : 通过header字段确定数据包的开始位置。

   | header | length | header1 | content |: header2是一个固定长度的字段,它可能包含一些子字段。

  有一些必要的属性用来辅助解码数据包:

  byteOrder: 反序列化整数使用的字节序。

  lengthFieldOffset:  长度字段的偏移量,也是header的长度。

  lengthFieldLength: 长度字段的长度。长度字段是一个整数,它的长度可能是: 1, 2, 3, 4, 8。

  lengthAdjustment:  header1的长度。

  initialBytesToStrip: 从Byte流中提取数据包时去掉的数据长度。

  通过覆盖decode方法从Byte流中提取数据包:

     @Override
protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
Object decoded = decode(ctx, in);
if (decoded != null) {
out.add(decoded);
}
}

  代码比较简单,调用内部的decode方法完成数据包的提取,干货都在这个内部方法中。

     protected Object decode(ChannelHandlerContext ctx, ByteBuf in) throws Exception {
if (discardingTooLongFrame) {
discardingTooLongFrame(in);
} if (in.readableBytes() < lengthFieldEndOffset) {
return null;
} int actualLengthFieldOffset = in.readerIndex() + lengthFieldOffset;
long frameLength = getUnadjustedFrameLength(in, actualLengthFieldOffset, lengthFieldLength, byteOrder); if (frameLength < 0) {
failOnNegativeLengthField(in, frameLength, lengthFieldEndOffset);
} frameLength += lengthAdjustment + lengthFieldEndOffset; if (frameLength < lengthFieldEndOffset) {
failOnFrameLengthLessThanLengthFieldEndOffset(in, frameLength, lengthFieldEndOffset);
} if (frameLength > maxFrameLength) {
exceededFrameLength(in, frameLength);
return null;
} // never overflows because it's less than maxFrameLength
int frameLengthInt = (int) frameLength;
if (in.readableBytes() < frameLengthInt) {
return null;
} if (initialBytesToStrip > frameLengthInt) {
failOnFrameLengthLessThanInitialBytesToStrip(in, frameLength, initialBytesToStrip);
}
in.skipBytes(initialBytesToStrip); // extract frame
int readerIndex = in.readerIndex();
int actualFrameLength = frameLengthInt - initialBytesToStrip;
ByteBuf frame = extractFrame(ctx, in, readerIndex, actualFrameLength);
in.readerIndex(readerIndex + actualFrameLength);
return frame;
}

  调用extractFrame(42行)从Byte流中提取数据包之前的关键环节有:

  • 找到数据包的开始位置:  10行。  
  • 确定数据包的长度: 11行,调用getUnadjustedFrameLength方法反序列化到的length字段值。此时frameLength值是content的长度,还不是真正的包长度。17行,content长度加上header1的长度(lengthAjustment)再加上header和length的长度(lengthFieldEndOffset),得到的结果才是真正的包长度。 41行,最后减去需要丢掉的那部分数据的长度(initialBytesStrip),得到期望的数据包长度。
  • 处理in中数据不足一个数据包的情况: 6-7行,30-31行,返回null。
  • 清理掉in中超过最大数据包长度限制的数据: 23-24行如果in中的数据大于frameLength丢掉这个数据包,否则丢掉in中现有的所有数据,记录下还需要丢弃的数据长度,下次在 2-3行丢掉剩下长度的数据。
  • 处理包长度错误的情况: 13-14行,19-20行丢掉header和length。34-35行丢掉frameLength长度的数据。

  最后得到得到数据包的开始位置和长度之和从in缓冲区中提取出一个完整数据包,并修改in的读位置, 43-44行。  

  getUnadjustedFrameLength中反序列环length的值是计算数据包长度的关键,这个方法的实现如下:

     protected long getUnadjustedFrameLength(ByteBuf buf, int offset, int length, ByteOrder order) {
buf = buf.order(order);
long frameLength;
switch (length) {
case 1:
frameLength = buf.getUnsignedByte(offset);
break;
case 2:
frameLength = buf.getUnsignedShort(offset);
break;
case 3:
frameLength = buf.getUnsignedMedium(offset);
break;
case 4:
frameLength = buf.getUnsignedInt(offset);
break;
case 8:
frameLength = buf.getLong(offset);
break;
default:
throw new DecoderException(
"unsupported lengthFieldLength: " + lengthFieldLength + " (expected: 1, 2, 3, 4, or 8)");
}
return frameLength;
}

  2行设置ByteBuf反序列化整数时使用的字节序,默认BIG_ENDIAN。这个值可以在调用构造方法时设置。

  4-24行,根据length字段的不同长度,使用ByteBuf的不同方法反序列化length的值。length字段的长度只能是: 1,2,3,4,8之一。

  

  以上是LengthFieldBasedFrameDecoder实现的核心代码的分析。这个类把一个比较关键的问题留给子类实现,就是如何处理header或header1字段的处理, header1可以没有,但一定要有header。他们内部可以有比较复杂的结构,而且长度是约定好的,不会变。这个就给子类留下了比较大的扩展空间。通过扩展这个类,我们可以实现任意格式数据包的提取功能。

带有长度字段的数据包编码: LengthFieldPrepender

  这个类实现的功能和LengthFieldBasedFrameDecoder相反,也比它要简单很多,只是简单地在已经序列化好的数据前面加上长度字段。

     @Override
protected void encode(ChannelHandlerContext ctx, ByteBuf msg, ByteBuf out) throws Exception {
int length = msg.readableBytes() + lengthAdjustment;
if (lengthIncludesLengthFieldLength) {
length += lengthFieldLength;
} if (length < 0) {
throw new IllegalArgumentException(
"Adjusted frame length (" + length + ") is less than zero");
} switch (lengthFieldLength) {
case 1:
if (length >= 256) {
throw new IllegalArgumentException(
"length does not fit into a byte: " + length);
}
out.writeByte((byte) length);
break;
case 2:
if (length >= 65536) {
throw new IllegalArgumentException(
"length does not fit into a short integer: " + length);
}
out.writeShort((short) length);
break;
case 3:
if (length >= 16777216) {
throw new IllegalArgumentException(
"length does not fit into a medium integer: " + length);
}
out.writeMedium(length);
break;
case 4:
out.writeInt(length);
break;
case 8:
out.writeLong(length);
break;
default:
throw new Error("should not reach here");
} out.writeBytes(msg, msg.readerIndex(), msg.readableBytes());
}

  3-11行,计算并检查长度字段的值。

    13-43行,在数据前面加上长度字段。

  45行,把数据追加到长度长度字段之后。

行数据包和固定长度数据包的提取

  LineBasedFrameDecoder: 用于从字符串流中按行提取数据包。用"\n"或"\r\n"作为前一个数据包的结束标志和下一个数据包的开始标志,也是根据这个标志算出数据包的长度。

  FixedLengthFrameDecoder: 用于从Byte流中安固定长度提取数据包。数据包没有明确的开始标志或结束标志,只是简单地根据约定的长度提取数据包。

  这个中数据包提取方式对数据源可靠性要求较高,实际应用中要多加小心。

  

字符集转换

  StringEncoder, StringDecoder这两个类用于把字符串从一种字符集转换成另外一种字符集,不涉及数据包的提取。如:GBK和UTF-8之间的转换。

Base64编解码

  Base64Encoder, Base64Decoder这个两个类用于base64的编解码,不涉及数据包的提取。

  

ProtoBuf编解码

  ProtobufEncoder, ProtobufDecoder用ProtoBuf格式数据包的编解码,不涉及数据包的的提取。

压缩和解压缩

  ZlibEncoder,ZlibDecoder: 对zlib和gzip压缩和解压缩算法的支持,不涉及数据包的提取。

  SnappyFramedEncoder,SnappyFramedDecoder: 最Snappy压缩和解压算法的支持,不涉及数据包的提取。

本章小结

  本章分析了分析了Netty使用编解码框架实现特定用途的编解码工具,其中最重要的是LengthFieldPrepender, LengthFieldBasedFrameDecoder类,这两个类展示了对任意二进制数据包打包,和从Byte流中提取二进制数据包的常用方法,理解了这两个类的实现,就能针对任意类型数据包实现自己的编解码Handler。其他的类比较简单,大部分不涉及数据包的提取,只涉及到一些常用的算法和编码格式,Netty在这里只是提供了一些开箱即用的工具。

  前讲过LengthFieldBasedFrameDecoder把对header字段的处理留给子类,这意味着子类可以通过设计自己的header实现更加健壮的,安全的同时兼顾性能的数据包,关于这个话题将在下一章详细讲解。

  

  

netty源码解解析(4.0)-19 ChannelHandler: codec--常用编解码实现的更多相关文章

  1. netty源码解解析(4.0)-17 ChannelHandler: IdleStateHandler实现

    io.netty.handler.timeout.IdleStateHandler功能是监测Channel上read, write或者这两者的空闲状态.当Channel超过了指定的空闲时间时,这个Ha ...

  2. netty源码解解析(4.0)-18 ChannelHandler: codec--编解码框架

    编解码框架和一些常用的实现位于io.netty.handler.codec包中. 编解码框架包含两部分:Byte流和特定类型数据之间的编解码,也叫序列化和反序列化.不类型数据之间的转换. 下图是编解码 ...

  3. netty源码解解析(4.0)-20 ChannelHandler: 自己实现一个自定义协议的服务器和客户端

    本章不会直接分析Netty源码,而是通过使用Netty的能力实现一个自定义协议的服务器和客户端.通过这样的实践,可以更深刻地理解Netty的相关代码,同时可以了解,在设计实现自定义协议的过程中需要解决 ...

  4. netty源码解解析(4.0)-16 ChannelHandler概览

    本章开始分析ChannelHandler实现代码.ChannelHandler是netty为开发者提供的实现定制业务的主要接口,开发者在使用netty时,最主要的工作就是实现自己的ChannelHan ...

  5. netty源码解解析(4.0)-10 ChannelPipleline的默认实现--事件传递及处理

    事件触发.传递.处理是DefaultChannelPipleline实现的另一个核心能力.在前面在章节中粗略地讲过了事件的处理流程,本章将会详细地分析其中的所有关键细节.这些关键点包括: 事件触发接口 ...

  6. netty源码解解析(4.0)-11 Channel NIO实现-概览

      结构设计 Channel的NIO实现位于io.netty.channel.nio包和io.netty.channel.socket.nio包中,其中io.netty.channel.nio是抽象实 ...

  7. netty源码解解析(4.0)-15 Channel NIO实现:写数据

    写数据是NIO Channel实现的另一个比较复杂的功能.每一个channel都有一个outboundBuffer,这是一个输出缓冲区.当调用channel的write方法写数据时,这个数据被一系列C ...

  8. netty源码解解析(4.0)-14 Channel NIO实现:读取数据

     本章分析Nio Channel的数据读取功能的实现. Channel读取数据需要Channel和ChannelHandler配合使用,netty设计数据读取功能包括三个要素:Channel, Eve ...

  9. netty源码解解析(4.0)-12 Channel NIO实现:channel初始化

    创建一个channel实例,并把它register到eventLoopGroup中之后,这个channel然后处于inactive状态,仍然是不可用的.只有在bind或connect方法调用成功之后才 ...

随机推荐

  1. PHP语句中or的用法

     经常看到这样的语句: $file = fopen($filename, 'r') or die("抱歉,无法打开: $filename"); or在这里是这样理解的,因为在P ...

  2. 《VR入门系列教程》之20---使用Oculus移动端SDK

    使用Oculus移动端SDK     在基于安卓系统的GearVR上开发应用需要用到Oculus的移动端SDK,下面的网址可以下载SDK:http://developer.oculus.com     ...

  3. Python基础总结之第四天开始【格式化‘字符串’】(新手可相互督促)

    年薪20万... 字符串格式化: 先看小案例-------: a = 'hello,my name is %s,I like %s.'%('XiaoHong','football') #在字符串中,[ ...

  4. Ubuntu16.04配置Django服务器环境

    本环境是使用Ubuntu16.04+Django2.1.0+python3.6+uwsgi+nginx进行配置 1. 安装python3.6 Ubuntu16.04中原本安装的是python3.5,但 ...

  5. Java多线程笔记总结

    1.线程的三种创建方式 对比三种方式: 通过继承Thread类实现 通过实现Runnable接口 实现Callable接口 第1种方式无法继承其他类,第2,3种可以继承其他类: 第2,3种方式多线程可 ...

  6. Confluence未授权模板注入/代码执行(CVE-2019-3396)

    --- title: Confluence未授权模板注入/代码执行(CVE-2019-3396) tags: [poc,cve] num :g7y12 --- # 简介 --- Confluence是 ...

  7. Spring源码解析——循环依赖的解决方案

    一.前言 承接<Spring源码解析--创建bean>.<Spring源码解析--创建bean的实例>,我们今天接着聊聊,循环依赖的解决方案,即创建bean的ObjectFac ...

  8. java流压缩图片

    整理文档,搜刮出一个Java做图片压缩的代码,稍微整理精简一下做下分享.首先,要压缩的图片格式不能说动态图片,你可以使用bmp.png.gif等,至于压缩质量,可以通过BufferedImage来指定 ...

  9. wamp不显示文件图标

    wamp不显示文件图标 效果如下图 右键图片"在新的标签页打开图片"后会跳转到404页面,并显示The requested URL /icons/unknown.gif was n ...

  10. S2:c#继承

    在C#中,如果一个类后面通过冒号又跟了另外一个类,那么我们就称冒号前面的类为子类,冒号后面的类为父类.这种书写类的方式放映出来的关系就称为类的继承关系. 1.子类:派生类 父类:基类或者超类 满足is ...