Netty自定义协议解析原理与应用

目前，大家都选择Netty做为游戏服务器框架网络通信的框架，而且目前也有很多优秀的产品是基于Netty开发的。它的稳定性，易用性和高效率性已得到广泛的认同。在游戏服务器开发中，选择netty一般就意味着我们要使用长连接来建立与客户端的通信，并且是自定义协议，在网络开发中，我们不得不处理断包，粘包的问题，因为Tcp/ip是基于数据流的传输，包与包之间没有明确的界限，而且于由网络路由的复杂性，大包有可能分成小包，小包也有可能被组装成大包进行传输。而Netty就考虑到了这一点，而且它用一个类就帮我们处理了这个问题，这个类就是：LengthFieldBasedFrameDecoder。这里是它的API说明：http://netty.io/4.1/api/index.html

这里简单翻译一下，以供参考。

这个解码器是用来动态分割消息包的，这些消息包都带有一个表示消息长度的值。当你需要解码一个二进制流的包时，有一个表示消息内容长度或整个包长度的包头是非常有用的。LengthFieldBasedFrameDecoder解码器提供一些参数的配置，它可以解码任何一种带包长度信息的包。这些包经常出现在client/server模式的网络通信协议中，下面是一些例子，它们可以帮助你去选择哪个配置来使用。

这段代码是Netty服务启动时的配置

public class ServerManager {

private int port;

public ServerManager(int port) {

this.port = port;

}

//参考的官方例子

public void run() throws Exception {

EventLoopGroup bossGroup = new NioEventLoopGroup(); // (1)

EventLoopGroup workerGroup = new NioEventLoopGroup();

try {

ServerBootstrap b = new ServerBootstrap(); // (2)

b.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class) // (3)

.childHandler(new ChannelInitializer<SocketChannel>() { // (4)

@Override

public void initChannel(SocketChannel ch) throws Exception {

//这里就是添加解码器的地方，它有几种不同的构造方法。下面是带全部参数的构造方法，这些参数的作用将在下面的例子中说明，这里没有赋值。ByteOrder可以选择编码是大端还是小端（关于大端或小端的问题，不明白的请自行百度），maxFrameLength表示接收到的包的最大长度。

ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(ByteOrder.BIG_ENDIAN, maxFrameLength, lengthFieldOffset, lengthFieldLength, lengthAdjustment, initialBytesToStrip, failFast));

ch.pipeline().addLast(new ServerHandler());

}

}).option(ChannelOption.SO_BACKLOG, 128) // (5)

.childOption(ChannelOption.SO_KEEPALIVE, true); // (6)

// Bind and start to accept incoming connections.

ChannelFuture f = b.bind(port).sync(); // (7)

// Wait until the server socket is closed.

// In this example, this does not happen, but you can do that to

// gracefully

// shut down your server.

f.channel().closeFuture().sync();

} finally {

workerGroup.shutdownGracefully();

bossGroup.shutdownGracefully();

}

}

}

1）2个字节的包头记录包长，0 字节偏移，解码后不跳过包头。

这个例子中，包头表示包长度的值是12，它表示的是包的内容”HELLO,WORLD”的长度。默认来说，解码器会把这个包头的长度假设为包头后面所有字节的长度，因为这个包可以被下面的这个配置解码。

lengthFieldOffset   = 0

lengthFieldLength   = 2

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" |

+--------+----------------+      +--------+----------------+

Before Decode表示的是解码之前接收到的完整的数据包的包结构，After Decode表示的是解码完成后，传给下一层过滤器的包结构。在上面的服务器启动代码中，Before Decode就是客户端传过来的包，而After Decode就是经过这个解码器之后，传到ServerHandler的public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception 方法中的Object msg的结构，是一个ByteBuf类型。下面所有的例子都是如此。

