Netty的粘包/拆包问题的解决之道

小明 2025-05-06 07:33:44 4

问题提出

在使���Netty进行网络通信时，由于网络传输的特性，数据往往无法保持完整的发送或接收。可以把netty的socket通道看成是一段水管，水管里的水是没有分界线的。TCP作为底层传输协议，是不了解上层业务数据的意义。这就会导致数据在传输过程中被拆分成多个小片段，或者多个数据包被合并到一个大的数据包中。为了解决这个问题，Netty提供了一些方法来处理拆包和粘包的问题。

（）

1.消息定长，每个消息都是固定长度，不足字节部分用空格补全。

netty提供了提供了FixedLengthFrameEncoder和FixedLengthFrameDecoder来实现。说实在的，这种解决方式实在简单粗暴，根本不会有产品项目采纳。

2.在包尾插入分割符合，例如回车换行符

netty提供了LineBasedFrameDecoder+StringDecoder组合来支持换行符分割。

（）

其工作原理是LineBasedFrameDecoder先遍历ByteBuf的可读字节，若包含换行符，则以其作为结束位置，将区间的字节作为一个整体字符数组，StringDecoder再将捕获的字符数组转成一个字符串。

若需要采用其他分割符，netty也提供了DelimiterBasedFrameDecode+StringDecoder组合来支持。

3.在消息头增加长度来表示消息的总大小

送端在数据包的前面添加一个消息长度字段，接收端根据消息长度进行解析。Netty提供了LengthFieldPrepender和LengthFieldBasedFrameDecoder来处理基于消息长度的粘包。

  ChannelPipeline pipeline = ch.pipeline();
  // 添加LengthFieldBasedFrameDecoder来解决粘包和拆包问题
  pipeline.addLast(new LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4));
  // 添加LengthFieldPrepender来处理粘包和拆包问题
  pipeline.addLast(new LengthFieldPrepender(4));

这个示例中的LengthFieldBasedFrameDecoder使用了以下参数：

  • frameMaxLengh：解码后的最大帧长度，超过这个长度的帧将被丢弃。
  • lengthFieldOffset：长度字段的偏移量，指的是长度字段的起始位置相对于整个数据包的起始位置的偏移量。
  • lengthFieldLength：长度字段的长度，指的是长度字段的字节数。
  • lengthAdjustment：长度字段的调整值，指的是长度字段值需要增加或减少的量。
  • initialBytesToStrip：从解码后的帧中去掉的字节数。

    这几个参数比较复杂，源码给了非常详细的例子进行说明，有兴趣的可以通过源码进行阅读。

     4，自定义消息头和消息体

    第三种方法虽然使用简单，但无法满足一些需求。对于一个项目来说，可能消息的种类非常多，不能单纯使用消息长度来定义，需要额外一个消息id来表示。那既然项目已定义了自己的私有协议栈来解决粘包问题了，那就不会继续使用LengthFieldBasedFrameDecoder。例如jforgame就使用了完全私有的协议栈解析。

    public class DefaultProtocolDecoder extends ByteToMessageDecoder {
    private int maxProtocolBytes = 4096;
    private Logger logger = LoggerFactory.getLogger(DefaultProtocolDecoder.class);
    private MessageFactory messageFactory;
    private MessageCodec messageCodec;
    /**
     * 消息元信息常量，为int类型的长度，表示消息的id
     */
    private final int MESSAGE_META_SIZE = 4;
    public DefaultProtocolDecoder(MessageFactory messageFactory, MessageCodec messageCodec) {
        this.messageFactory = messageFactory;
        this.messageCodec = messageCodec;
    }
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List out) throws Exception {
        if (in.readableBytes()  maxProtocolBytes) {
            logger.error("单包长度[{}]过大，断开链接", length);
            ctx.close();
            return;
        }
        if (in.readableBytes()  

    在本例中私有协议定义中定义了包头（包长度+消息id)和包体。如果buff小于包长度，则继续等待数据到达。通过消息id来定义一个实际的消息类型，再通过消息编解码来读取。可以继续优化的是，因为一般客户端的请求消息都比较小，发生粘包的可能性很大。在这里，我们还可以增加一个for循环来解析更多的请求包。
     

    这里注意两个概念，私有协议指的是包头+包体，而消息编解码指的是包体反序列化成一个真正的业务对象。
The End

标签：

微信