面经策

Netty 是如何解决粘包和拆包问题的？ ​

  • 标签：Netty、后端

🏛 业务架构师 ​

粘包/拆包的根源：TCP 是字节流协议，不保存消息边界——它只保证字节顺序，"一条消息"是应用层的概念。发送端两次 write 的数据可能被合并成一包送达（粘），一条消息也可能被拆成多包（拆）。

这是业务协议设计问题，不是 TCP 的 bug。解法就是应用层自定义边界，三种主流方式：

  • 定长协议：每条消息固定长度，不足补齐。简单但浪费带宽，只适合固定尺寸报文；
  • 分隔符协议：消息尾加特定分隔符（如换行）。要处理正文里出现分隔符的转义——早期系统踩过的坑：用户昵称里带分隔符导致协议解析错乱；
  • 长度域协议（业界主流）：报文头里写明 body 长度，接收端按长度切分。Netty 的 LengthFieldBasedFrameDecoder 配 LengthFieldPrepender 即可，参数（长度域偏移、字节数）就是通信双方的契约。

业务上的教训定位：自定义协议的对接联调中，粘包问题永远在压力测试才暴露——功能测试消息少、每个包独立，一上量就出现"解析出乱码报文"。所以我的规约：私有协议上线前必须做粘包专项压测（连续高频发包验证拆组帧正确性）。

一句话：消息边界是业务契约的一部分，协议设计评审要和接口定义评审同级严肃对待——线上解析错乱排查半天，损失的是双端团队的时间。

🏗 系统架构师 ​

粘包拆包的根源：TCP 是字节流协议，没有消息边界。发送端三次 write 可能被 Nagle 算法合并成一段发出（粘包），一段大数据也可能被 MSS 分片、接收端一次 read 拿到半个消息（拆包）。这不是 bug，是流语义的必然。

解决思路是在应用层定义消息边界，Netty 提供四种开箱即用的解码器：

  • FixedLengthFrameDecoder：固定长度分帧，简单但浪费带宽，协议头部 padding 场景用；
  • DelimiterBasedFrameDecoder：特殊分隔符（如 \n、自定义魔术字节）分帧，文本协议（Redis RESP）常用；
  • LengthFieldBasedFrameDecoder（最通用）：协议头带长度字段，lengthFieldOffset/lengthFieldLength/adjustment/initialBytesToStrip 四参数适配绝大多数二进制协议——先读长度再精准截取帧，自定义 RPC 协议的标准做法；
  • 行解码器 LineBasedFrameDecoder：换行分帧的特例。

我的实践：自定义协议 = 魔数 + 版本 + 消息类型 + 长度 + payload，解码器外再套一个ByteToMessageDecoder做 CRC 校验与超长帧防护（maxFrameLength 防内存攻击）；解码得到的帧向下传递，业务 Handler 里永远拿到完整消息，编码侧对应用 LengthFieldPrepender 补长度，一侧写一侧读，闭环。

💻 全栈开发专家 ​

根源：TCP 是字节流协议，没有"消息边界"，一次 send 可能被拆成多段（拆包），多次 send 可能被合并传输（粘包，Nagle 算法/MSS 分段）。应用层必须自己定义边界。Netty 提供四类现成解码器：

java
ch.pipeline()
  .addLast(new FixedLengthFrameDecoder(64))            // 定长
  .addLast(new LineBasedFrameDecoder(1024))            // 换行分隔
  .addLast(new DelimiterBasedFrameDecoder(1024, Unpooled.copiedBuffer("$_")))
  // 最常用：长度字段解码器（自定义协议标配）
  .addLast(new LengthFieldBasedFrameDecoder(65535, 0, 4, 0, 4));
  // maxFrameLength=65535, lengthFieldOffset=0, lengthFieldLength=4(int长度),
  // lengthAdjustment=0, initialBytesToStrip=4(剥掉长度头)

我设计协议的固定格式：魔数(4B) + 版本(1B) + 消息类型(1B) + 长度(4B) + body，LengthFieldBasedFrameDecoder 参数对着字节布局算，长度字段防脏包（maxFrameLength 溢出直接断连，保护内存）。

踩过的坑：

  1. 解码器在 pipeline 里的顺序必须最前，且和 encoder 对称；
  2. maxFrameLength 要留够，业务 body 变大后频繁 TooLongFrameException；
  3. 长度字段里包含不包含自身/头部长度，全链路（对端编码器）理解必须一致——联调时对着 16 进制 dump 对齐最靠谱；
  4. TCP 层的粘包无法在协议外"解决"，只能靠应用层协议化解，这个意识比记 API 重要。