public class ServerHandler implements ChannelInboundHandler {

public void handlerAdded(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void channelRegistered(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void channelUnregistered(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void channelActive(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void channelInactive(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {

ByteBuf byteBuf = (ByteBuf) msg;

//读取包的包长度

int len = byteBuf.readInt();

//剩下的就是包内容了。

.........

}

public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {

// TODO Auto-generated method stub

}

public void channelWritabilityChanged(ChannelHandlerContext ctx) throws Exception {

// TODO Auto-generated method stub

}

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {

// TODO Auto-generated method stub

//cause.printStackTrace();

}

2) 2个字节的包头记录包长，0 字节偏移，解码后跳过包头。

我们可以根据ByteBuf.readableBytes(), 方法来获取包的长度值，所以，有时候我们希望解码后，可以跳过表示信息长度的包头。下面这个例子就实现了它，跳过2 个字节的包头信息。

lengthFieldOffset   = 0

lengthFieldLength   = 2

lengthAdjustment    = 0

initialBytesToStrip = 2 (= the length of the Length field)

BEFORE DECODE (14 bytes)         AFTER DECODE (12 bytes)

+--------+----------------+      +----------------+

| Length | Actual Content |----->| Actual Content |

| 0x000C | "HELLO, WORLD" |      | "HELLO, WORLD" |

+--------+----------------+      +----------------+

这样我们在public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception中得到的msg就只是包含了包内容的信息，而不包括包头的信息了。

3) 2个字节的包头记录包长，0 字节偏移，包头表示包长度的值代表的整个包的长度，包括包头占的字节数。

大部分情况下，包长度代表的是包内容的长度，比如之前的例子。但是，在有些协议中，包长度代表的是整个协议传输包的长度，包括包头的长度。下面这个例子中，我们指定一个非0的lengthAdjustment值，因为下面这个例子中的包长度总是比包的内容长度多2个字节，所以我们指定lengthAdjustment = -2 作为补偿。

lengthFieldOffset   =  0

lengthFieldLength   =  2

lengthAdjustment    = -2 (= the length of the Length field)

initialBytesToStrip =  0

BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)

+--------+----------------+      +--------+----------------+

| Length | Actual Content |----->| Length | Actual Content |

| 0x000E | "HELLO, WORLD" |      | 0x000E | "HELLO, WORLD" |

+--------+----------------+      +--------+----------------+

解码后，收到的msg信息和1)中是一样的。

4) 5字节的包头，3字节表示包的长度，这3个字节在包头的末尾。不跳过包头

这个例子是1)的一个变种。2字节表示整个包的大小（不包括这2个字节数），3字节表示包内容的长度。

lengthFieldOffset   = 2 (= the length of Header 1)

lengthFieldLength   = 3

lengthAdjustment    = 0

initialBytesToStrip = 0

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" |

+----------+----------+----------------+               +----------+----------+----------------+

Header1的值是15，Length是12

5) 4 字节的包头，在包的中间有2字节长度表示包内容的长度，解码后跳过第一个包头和包长度的值

这个例子是上面所有例子的一个综合，在包头信息中，包长度前面有一个预设的包头，包长度后面，有一个额外的包头，预设包头影响lengthFieldOffset的值，额外的包头影响lengthAdjustment的值，这里设置一个非0的值给initialBytesToStrip 表示跳过预设包头和包长度的值。

lengthFieldOffset   = 1 (= the length of HDR1)

lengthFieldLength   = 2

lengthAdjustment    = 1 (= the length of HDR2)

initialBytesToStrip = 3 (= the length of HDR1 + LEN)

BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)

+------+--------+------+----------------+      +------+----------------+

| HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |

| 0xCA | 0x000C | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |

+------+--------+------+----------------+      +------+----------------+

6) 4 字节的包头，在包的中间有2字节长度表示包内容的长度，解码后跳过第一个包头和包长度的值，包长度的值代表的是整个包的长度。

这个例子与上面的例子类似，只是这里包长度表示的整个包的长度

lengthFieldOffset   =  1

lengthFieldLength   =  2

lengthAdjustment    = -3 (= the length of HDR1 + LEN, negative)

initialBytesToStrip = 3

BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)

+------+--------+------+----------------+      +------+----------------+

| HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |

| 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |

+------+--------+------+----------------+      +------+----------------+

通过以上几种例子的配置，我们可以灵活的定义我们的协议格式，通过简单的配置Netty的解码器，就可以完成消息的解码，又方便，又安全。

转载请注明，来自游戏技术网:http://www.youxijishu.com

打赏