1. 粘包拆包基础：TCP流与消息边界
各位同学，咱们今天正式开讲。我是老张，干网络这行十几年了，抓过的包少说也有几十万个。今天聊的这个话题——粘包拆包，说白了就是TCP协议里最让人头疼、也最基础的一个坑。
我记得刚入行那会儿，第一次遇到客户端发数据、服务端收不全的情况，我对着Wireshark看了半天，愣是没搞明白。后来才意识到，这根本不是Bug，而是TCP的“天性”。
1.1 TCP流：没有边界的字节管道
先问大家一个问题：TCP是什么？
很多人背过——面向连接、可靠、基于字节流的传输层协议。但“基于字节流”这四个字，恰恰是粘包拆包的根源。
什么叫字节流？说白了，TCP不关心你发的是什么。你发一个“Hello”，它不会帮你标记“这是第1条消息”。它只管把字节按顺序扔进一个管道里，像水流一样，一股脑儿送到对端。
我给大家画个图，看看TCP流到底长什么样。
看到没？发送端明明发了三条独立的消息，但到了TCP管道里，它们就混在一起了。接收端拿到的是一整段字节流，它根本不知道哪里是A的结尾、哪里是B的开头。
这就是粘包拆包问题的根源——应用层有消息边界，TCP没有。
1.2 什么是粘包
粘包，顾名思义，就是多个消息包“粘”在一起了。
举个例子。你写了一个聊天程序，客户端连续发了三条消息：
- 消息1："你好"（6字节）
- 消息2："在吗"（6字节）
- 消息3："吃饭没"（9字节）
服务端recv()一次，读到了21个字节——"你好在吗吃饭没"。这就是粘包。
粘包的本质：多个发送操作的数据，被合并到一次接收中。
1.3 什么是拆包
拆包是另一个方向的问题——一条完整的消息，被拆成了多次接收。
还是那个聊天程序。这次客户端发了一条大消息：
- 消息："这是一条非常长的消息，超过了MSS（最大报文段长度）"（假设50字节）
服务端第一次recv()读到30字节，第二次recv()才读到剩下的20字节。这就是拆包。
拆包的本质：一次发送操作的数据，被分散到多次接收中。
1.4 为什么TCP会粘包
好，现在咱们聊聊根本原因。为什么TCP会粘包？
我总结了一下，主要有三个层面的原因：
| 层面 | 原因 | 说明 |
|---|---|---|
| 发送端 | Nagle算法 | 为了减少小包数量，Nagle会把多个小数据包合并成一个TCP段再发送 |
| 接收端 | TCP接收缓冲区 | 接收端内核缓冲区积累数据，应用层一次recv可能读到多个消息 |
| 网络层 | MSS与IP分片 | 超过MSS的数据会被拆分，但接收端重组后仍可能产生粘包 |
1.4.1 Nagle算法——粘包的“头号元凶”
Nagle算法是TCP协议栈里一个优化机制。它的逻辑很简单：
- 如果发送的数据很小（小于MSS），就先攒着
- 等收到上一个包的ACK，或者攒到足够大，再一起发出去
这个算法在早期网络带宽稀缺的年代很有用。但现在嘛……
TCP_NODELAY = 1，问题解决。
1.4.2 接收缓冲区——粘包的“帮凶”
接收端这边也有问题。TCP内核有一个接收缓冲区，数据到了之后先放缓冲区里。应用层调用recv()时，是从缓冲区里取数据。
如果应用层读得慢，或者一次读太多，就会把多个消息一起读出来。
举个例子：
// 发送端连续发送
send(sock, "msg1", 4, 0);
send(sock, "msg2", 4, 0);
send(sock, "msg3", 4, 0);
// 接收端一次读取
char buf[1024];
int n = recv(sock, buf, sizeof(buf), 0);
// n = 12, buf = "msg1msg2msg3" → 粘包了1.4.3 MSS与IP分片——拆包的“推手”
拆包的原因相对简单。TCP在传输层会把数据切成段，每个段的大小受MSS限制。MSS一般是1460字节（以太网MTU 1500 - IP头20 - TCP头20）。
如果你发了一条3000字节的消息，TCP会把它切成两个段：
- 段1：1460字节
- 段2：1540字节
这两个段在网络中独立传输，到达接收端的时间可能不同。应用层第一次recv()可能只读到段1，第二次才读到段2。这就是拆包。
1.5 粘包拆包的本质总结
说了这么多，咱们用一张图把核心逻辑串起来：
说白了，粘包拆包不是TCP的Bug，而是TCP的Feature。它天生就不管消息边界，把这个问题甩给了应用层。你作为开发者，必须自己想办法解决。
怎么解决？后面几章我会详细讲。但今天先把基础打牢——理解TCP流的本质，理解粘包拆包是什么、为什么发生。地基不稳，后面盖楼全是歪的。
好，第一章就到这里。下节课咱们聊聊怎么用Wireshark抓包，亲眼看看粘包拆包长什么样。