如何基于Netty处理粘包、拆包问题？

涉及到相关重要组件：

1. ByteToMessageDecoder
2. MessageToMessageDecoder

这两个组件都实现了ChannelInboundHandler接口，这说明这两个组件都是用来解码网络上过来的数据的。而他们的顺序一般是ByteToMessageDecoder位于head channel handler的后面，MessageToMessageDecoder位于ByteToMessageDecoder的后面。Netty中，涉及到粘包、拆包的逻辑主要在ByteToMessageDecoder及其实现中。

ByteToMessageDecoder

顾名思义、ByteToMessageDecoder是用来将从网络缓冲区读取的字节转换成有意义的消息对象的，对于源码层面指的说明的一段是下面这部分：

protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {

    try {

        while (in.isReadable()) {

            int outSize = out.size();

            if (outSize > 0) {

                fireChannelRead(ctx, out, outSize);

                out.clear();

                if (ctx.isRemoved()) {

                    break;

                }

                outSize = 0;

            }

            int oldInputLength = in.readableBytes();

            decode(ctx, in, out);

            if (ctx.isRemoved()) {

                break;

            }

            if (outSize == out.size()) {

                if (oldInputLength == in.readableBytes()) {

                    break;

                } else {

                    continue;

                }

            }

            if (oldInputLength == in.readableBytes()) {

                throw new DecoderException(

                        StringUtil.simpleClassName(getClass()) +

                        ".decode() did not read anything but decoded a message.");

            }

            if (isSingleDecode()) {

                break;

            }

        }

    } catch (DecoderException e) {

        throw e;

    } catch (Throwable cause) {

        throw new DecoderException(cause);

    }

}

为了节省篇幅，我把注释删除掉了，当上面一个channel handler传入的ByteBuf有数据的时候，这里我们可以把in参数看成网络流，这里有不断的数据流入，而我们要做的就是从这个byte流中分离出message，然后把message添加给out。分开将一下代码逻辑：

1. 当out中有Message的时候，直接将out中的内容交给后面的channel handler去处理。
2. 当用户逻辑把当前channel handler移除的时候，立即停止对网络数据的处理。
3. 记录当前in中可读字节数。
4. decode是抽象方法，交给子类具体实现。
5. 同样判断当前channel handler移除的时候，立即停止对网络数据的处理。
6. 如果子类实现没有分理出任何message的时候，且子类实现也没有动bytebuf中的数据的时候，这里直接跳出，等待后续有数据来了再进行处理。
7. 如果子类实现没有分理出任何message的时候，且子类实现动了bytebuf中的数据，则继续循环，直到解析出message或者不在对bytebuf中数据进行处理为止。
8. 如果子类实现解析出了message但是又没有动bytebuf中的数据，那么是有问题的，抛出异常。
9. 如果标志位只解码一次，则退出。

可以知道，如果要实现具有处理粘包、拆包功能的子类，及decode实现，必须要遵守上面的规则，我们以实现处理第一部分的第二种粘包情况和第三种情况拆包情况的服务器逻辑来举例：

对于粘包情况的decode需要实现的逻辑对应于将客户端发送的两条消息都解析出来分为两个message加入out，这样的话callDecode只需要调用一次decode即可。

对于拆包情况的decode需要实现的逻辑主要对应于处理第一个数据包的时候第一次调用decode的时候out的size不变，从continue跳出并且由于不满足继续可读而退出循环，处理第二个数据包的时候，对于decode的调用将会产生两个message放入out，其中两次进入callDecode上下文中的数据流将会合并为一个bytebuf和当前channel handler实例关联，两次处理完毕即清空这个bytebuf。

当然，尽管介绍了ByteToMessageDecoder，用户自己去实现处理粘包、拆包的逻辑还是有一定难度的，Netty已经提供了一些基于不同处理粘包、拆包规则的实现：如DelimiterBasedFrameDecoder、FixedLengthFrameDecoder、LengthFieldBasedFrameDecoder和LineBasedFrameDecoder等等。其中：

DelimiterBasedFrameDecoder是基于消息边界方式进行粘包拆包处理的。

FixedLengthFrameDecoder是基于固定长度消息进行粘包拆包处理的。

LengthFieldBasedFrameDecoder是基于消息头指定消息长度进行粘包拆包处理的。

LineBasedFrameDecoder是基于行来进行消息粘包拆包处理的。

用户可以自行选择规则然后使用Netty提供的对应的Decoder来进行具有粘包、拆包处理功能的网络应用开发。

最后

在通常的高性能网络应用中，客户端通常以长连接的方式和服务端相连，因为每次建立网络连接是一个很耗时的操作。比如在RPC调用中，如果一个客户端远程调用的过程中，连续发起了多次调用，而如果这些调用对应于同一个连接的时候，那么就会出现服务器需要对于这些多次调用消息的粘包拆包问题的处理。如果是你，你会选择哪种策略呢？