3. 粘包拆包的典型场景：连续发送小数据包、发送端缓冲区合并、接收端读取不及时、网络拥塞导致重传

说实话，粘包拆包这个问题，很多新手觉得是玄学。其实不是。它背后有非常清晰的触发条件。我这些年排查过的线上问题，十有八九都逃不出下面这四种场景。咱们一个一个掰开来看。

3.1 场景一：连续发送小数据包

这是最常见的粘包场景。你想想看，应用层连续调用了两次 send()，每次只发几十个字节。TCP 协议栈一看，嘿，这点数据还不够塞满一个 MSS（最大报文段长度）的。它就会做个小动作——把两次的数据合并成一个 TCP 报文发出去。

我记得有一次排查一个即时通讯的丢消息问题。客户端发了两条心跳，服务端只收到一条。抓包一看，两个心跳包被塞进同一个 TCP 段里了。这就是典型的连续小包粘包。

3.2 场景二：发送端缓冲区合并

这个场景跟第一个有点像，但触发机制不同。发送端调用 send() 时，数据先拷贝到内核的发送缓冲区。如果缓冲区里还有上次没发完的数据，新数据就会直接追加在后面。等 TCP 真正发送时，可能一次就把缓冲区里攒的几段数据全发出去了。

我建议你在写代码时注意一点：不要假设一次 send() 对应一次 recv()。这个假设是很多粘包问题的根源。

3.3 场景三：接收端读取不及时

这个场景很有意思。发送端其实已经按正常节奏发数据了，但接收端处理不过来。比如接收线程被阻塞了，或者业务逻辑处理太慢。这时候接收缓冲区里就会堆积数据。等接收端终于有空去 recv() 时，一次性读出来的可能就是好几段数据的混合物。

为什么会这样？因为 TCP 是流式协议，它不关心你应用层的消息边界。接收缓冲区里有什么，recv() 就给你什么。你读得慢，它就攒得多。

读取时机	缓冲区状态	读取结果
立即读取	只有一段数据	正常，无粘包
延迟 100ms	堆积了 2 段数据	粘包，一次读出两段
延迟 500ms	堆积了 5 段数据	严重粘包，一次读出多段

我个人习惯在接收端用独立线程做网络读取，跟业务处理线程分开。这样能最大程度避免因为业务处理慢导致的读取不及时问题。

3.4 场景四：网络拥塞导致重传

这个场景比较隐蔽。网络出现拥塞时，TCP 会启动重传机制。重传的数据包到达接收端时，可能跟后面新发的数据包撞在一起。接收端一次性收到两个包，自然就粘了。

说白了，网络拥塞不仅影响性能，还会破坏你应用层的消息边界。我在一个跨机房传输的项目里遇到过这个问题。两个机房之间的链路偶尔抖动，一抖动就丢包重传，一重传就粘包。最后不得不在协议层加了序号校验，才彻底解决。

3.5 四种场景对比总结

下面这张图把这四种场景的核心逻辑串起来了。你可以对照着看，自己项目里遇到的是哪一种。

3.6 实战中的排查思路

遇到粘包问题，我一般按这个顺序排查：

1. 先抓包——用 Wireshark 或 tcpdump 看实际报文，确认是不是真的粘包了
2. 看发送频率——连续小包？间隔多少毫秒？
3. 看接收端处理速度——是不是业务逻辑太慢导致读取不及时？
4. 看网络状况——有没有丢包重传？链路延迟是否正常？
5. 检查协议设计——有没有长度头？有没有消息边界标识？