3. 粘包拆包问题复现：用 Python socket 亲手制造“事故现场”
说实话，光讲理论不写代码，总觉得隔靴搔痒。这一章我们就来点实际的——用 Python 的 socket 模块，把粘包和拆包这两个“妖怪”请出来，亲眼看看它们长什么样。
我刚开始学网络编程时，也以为只要 send 一次、recv 一次就完事了。直到有一次在调试一个文件传输工具，发现接收端拿到的数据总是对不上号……嗯，从那以后我才真正重视起这个问题。
3.1 先搭个最简单的实验环境
我们不需要复杂的框架，一个服务端、一个客户端，用 TCP 通信就够了。TCP 是流式协议，数据像水管里的水一样连续不断，这正是粘包拆包的根源。
核心思路：服务端连续发送多条小消息，客户端尝试一次性接收。观察客户端收到的数据是否和发送时完全一致。
服务端代码（server.py）
import socket
import time
def server():
# 创建 TCP socket
server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server_sock.bind(('127.0.0.1', 8888))
server_sock.listen(5)
print("[服务端] 启动，等待连接...")
conn, addr = server_sock.accept()
print(f"[服务端] 客户端 {addr} 已连接")
# 连续发送 3 条短消息
messages = [b"Hello", b"World", b"Python"]
for msg in messages:
print(f"[服务端] 发送: {msg}")
conn.send(msg)
time.sleep(0.01) # 极短间隔，模拟高并发场景
conn.close()
server_sock.close()
if __name__ == "__main__":
server()客户端代码（client.py）
import socket
def client():
client_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_sock.connect(('127.0.0.1', 8888))
# 一次性接收 1024 字节
data = client_sock.recv(1024)
print(f"[客户端] 收到: {data}")
client_sock.close()
if __name__ == "__main__":
client()小提示：服务端用 time.sleep(0.01) 只是为了让发送间隔更短，更容易触发粘包。实际生产环境中，网络延迟和缓冲区大小才是主因。
3.2 运行看看——粘包现象出现了
先启动服务端，再启动客户端。你猜结果是什么？
服务端输出：
[服务端] 启动，等待连接...
[服务端] 客户端 ('127.0.0.1', 54321) 已连接
[服务端] 发送: b'Hello'
[服务端] 发送: b'World'
[服务端] 发送: b'Python'客户端输出：
[客户端] 收到: b'HelloWorldPython'看到了吧？客户端明明只调了一次 recv(1024)，却把三条消息全收进来了。这就是典型的粘包——多条小数据合并成一条，接收端无法区分边界。
注意：粘包不是每次必现的。如果你把 time.sleep(0.01) 改成 time.sleep(1)，很可能就正常分开了。但网络环境不可控，我们不能赌运气。
3.3 拆包现象——消息被“切”开了
粘包看完了，那拆包呢？拆包通常发生在消息体比较大的时候。比如你发送 10KB 的数据，但接收缓冲区只有 4KB，一次 recv 只能拿到一部分。
我们来模拟一下：
修改后的服务端（发送大消息）
import socket
def server_big():
server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server_sock.bind(('127.0.0.1', 8889))
server_sock.listen(5)
conn, addr = server_sock.accept()
# 发送一条 10000 字节的消息
big_msg = b"A" * 10000
conn.send(big_msg)
print(f"[服务端] 已发送 10000 字节")
conn.close()
server_sock.close()
if __name__ == "__main__":
server_big()修改后的客户端（用小缓冲区接收）
import socket
def client_small():
client_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_sock.connect(('127.0.0.1', 8889))
# 故意用很小的缓冲区
chunk1 = client_sock.recv(4096)
print(f"[客户端] 第一次收到 {len(chunk1)} 字节")
chunk2 = client_sock.recv(4096)
print(f"[客户端] 第二次收到 {len(chunk2)} 字节")
chunk3 = client_sock.recv(2048)
print(f"[客户端] 第三次收到 {len(chunk3)} 字节")
client_sock.close()
if __name__ == "__main__":
client_small()运行结果：
[客户端] 第一次收到 4096 字节
[客户端] 第二次收到 4096 字节
[客户端] 第三次收到 1808 字节一条完整的 10000 字节消息，被拆成了 3 段。这就是拆包。接收端如果不知道原始消息的长度，根本拼不回去。
关键认知：粘包和拆包是 TCP 流式传输的一体两面。小消息容易粘，大消息容易拆。解决方案的核心就是——让接收端知道每条消息从哪里开始、到哪里结束。
3.4 一张图看懂粘包拆包
我画了一张流程图，把这两种情况放在一起对比，你一看就明白。
3.5 为什么 TCP 会这样？
你可能会问：为什么 UDP 没有这个问题？因为 UDP 是面向数据报的，每次 sendto 就是一个独立报文，接收端 recvfrom 拿到的就是完整的一条。但 TCP 是流式协议，它只保证字节顺序，不保证消息边界。
我个人习惯把 TCP 想象成一根水管：你往里面倒水（发送数据），对方从另一头接水（接收数据）。如果倒得快、接得慢，水就会积在管子里；如果倒得慢、接得快，管子可能空转。粘包和拆包，就是这种“供需不匹配”的体现。
避坑指南：我曾经在一个物联网项目中，设备端每 100ms 发送一次传感器数据，服务端用 recv(1024) 接收。结果发现服务端经常一次收到 5~6 条数据，导致解析错位。后来加了消息头长度字段才解决。这个方案我们下一章会详细讲。
3.6 总结一下本章要点
| 现象 | 触发条件 | 典型表现 | 危害 |
|---|---|---|---|
| 粘包 | 多条小消息连续发送，间隔极短 | 一次 recv 收到多条消息 | 无法区分消息边界，解析错乱 |
| 拆包 | 单条消息大于接收缓冲区 | 一条消息分多次 recv 才能收完 | 数据不完整，需要手动拼接 |
现在你已经亲手“制造”了粘包和拆包，也亲眼看到了它们的真面目。别慌，这两种情况都有成熟的解决方案。下一章我们会深入探讨最经典的方法——消息头+消息体的定长/变长协议设计。
嗯，代码在手，心里不慌。先把今天的实验跑一遍，感受一下 TCP 的“脾气”。