2. TCP协议基础回顾：粘包拆包问题的根源

聊粘包拆包，绕不开TCP协议本身。我见过不少开发者，一上来就查怎么拆包，结果连TCP报文长什么样都没搞清楚。说白了，你不懂TCP的脾气，就搞不定粘包。

这一节，我们快速过一遍TCP的核心机制。重点放在那些直接导致粘包拆包的设计上。

2.1 TCP报文段结构

先看最基础的东西——TCP报文段长什么样。我习惯把它分成两部分：头部和数据。

字段	长度	作用
源端口 / 目的端口	各16位	标识通信进程
序列号 (SEQ)	32位	字节流编号，解决乱序
确认号 (ACK)	32位	期望收到的下一个字节
数据偏移	4位	头部长度，单位4字节
标志位 (URG/ACK/PSH/RST/SYN/FIN)	6位	控制连接状态
窗口大小	16位	接收方剩余缓冲区
校验和	16位	端到端校验
紧急指针	16位	紧急数据位置

这里有个关键点：TCP是流式协议。它不关心你应用层发的是什么，它只把数据当成一连串的字节。你发一个100字节的包，TCP可能拆成两个50字节的段，也可能攒三个包一起发。这就是粘包拆包的根源。

2.2 滑动窗口机制

滑动窗口是TCP做流量控制的核心手段。我当年调优一个高并发网关时，就是靠调窗口参数把吞吐量提上去的。

简单说，滑动窗口就是接收方告诉发送方："我还有多少空间，你悠着点发。"

• 发送窗口：发送方可以连续发送的字节数，不用等ACK
• 接收窗口：接收方缓冲区剩余容量，通过TCP头部通告
• 窗口滑动：收到ACK后，窗口向右移动，释放新空间

为什么会引发粘包？你想想看，如果接收窗口很大，发送方一口气把多个小包全塞进去，接收方一次read()可能就读到好几条消息。这就是典型的粘包场景。

2.3 Nagle算法与延迟确认

这两个东西，是粘包问题的"帮凶"。我踩过它们的坑，印象特别深。

Nagle算法

Nagle算法的初衷是好的——减少小包数量。它的规则很简单：

1. 如果数据长度 >= MSS，立即发送
2. 如果数据长度 < MSS，且之前的小包还没收到ACK，就攒着
3. 等ACK到了，或者攒够MSS了，再一起发

你看，这不就是主动粘包吗？我做过一个游戏服务器，客户端发的小指令包被Nagle算法攒住了，导致操作延迟飙升。后来果断关了Nagle，问题解决。

延迟确认

延迟确认是接收方的策略：收到数据后不立即回ACK，等200ms或攒够两个段再回。这样做能减少ACK包数量，但副作用也很明显——发送方收不到ACK，窗口不滑动，数据就卡住了。

Nagle + 延迟确认，堪称粘包拆包的"黄金搭档"。发送方攒着不发，接收方攒着不确认，两边一起攒，性能直接拉胯。

2.4 MSS与MTU的概念

这两个概念经常被搞混，我简单理一下。

概念	全称	层级	典型值	作用
MTU	最大传输单元	网络层（IP）	1500字节（以太网）	IP层不分片的最大包
MSS	最大报文段长度	传输层（TCP）	1460字节（MTU - 40）	TCP数据部分最大长度

MSS = MTU - IP头部(20) - TCP头部(20)。以太网MTU是1500，所以MSS通常是1460。TCP在三次握手时会协商MSS，双方取最小值。

为什么提这个？因为MSS决定了TCP单个报文段能装多少数据。如果你的应用层消息大于MSS，TCP必然拆包。这就是拆包的物理原因。

2.5 TCP缓冲区工作原理

TCP缓冲区是粘包拆包的"案发现场"。我画了一张图，帮你理解数据是怎么流动的。

这张图展示了数据从应用层到发送缓冲区，再到网络，最后到接收缓冲区的完整路径。注意看接收缓冲区那块——粘包和拆包就发生在这里。

• 粘包：多个小消息在接收缓冲区里连成一片，应用层一次read()读到多条
• 拆包：一个大消息被TCP拆成多个段，应用层需要多次read()才能拼完整

我刚开始做网络编程时，总以为send()和recv()是一一对应的。后来被现实狠狠教育了一顿。TCP的缓冲区是流式的，你send()三次，对方可能一次recv()就全拿走了；你send()一次，对方也可能分三次recv()才能拿完。