TCP粘包与拆包#

现象： 发送方连续 write 了消息 A、B，接收方 read 可能拿到：

正常：   [A] [B]
粘包：   [A B]            多条消息挤在一次读取里
拆包：   [A 前半] [A 后半 B]  一条消息被拆到多次读取

根本原因： TCP 是面向字节流的协议，只保证字节有序可靠，不保留应用层”一次 write”的边界。具体诱因：

• 发送端：Nagle 算法把多个小包合并发送；大消息超过 MSS 被切成多个报文段；发送缓冲区里的数据何时发、发多少由内核决定
• 接收端：数据先进接收缓冲区，应用一次 read 读多少取决于缓冲区里已有多少字节和传入的读取长度

解决方案（应用层自定义消息边界）：

长度字段方案的接收逻辑：

1. 缓冲区可读字节 < 头部长度（如 4 字节）→ 等待更多数据（半包）
2. 读出 length，缓冲区可读字节 < 头部 + length → 回退读指针，继续等待
3. 够了 → 截取一条完整消息交给上层，剩余字节留到下一轮（粘包）

关掉 Nagle（TCP_NODELAY）不能解决粘包： 它只减少发送端合包，接收端一次读多少仍不确定，边界必须由应用层协议定义。

TCP 粘包和拆包的根本原因是 TCP 是面向字节流的协议，没有消息边界的概念。发送方写入的多条消息在 TCP 看来就是一连串字节，接收方从 socket 缓冲区读到的数据可能是多条消息合在一起（粘包），也可能是一条消息被拆成多次读取（拆包），还可能两者同时发生。产生的具体原因包括：Nagle 算法将小包合并发送、TCP 报文段大小受 MSS 限制、接收方读取速度和发送方写入速度不匹配等。解决粘包拆包本质上是在应用层定义消息边界，有三种常用方案：一是固定长度协议，每条消息定长不足补齐，简单但浪费空间；二是分隔符协议，用特殊字符如换行符标记消息结束，HTTP/1.1 的 Header 就用 CRLF 分隔；三是长度字段加内容的方式，消息头先写一个固定字节数的长度字段再跟实际数据，接收方先读长度再按长度读内容，这是最推荐的方案。Netty 提供了 LengthFieldBasedFrameDecoder 等现成的解码器来处理这个问题。UDP 是数据报协议天然有消息边界，不存在粘包问题。

追问方向：

• “HTTP 怎么解决粘包？”→ HTTP/1.1 用 Content-Length 标明 Body 长度 或 Transfer-Encoding: chunked 分块传输，Header 用 CRLF 分隔
• “Netty 怎么处理粘包？”→ 提供 LengthFieldBasedFrameDecoder（长度字段解码器）、DelimiterBasedFrameDecoder（分隔符）、FixedLengthFrameDecoder（定长）等开箱即用
• “UDP 有粘包问题吗？”→ 没有，UDP 是数据报协议天然有消息边界，每次 recvfrom 读取的就是一个完整的数据报

易错点：

• ❌ TCP 粘包是 TCP 的 bug——TCP 是字节流协议这是特性
• ❌ UDP 也有粘包——UDP 是数据报协议有消息边界