3、粘包问题实战复现：用Python亲手捅破这层窗户纸

说实话，粘包这个问题，几乎每个做TCP开发的人都遇到过。我记得刚入行那会儿，写了个简单的即时通讯模块，服务端收到的消息总是莫名其妙地连在一起。当时我还以为是网卡驱动的问题，折腾了两天才反应过来——哦，这就是传说中的粘包。

今天咱们就亲手复现一下这个现象。你跟着我敲一遍代码，再用Wireshark抓包验证，保证以后面试官问你粘包，你能从原理讲到抓包，再到解决方案，一条龙给他讲明白。

3.1 粘包到底长什么样？

先看个最直观的例子。假设客户端连续发送两条消息：

• 消息A："Hello"
• 消息B："World"

理想情况下，服务端应该收到两条独立的消息。但粘包发生后，服务端可能一次性收到"HelloWorld"，或者收到"Hel" + "loWorld"——反正就是分不清边界。

3.2 实战复现：服务端与客户端代码

我习惯用Python的socket模块来做演示，因为它足够简单，又能把问题暴露得清清楚楚。

3.2.1 服务端代码（故意不做拆包处理）

import socket

def tcp_server():
    server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server_socket.bind(('0.0.0.0', 8888))
    server_socket.listen(5)
    print("[Server] 监听 0.0.0.0:8888 ...")

    conn, addr = server_socket.accept()
    print(f"[Server] 客户端连接: {addr}")

    while True:
        data = conn.recv(1024)  # 一次最多读1024字节
        if not data:
            break
        # 这里故意不做拆包，直接打印收到的原始数据
        print(f"[Server] 收到 {len(data)} 字节: {data}")
        # 原样回显
        conn.sendall(data)

    conn.close()
    server_socket.close()

if __name__ == '__main__':
    tcp_server()

3.2.2 客户端代码（连续发送多条小消息）

import socket
import time

def tcp_client():
    client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client_socket.connect(('127.0.0.1', 8888))

    messages = [b'Hello', b'World', b'TCP', b'Sticky', b'Packet']

    for msg in messages:
        client_socket.sendall(msg)
        print(f"[Client] 发送: {msg}")
        time.sleep(0.01)  # 极短间隔，模拟高并发发送

    # 等待回显
    for _ in range(len(messages)):
        data = client_socket.recv(1024)
        print(f"[Client] 收到回显: {data}")

    client_socket.close()

if __name__ == '__main__':
    tcp_client()

3.3 运行结果分析

启动服务端，再启动客户端。你看到的输出大概是这样：

# 服务端输出
[Server] 监听 0.0.0.0:8888 ...
[Server] 客户端连接: ('127.0.0.1', 54321)
[Server] 收到 14 字节: b'HelloWorldTCPSticky'
[Server] 收到 6 字节: b'Packet'

# 客户端输出
[Client] 发送: b'Hello'
[Client] 发送: b'World'
[Client] 发送: b'TCP'
[Client] 发送: b'Sticky'
[Client] 发送: b'Packet'
[Client] 收到回显: b'HelloWorldTCPSticky'
[Client] 收到回显: b'Packet'

看到了吗？客户端明明发了5条消息，服务端只收到了2次。第一次把"Hello"+"World"+"TCP"+"Sticky"粘在了一起，第二次单独收到了"Packet"。

为什么会这样？

因为TCP的缓冲区机制。客户端连续发送时，数据在发送缓冲区里攒成了一团。服务端调用recv(1024)时，一次就读走了缓冲区里所有能读到的数据。至于这些数据原本是几条消息——TCP不管，它只保证顺序，不保证边界。

3.4 Wireshark抓包验证

光看代码输出还不够，咱们得用Wireshark抓包看看底层到底发生了什么。

3.4.1 抓包步骤

1. 启动Wireshark，选择回环接口（Loopback: lo0 或 Adapter for loopback traffic capture）
2. 设置过滤条件：tcp.port == 8888
3. 重新运行客户端和服务端
4. 停止抓包，找到相关的TCP流

3.4.2 关键观察点

在Wireshark中，右键任意一个TCP包，选择"Follow" → "TCP Stream"。你会看到类似这样的内容：

HelloWorldTCPStickyPacket

Wireshark把整个TCP流的内容拼接成了一行。这说明什么？说明在TCP层面，这些数据就是连续不断的字节流，没有任何分隔符。

再看Packet列表，你会发现：

序号	源端口	目的端口	长度	Info
1	54321	8888	5	PSH, ACK - Hello
2	54321	8888	5	PSH, ACK - World
3	54321	8888	3	PSH, ACK - TCP
4	54321	8888	6	PSH, ACK - Sticky
5	54321	8888	6	PSH, ACK - Packet
6	8888	54321	14	PSH, ACK - HelloWorldTCPSticky
7	8888	54321	6	PSH, ACK - Packet

注意看序号1-5，客户端确实分5次发送了数据。但服务端在序号6一次性回复了14字节。这就是粘包在抓包层面的直接证据。

3.5 粘包发生的根本原因

咱们用一张图把整个流程串起来：

从这张图可以看得很清楚：粘包的本质是发送端合并和接收端合并共同作用的结果。

• 发送端合并：Nagle算法、TCP分段、发送缓冲区策略，都可能把多条小消息合并成一个TCP段发送出去。
• 接收端合并：服务端调用recv()时，如果接收缓冲区里有多个消息的数据，一次recv()就会全部读走。

3.6 粘包的两种典型场景

场景	触发条件	表现
发送端粘包	连续发送小消息，间隔极短（< 200ms）	多个消息合并为一个TCP段发送
接收端粘包	服务端recv()缓冲区设置过大，或读取不及时	一次recv()读取了多条消息

在实际项目中，这两种情况往往同时发生。你想想看，高并发场景下，客户端发得快，服务端读得慢，粘包几乎是必然的。

3.7 小结

这一章咱们亲手复现了粘包现象，也用Wireshark抓包验证了底层行为。核心就一句话：TCP是流，不是消息。应用层如果不自己定义消息边界，粘包就会一直存在。