小编带你了解Netty 系列七（那些开箱即用的 ChannelHandler）.

回到顶部
四、拆包和粘包的解决方案
TCP 传输过程中，客户端发送了两个数据包，而服务端却只收到一个数据包，客户端的两个数据包粘连在一起，称为粘包；

TCP 传输过程中，客户端发送了两个数据包，服务端虽然收到了两个数据包，但是两个数据包都是不完整的，或多了数据，或少了数据，称为拆包；

发生TCP粘包、拆包主要是由于下面一些原因：

1、应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
2、应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
3、进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>MSS的时候将发生拆包。
4、接收方法不及时读取套接字缓冲区数据，这将发生粘包。

Netty 预定义了一些×××用于解决粘包和拆包现象，其中大体分为两类：

基于分隔符的协议：在数据包之间使用定义的字符来标记消息或者消息段的开头或者结尾。这样，接收端通过这个字符就可以将不同的数据包拆分开。
基于长度的协议：发送端给每个数据包添加包头部，头部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包头部的长度字段，便知道每一个数据包的实际长度了。

基于分隔符的协议

复制代码
public class LineBasedHandlerInitializer extends ChannelInitializer<Channel> {

@Override
protected void initChannel(Channel ch) throws Exception {
    ch.pipeline().addLast(
            // 将提取到的桢转发给下一个Channelhandler
            new LineBasedFrameDecoder(64 * 1024),
            // 添加 FrameHandler 以接收帧
            new FrameHandler()
    );
}

public static final class FrameHandler extends SimpleChannelInboundHandler<ByteBuf> {

    @Override
    protected void messageReceived(ChannelHandlerContext ctx, ByteBuf msg) throws Exception {
        //Do something with the data extracted from the frame
    }
}

}
复制代码
基于长度的协议

LengthFieldBasedFrameDecoder 是 Netty 基于长度协议解决拆包粘包问题的一个重要的类，主要结构就是 header+body 结构。我们只需要传入正确的参数就可以发送和接收正确的数据，那吗重点就在于这几个参数的意义。下面我们就具体了解一下这几个参数的意义。先来看一下LengthFieldBasedFrameDecoder主要的构造方法：

public LengthFieldBasedFrameDecoder(
int maxFrameLength,
int lengthFieldOffset, int lengthFieldLength,
int lengthAdjustment, int initialBytesToStrip)
maxFrameLength：最大帧长度。也就是可以接收的数据的最大长度。如果超过，此次数据会被丢弃。
lengthFieldOffset：长度域偏移。就是说数据开始的几个字节可能不是表示数据长度，需要后移几个字节才是长度域。
lengthFieldLength：长度域字节数。用几个字节来表示数据长度。
lengthAdjustment：数据长度修正。因为长度域指定的长度可以使 header+body 的整个长度，也可以只是body的长度。如果表示header+body的整个长度，那么我们需要修正数据长度。
initialBytesToStrip：跳过的字节数。如果你需要接收 header+body 的所有数据，此值就是0，如果你只想接收body数据，那么需要跳过header所占用的字节数。

复制代码
public class LengthBasedInitializer extends ChannelInitializer<Channel> {

@Override
protected void initChannel(Channel ch) throws Exception {
    ch.pipeline().addLast(
            new LengthFieldBasedFrameDecoder(64 * 1024, 0, 8),
            new FrameHandler()
    );
}

public static final class FrameHandler extends SimpleChannelInboundHandler<ByteBuf> {

    @Override
    protected void messageReceived(ChannelHandlerContext ctx, ByteBuf msg) throws Exception {
        //处理桢的数据
    }
}

}
复制代码
tips：UDP协议不会发生沾包或拆包现象， 因为UDP是基于报文发送的，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开。

回到顶部
五、其他
由于网络饱和的可能性，如何在异步框架中高效地写大块的数据是一个特殊的问题。Netty 通过一个 FileRegion 接口来实现，其在 Netty 的API 文档中的定义是："通过支持零拷贝的文件传输的 Channel 来发送的文件区域"。但是该接口只适用于文件内容的直接传输，不包括应用程序对文件数据的任何处理。

如果大块的数据要从文件系统复制到用户内存中时，可以安装一个 ChunkedWriteHandler，并用 ChunkedInput 实现写入文件数据。 它支持异步写大型数据流，而又不会导致大量的内存消耗。

ChunkedWriteHandlerInitializer.java

Netty提供的用于和JDK进行互操作的序列化类 ：

Netty提供的用于和 JBoss Marshalling 进行互操作的序列化类 ：

MarshallingInitializer.java
Netty提供的用于和 Protocol Buffers 进行互操作的序列化类 ：

原文地址：http://blog.51cto.com/13954634/2171386