3. 粘包拆包产生场景：发送端缓冲区合并、接收端缓冲区读取不及时、报文大小超过MSS

好，咱们今天聊聊粘包拆包到底是怎么产生的。

说实话，很多新手一上来就问我：“老师，粘包拆包是不是协议本身的问题？” 其实不是。TCP 是流式协议，它压根不关心你发的是几个包。它只负责把数据流从 A 点搬到 B 点。那问题出在哪？出在三个典型场景上。

我个人习惯把这三种场景记成：发送端“攒着发”、接收端“懒得读”、报文“太大个”。下面我一个一个拆开讲。

3.1 场景一：发送端缓冲区合并（Nagle 算法惹的祸）

先说说发送端。你想想看，如果每次发 1 个字节都要走一次网络，那效率得多低？所以 TCP 内部有个优化机制——Nagle 算法。

这个算法的逻辑很简单：
如果发送端有多个小数据包，TCP 不会立刻发出去。它会等一等，攒成一个大包再发。说白了，就是“合并同类项”。

我在项目中遇到过这样一个案例：
一个游戏服务器，客户端每 10 毫秒发一个状态包，每个包才 20 字节。结果 Nagle 算法一开，这些包被合并成一个 200 字节的大包。接收端收到后，傻眼了——它不知道哪里是边界。

3.2 场景二：接收端缓冲区读取不及时（应用层“偷懒”）

这个场景更常见。我经常跟团队说：“别怪 TCP，先看看你自己的代码。”

接收端的工作流程是这样的：
数据到达 -> 存入接收缓冲区 -> 应用层调用 recv() 或 read() 读取。

问题来了：如果应用层读取速度慢，或者一次只读了一部分，会发生什么？

举个例子：
发送端连续发了两个包，包 A（100 字节）和包 B（200 字节）。
接收端只调用了一次 recv(buf, 150)，结果呢？
它读到了包 A 的全部 100 字节 + 包 B 的前 50 字节。
这就是典型的粘包。

反过来，如果接收端一次读了 300 字节，但包 A 只有 100 字节，那它读到的是包 A + 包 B 的混合体。还是粘包。

3.3 场景三：报文大小超过 MSS（拆包的本质）

这个场景跟前面两个不太一样。前面两个是“粘”，这个是“拆”。

MSS 是什么？最大报文段长度。简单说，就是 TCP 层一次能传输的最大数据量。通常 MSS = MTU - IP 头 - TCP 头 ≈ 1460 字节。

如果你发送的报文超过 MSS，TCP 会怎么做？
它会拆。把一个大数据包拆成多个小数据段，分别发送。

比如你发了一个 3000 字节的包，MSS 是 1460。TCP 会把它拆成：
- 段 1：1460 字节
- 段 2：1460 字节
- 段 3：80 字节

接收端收到的是三个独立的 TCP 段。如果应用层没有正确的边界标识，它根本不知道这三个段原来是一个包。

3.4 三种场景对比总结

为了让你看得更清楚，我整理了一个表格：

3.5 核心逻辑图：粘包拆包产生根源

下面我用一张 SVG 图，把这三个场景的关系画出来。你看完应该能一目了然。

3.6 怎么判断你遇到了哪种场景？

嗯，这里有个小技巧。我在线上排查问题时，一般这么看：

1. 如果数据总是“多包黏在一起”，而且包的大小不固定 → 大概率是发送端合并（Nagle 算法）
2. 如果数据“时粘时不粘”，而且跟系统负载有关 → 大概率是接收端读取不及时
3. 如果数据“被拆成固定大小”，比如总是 1460 字节左右 → 肯定是 MSS 拆包

好了，三种场景都讲完了。你想想看，是不是每个场景都跟“边界”有关？没错，粘包拆包的本质就是边界丢失。下一节我们开始讲怎么解决它。

可可精品资料库