1. 粘包拆包问题概述

做网络编程这么多年，我几乎每次面试都会问这个问题：「说说你对粘包拆包的理解？」

有意思的是，很多人能背出概念，但一问到根因就卡壳了。今天咱们就把这事彻底聊透。

什么是粘包和拆包

先看两个场景。

粘包：你发了两次数据，结果接收方一次全收走了。就像你寄了两个快递，结果快递员把它们捆在一起送过来。

拆包：你发了一次数据，结果接收方分两次才收完。好比寄了一个大箱子，快递员拆成两趟送。

我画了张图，一看就明白：

问题产生的根本原因

说白了，根因就一句话：TCP 是流式协议，没有消息边界。

你调用 send() 发数据，TCP 协议栈只管把字节流塞进发送缓冲区。至于这些字节属于哪条消息？TCP 不关心。它只保证顺序和可靠，不保证消息完整性。

我举个例子你就懂了：

// 发送端：两次 send
send(sock, "Hello", 5, 0);
send(sock, "World", 5, 0);

// 接收端：一次 recv
char buf[1024];
int n = recv(sock, buf, sizeof(buf), 0);
// buf 里可能是 "HelloWorld"（粘包）
// 也可能是 "Hel" + "loWorld"（拆包）
// 也可能是 "Hello" + "World"（运气好，没出问题）

为什么会这样？

因为 TCP 内部有 Nagle 算法、MSS（最大报文段长度）、接收窗口这些机制在起作用。它们会合并、拆分你的数据。你控制不了。

TCP 是流式协议的本质

很多人把 TCP 当成「管道」来理解。你往里倒水，对面接水。你倒一次，对面可能接一次，也可能接好几次。你倒两次，对面可能一次接走。

这就是流式协议的本质——没有消息边界。

我习惯用一个比喻：TCP 就像一条传送带，上面只有一个个字节。你放上去的「消息」只是你心里的概念，传送带不认。它只认字节。

特性	TCP	UDP
协议类型	流式协议	报文协议
消息边界	无	有
数据单元	字节流	数据报
粘包拆包	常见	不存在

UDP 为什么没有这个问题

UDP 是报文协议。你发一次 sendto()，对面 recvfrom() 一次收走。不多不少，刚好一个报文。

为什么？因为 UDP 保留了消息边界。每个 sendto() 调用对应一个独立的 UDP 数据报。接收方一次 recvfrom() 只能收一个数据报。

但注意了——UDP 有它自己的问题：丢包、乱序、无连接。它只是没有粘包拆包，不代表它更好用。

问题对业务的影响

粘包拆包不是「偶尔出现」的问题。在高并发、大数据量的场景下，它几乎必然发生。影响有多大？

• 数据错乱：两条消息粘在一起，解析器把 A 的尾巴 + B 的头当成一条消息，直接解析失败
• 业务逻辑错误：比如金融交易，一条订单消息被拆成两半，前半段校验通过，后半段丢了，订单状态永远卡住
• 内存泄漏：拆包导致数据不完整，程序不断等待后续数据，缓冲区越积越多
• 性能下降：频繁的粘包拆包导致应用层反复重试、超时、重连