第一章：粘包拆包现象演示
大家好，我是你们这门课的老朋友。今天咱们来聊聊网络编程里一个特别基础、但又特别容易踩坑的问题——粘包和拆包。
说实话，我刚开始做网络编程那会儿，第一次遇到粘包，整个人是懵的。明明我发了两个包，对面怎么只收到一个？后来查了半天资料才明白，哦，原来TCP协议是流式协议，它不关心你发了几次，只关心数据流本身。嗯，今天咱们就把这个现象彻底搞明白。
什么是粘包？
粘包，说白了就是：发送方连续发送了多个小数据包，接收方一次就把它们全收走了。
你想想看，TCP是面向流的协议。它没有消息边界的概念。你调用两次send()，底层可能就把这两段数据合并成一个TCP报文段发出去。接收方调用一次recv()，就把两段数据一起读走了。
为什么会这样？
- Nagle算法：TCP默认开启Nagle算法，它会把小数据攒起来，等到一定量再发。我当年调优一个游戏服务器时，就被这个算法坑过——玩家发的小指令全被攒在一起了，服务器收到后解析出错。
- TCP缓冲区：发送方和接收方都有缓冲区。数据先到缓冲区，再被应用程序读取。如果接收方读得慢，缓冲区里就会积压多个消息。
核心要点：粘包不是TCP协议的错误，而是应用层需要自己处理消息边界的问题。
什么是拆包？
拆包正好相反：发送方发了一个大数据包，接收方分多次才读完。
为什么会拆包？原因也很简单：
- MSS限制：TCP有最大报文段长度（MSS），一般1460字节左右。你发一个10KB的数据包，TCP必须把它拆成多个报文段发送。
- MTU限制：网络链路层的最大传输单元（MTU）通常是1500字节。超过这个大小，IP层会分片，TCP层也会拆分。
- 接收缓冲区大小：recv()调用时，你指定的缓冲区大小可能小于对方发送的数据量。比如你只给了1024字节的缓冲区，对方发了2048字节，那你就得读两次。
我的经验：我曾经做一个文件传输工具，客户端发一个1MB的图片，服务端recv()只给了4096字节的缓冲区。结果一个图片要读两百多次才读完。这就是典型的拆包场景。
用Python演示粘包现象
光说不练假把式。咱们直接上代码，看看粘包到底长什么样。
先写一个服务端：
# server_sticky.py
import socket
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('127.0.0.1', 8888))
server.listen(1)
print('服务端启动，等待连接...')
conn, addr = server.accept()
print(f'客户端连接：{addr}')
# 只调用一次recv，看看能收到什么
data = conn.recv(1024)
print(f'收到数据（长度{len(data)}）：{data}')
conn.close()
server.close()再写一个客户端：
# client_sticky.py
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8888))
# 连续发送两个小数据包
client.send(b'Hello, ')
client.send(b'World!')
print('客户端发送完成')
client.close()运行结果：
服务端启动，等待连接...
客户端连接：('127.0.0.1', 54321)
收到数据（长度13）：b'Hello, World!'看到了吗？客户端明明发了两次，服务端一次recv就把两个包全收走了。这就是粘包。
注意：粘包不一定每次都发生。如果两次send之间间隔足够长，或者数据量刚好凑巧，也可能不粘。但作为开发者，你必须假设它会发生。
用Python演示拆包现象
拆包的演示也很简单。咱们让客户端发一个大包，服务端用小缓冲区去读。
服务端代码：
# server_split.py
import socket
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('127.0.0.1', 8889))
server.listen(1)
print('服务端启动，等待连接...')
conn, addr = server.accept()
print(f'客户端连接：{addr}')
# 故意用小缓冲区，每次只读10字节
total_data = b''
while True:
chunk = conn.recv(10)
if not chunk:
break
total_data += chunk
print(f'收到分片（长度{len(chunk)}）：{chunk}')
print(f'完整数据（总长度{len(total_data)}）：{total_data}')
conn.close()
server.close()客户端代码：
# client_split.py
import socket
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8889))
# 发送一个大数据包
big_data = b'A' * 100 + b'B' * 100 + b'C' * 100
client.send(big_data)
print(f'客户端发送完成，总长度{len(big_data)}')
client.close()运行结果：
服务端启动，等待连接...
客户端连接：('127.0.0.1', 54322)
收到分片（长度10）：b'AAAAAAAAAA'
收到分片（长度10）：b'AAAAAAAAAA'
收到分片（长度10）：b'AAAAAAAAAA'
...（省略中间输出）
收到分片（长度10）：b'CCCCCCCCCC'
完整数据（总长度300）：b'AAA...BBB...CCC...'300字节的数据，被拆成了30次接收。这就是拆包。
避坑指南：我曾经写一个网络服务，recv缓冲区设成4096，以为够大了。结果对方发了一个10KB的请求头，我一次没读完，后面的解析全乱了。从那以后，我养成了一个习惯——永远用循环去recv，直到收完为止。
粘包拆包的核心逻辑图
为了让你更直观地理解，我画了一张流程图：
粘包和拆包的本质区别
| 对比项 | 粘包 | 拆包 |
|---|---|---|
| 发生场景 | 连续发送多个小数据包 | 发送一个大数据包 |
| 根本原因 | Nagle算法、TCP缓冲区合并 | MSS限制、MTU限制、recv缓冲区小 |
| 接收方表现 | 一次recv读到多个消息 | 多次recv才能读完一个消息 |
| 常见影响 | 消息边界丢失，解析出错 | 消息不完整，需要拼接 |
一句话总结：粘包是多个消息挤在一起，拆包是一个消息被撕成几片。两者都是TCP流式传输的自然结果，不是bug，但你必须处理。
好了，这一章的内容就到这儿。你亲手跑一遍代码，感受一下粘包和拆包到底是怎么回事。下一章咱们聊聊怎么解决这些问题——消息边界划分的几种常用方案。
可可精品资料库