2. TCP协议基础回顾：面向字节流、无消息边界、可靠传输
聊粘包拆包之前，咱们得先把TCP的老底摸清楚。很多同学一上来就问我：「为什么我的消息发过去，对方收不全？为什么两条数据粘在一起了？」
嗯，这些问题，根源都在TCP协议本身的三个核心特性上。今天我就带大家把这三点掰开揉碎了讲清楚。
2.1 面向字节流——TCP眼里没有「消息」
先问大家一个问题：当你调用 send() 发送了100个字节，TCP会怎么处理？
很多人以为，TCP会把这100个字节打包成一个「包裹」扔给对端。错！TCP根本不关心你发的是什么。它只把数据看成一条连续的、没有边界的字节河流。
核心理解：TCP的「流」就像水管里的水。你倒进去一杯水，它不会保持杯子的形状流出来，而是和水管里已有的水混在一起，变成一股连续的水流。
我在项目中遇到过这样一个场景：客户端发送了两次数据，第一次50字节，第二次50字节。服务端接收时，可能一次收到100字节，也可能先收到30字节，再收到70字节。你想想看，如果服务端不知道每次该读多少，那不乱套了吗？
这就是粘包拆包的根源之一——TCP不保留应用层消息的边界。
2.2 无消息边界——为什么你的数据会「粘」在一起？
咱们用一张图来直观感受一下：
看到了吗？应用层明明发了三条独立的消息，到了TCP层面，它们就混在一起了。接收端可能一次读到70字节（A+B粘包），也可能只读到20字节（A被拆包）。
避坑指南：我曾经接手过一个项目，开发人员以为TCP会像UDP一样保持消息边界，结果服务端收到的数据总是对不上。排查了三天，最后发现是粘包导致的。从那以后，我每到一个新项目，第一件事就是检查消息边界处理逻辑。
2.3 可靠传输——TCP的「承诺」与「代价」
TCP的可靠传输，说白了就是三个字：不丢、不乱、不重。它通过以下机制来保证：
| 机制 | 作用 | 对粘包拆包的影响 |
|---|---|---|
| 确认应答（ACK） | 接收方收到数据后回复确认 | 数据可能被重传，导致接收端收到重复或乱序的字节流 |
| 超时重传 | 发送方未收到ACK则重发 | 重传的数据可能与新数据在接收端「相遇」，加剧粘包 |
| 序列号 | 每个字节都有编号，保证顺序 | 接收端必须按序列号重组，这本身不产生粘包，但重组后的流依然无边界 |
| 流量控制 | 根据接收方窗口大小调整发送速率 | 窗口变化会导致数据在发送缓冲区堆积，一次发送可能包含多条消息 |
| 拥塞控制 | 网络拥塞时降低发送速率 | 慢启动、拥塞避免等算法会影响数据发送的时机和大小 |
你可能会问：「可靠传输不是好事吗？怎么还成了粘包拆包的帮凶？」
嗯，问题就在这里。TCP为了保证可靠，做了很多「额外操作」。比如，发送方可能因为窗口不足，把多条小消息合并成一个TCP段发送——这就是Nagle算法。接收方也可能因为延迟确认，攒了一批数据才通知应用层来读。
个人经验：我建议你在设计网络协议时，永远不要假设「一次send对应一次recv」。TCP的可靠只保证数据最终完整到达，但不保证以什么方式到达。你想想看，如果每次都要等完整消息才处理，那性能得多差？
2.4 三个特性如何共同导致粘包拆包
咱们把这三个特性串起来看：
- 面向字节流：TCP不关心你的消息结构，它只搬运字节
- 无消息边界：应用层无法从字节流中直接区分消息的起止
- 可靠传输：重传、窗口、Nagle等机制让数据的发送和接收变得「不可预测」
这三个特性加在一起，就导致了两种典型情况：
- 粘包：发送方连续发送多条小消息，TCP把它们合并成一个包发送。接收方一次读到多条消息的数据。
- 拆包：发送方发送一条大消息，TCP把它拆分成多个包发送。接收方需要多次读取才能拼完整。
一句话总结：粘包拆包不是TCP的bug，而是TCP面向字节流设计的必然结果。我们后面要讲的解决方案，本质上都是在应用层「重新划定消息边界」。
2.5 一个简单的实验验证
光说不练假把式。我写了个小demo，你可以跑一下看看效果：
# tcp_stream_demo.py
import socket
import threading
def server():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('127.0.0.1', 8888))
s.listen(1)
conn, addr = s.accept()
# 只调用一次recv，看看能读到多少
data = conn.recv(4096)
print(f"服务端一次读取到 {len(data)} 字节")
print(f"内容: {data}")
conn.close()
def client():
time.sleep(0.5)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 8888))
# 连续发送三条消息
s.send(b'Hello')
s.send(b'World')
s.send(b'TCP')
s.close()
import time
t = threading.Thread(target=server)
t.start()
client()
t.join()
你猜结果是什么？服务端一次读到了15个字节：b'HelloWorldTCP'。三条消息完美粘在了一起。
注意：这个实验在本地环回接口上几乎100%复现粘包。但在真实网络中，由于延迟、丢包等因素，情况会更复杂。有时候粘，有时候拆，这才是常态。
2.6 本章小结
好了，咱们把TCP的三个核心特性捋了一遍：
- 面向字节流：TCP是水管，不是快递员
- 无消息边界：应用层必须自己定义消息的起止
- 可靠传输：可靠是好事，但它带来的重传、窗口等机制加剧了粘包拆包