3. 粘包拆包的常见场景

说实话，粘包拆包这个问题，我在刚入行那几年没少被它折腾。那时候写一个简单的即时通讯服务，客户端发一条消息，服务端收着收着就乱套了。后来我才明白，这玩意儿不是 Bug，是 TCP 的底层机制决定的。

TCP 是流式协议，它不关心你发的是几条消息，它只关心字节流。所以，粘包和拆包本质上就是「消息边界」丢失的问题。下面我带你看看最常见的四种场景。

核心一句话：粘包拆包不是 TCP 的错，是应用层没处理好消息边界。

3.1 连续发送小数据包

这是最典型的粘包场景。你想想看，如果应用层连续调用 send() 发送几个很小的数据包，比如每条消息只有几十个字节，TCP 协议栈会怎么处理？

我个人的习惯是，在讲解这个问题时先看一个实际例子。假设客户端连续发送三条消息：

// 客户端连续发送
send(sock, "Hello", 5, 0);
send(sock, "World", 5, 0);
send(sock, "TCP", 3, 0);

服务端接收时，很可能一次性读到：

recv(sock, buf, 1024, 0);
// buf 内容: "HelloWorldTCP"

三条消息粘在一起了。为什么会这样？因为 Nagle 算法在背后搞鬼。它会把多个小包合并成一个大的 TCP 段再发送，提高网络利用率。但对我们应用层来说，这就是粘包。

因素	说明	影响
Nagle 算法	合并小包，等待 ACK 后再发	加剧粘包
MSS 大小	单次最大段大小（通常 1460 字节）	超过则拆包
发送频率	连续 send 间隔极短	容易粘包

我的经验：我在做一个物联网网关项目时，传感器每 50ms 上报一次状态数据，每条数据不到 100 字节。如果不做粘包处理，服务端收到的全是拼接后的乱码。后来我在每个包前面加了 4 字节的长度头，问题才解决。

3.2 发送端缓冲区合并

这个场景和上一个有点类似，但本质不同。发送端缓冲区合并，是 TCP 协议栈在内核层面做的优化。

你调用 send() 时，数据并不是立刻发出去的。它先拷贝到内核的发送缓冲区，然后由 TCP 协议栈决定什么时候发、怎么发。如果连续多次 send() 的数据都在同一个缓冲区里，TCP 就会把它们打包成一个 TCP 段发出去。

我记得有一次排查线上问题，发现客户端明明分了 5 次 send，服务端却只收到 2 次 recv 完成。抓包一看，TCP 层只发了 2 个数据包。这就是缓冲区合并导致的粘包。

// 发送端缓冲区合并示意
// 内核发送缓冲区大小通常为 16KB - 64KB
// 如果多次 send 的数据总量 < 缓冲区阈值，就会合并

send(sock, "A", 1, 0);   // 进入缓冲区
send(sock, "B", 1, 0);   // 还在缓冲区
send(sock, "C", 1, 0);   // 触发发送，三个字节一起发出去

注意：即使你关闭了 Nagle 算法（TCP_NODELAY），发送端缓冲区合并仍然可能发生。因为 TCP 协议栈有自己的发送策略，不完全受 Nagle 控制。

3.3 接收端读取不及时

这个场景经常被忽视，但实际项目中很常见。接收端读取不及时，说白了就是服务端处理速度跟不上数据到达的速度。

假设客户端一次性发来 10KB 数据，但服务端每次只 recv 2KB。那么前几次 recv 拿到的都是不完整的消息——这就是拆包。反过来，如果服务端忙不过来，数据在接收缓冲区里堆积，下次 recv 时可能一次性读到多条消息——这就是粘包。

我曾经接手过一个老项目，服务端用单线程循环 recv，每次只读 1024 字节。客户端发一条 3000 字节的消息，服务端要分 3 次才能读完。每次读到一半的数据，解析器就报错。这就是典型的接收端读取不及时导致的拆包问题。

// 接收端读取不及时示例
// 客户端发送 3000 字节
// 服务端每次只读 1024 字节

// 第一次 recv: 读到 0-1023 字节（不完整消息）
// 第二次 recv: 读到 1024-2047 字节（还是不完整）
// 第三次 recv: 读到 2048-2999 字节（终于完整了）

场景	原因	结果
接收缓冲区堆积	应用层读取速度 < 网络到达速度	粘包
recv 缓冲区过小	单次读取量 < 消息长度	拆包
处理线程阻塞	业务逻辑耗时导致读取延迟	粘包 + 拆包

3.4 应用层协议设计缺陷

这是最要命的场景。前面三种都是 TCP 的天然行为，你没法完全避免。但应用层协议设计缺陷，完全是人为的。

我见过最典型的错误，就是直接用固定分隔符来分割消息，比如用 \n 或 \r\n。你想想看，如果消息内容本身就包含这些字符怎么办？

// 错误的设计：用 \n 做消息分隔符
// 消息内容: "Hello\nWorld"
// 解析结果: 被拆成 "Hello" 和 "World" 两条消息

// 正确的设计：长度头 + 内容体
// [4字节长度][消息内容]
// 0005Hello0005World0003TCP

还有一种常见缺陷，就是没有定义消息的最大长度。攻击者可以发送一个超长的消息头，声明长度是 4GB，然后服务端傻傻地分配内存等着——这就是内存耗尽攻击。

避坑指南：我曾经在一个金融交易系统中看到过这样的代码——用 JSON 的 {} 括号匹配来分割消息。结果某次行情数据里嵌套了 10 层 JSON，解析器直接栈溢出。从那以后，我坚持所有协议都必须有明确的长度字段。

好的协议设计应该满足三个条件：

明确的消息边界：要么用固定长度，要么用长度头，要么用特殊结束符（但要转义）
可预期的最大长度：防止恶意攻击和内存溢出
自描述性：单条消息就能解析，不依赖上下文

这四种场景，说白了就是 TCP 的流式特性和应用层的消息边界需求之间的矛盾。你没法让 TCP 不发粘包，但你可以让你的协议能正确处理粘包和拆包。

📚 课程目录

3. 粘包拆包的常见场景

3.1 连续发送小数据包

3.2 发送端缓冲区合并

3.3 接收端读取不及时

3.4 应用层协议设计缺陷