4. 粘包现象模拟：用Python写一个TCP服务端和客户端，故意制造粘包场景

理论讲再多，不如亲手造一个坑。这一章我们直接动手，用Python写一个简单的TCP服务端和客户端，故意把粘包现象复现出来。你想想看，只有亲眼看到数据粘在一起，你才能真正理解它为什么发生。

我个人习惯，学网络协议一定要先会"造故障"。我在项目中遇到过好几次线上问题，最后定位都是粘包导致的。所以这一章，咱们就从零开始，造一个典型的粘包场景。

4.1 粘包产生的核心条件

先理清楚，粘包不是TCP的bug，而是TCP的"特性"。它之所以发生，说白了就两个条件：

  • 发送端：连续发送多个小数据包，且间隔时间极短
  • 接收端：没有及时读取，或者一次读取了多个包

TCP是流式协议，它只保证字节顺序，不保证消息边界。你发送了两次write，对方可能一次read就把两段数据全拿走了。这就是粘包。

核心结论：粘包是TCP流式传输的必然结果，不是异常。应用层必须自己解决消息边界问题。

4.2 服务端代码：故意不处理边界

我们先写服务端。这个服务端很简单，它接收客户端发来的数据，然后原样打印出来。注意，我故意不做任何拆包处理，就让它一次recv收多少算多少。

import socket
import threading

def handle_client(conn, addr):
    print(f"[新连接] {addr}")
    try:
        while True:
            # 故意用较大的缓冲区，一次收多个包
            data = conn.recv(1024)
            if not data:
                break
            # 直接打印收到的原始数据，不做任何拆包
            print(f"[收到] {data}")
    except ConnectionResetError:
        print(f"[断开] {addr}")
    finally:
        conn.close()

def start_server(host='127.0.0.1', port=8888):
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server.bind((host, port))
    server.listen(5)
    print(f"[服务端启动] {host}:{port}")

    while True:
        conn, addr = server.accept()
        thread = threading.Thread(target=handle_client, args=(conn, addr))
        thread.start()

if __name__ == '__main__':
    start_server()

这段代码里，recv(1024)是粘包的关键。客户端如果连续发几个小包，服务端很可能一次recv就把它们全收进来了。

小技巧：我在调试时习惯把recv缓冲区设大一点，这样更容易复现粘包。如果你设成recv(1)，反而很难看到粘包效果。

4.3 客户端代码：连续发送小数据包

客户端这边，我们故意连续发送多个小消息，中间不加任何延迟。这样TCP的Nagle算法会把这些小包合并成一个TCP段发送出去。

import socket
import time

def start_client(host='127.0.0.1', port=8888):
    client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client.connect((host, port))

    # 故意连续发送多个小消息，模拟粘包场景
    messages = [
        b"Hello",
        b"World",
        b"TCP",
        b"Sticky",
        b"Packet"
    ]

    print("[客户端] 开始连续发送消息...")
    for msg in messages:
        client.send(msg)
        # 注意：这里故意不加time.sleep()
        # 让TCP有机会合并这些小包

    print("[客户端] 发送完成，等待接收...")
    time.sleep(1)

    # 接收服务端的回显（如果有）
    try:
        response = client.recv(1024)
        print(f"[客户端收到] {response}")
    except:
        pass

    client.close()

if __name__ == '__main__':
    start_client()

注意看，我连续发了5条消息，每条都很短，而且中间没有sleep。这就是粘包的温床。

4.4 运行效果：亲眼看看粘包长什么样

先启动服务端，再启动客户端。你会看到服务端打印出类似这样的结果：

[服务端启动] 127.0.0.1:8888
[新连接] ('127.0.0.1', 54321)
[收到] b'HelloWorldTCPStickyPacket'

看到了吗？5条消息全部粘在一起了！服务端只调用了一次recv，就把所有数据都收走了。这就是典型的粘包现象。

为什么会这样？因为TCP的Nagle算法和发送端的连续写入，让这5个小包在发送缓冲区里合并成了一个TCP段。接收端一次recv就把整个段读走了。

注意：粘包不是每次都会发生。如果你在客户端每条消息后加一个time.sleep(0.1)，很可能就不会粘包了。因为TCP有超时机制，等待一段时间后就会把缓冲区里的数据发送出去。

4.5 粘包发生的完整流程

我用一张SVG图来展示粘包发生的完整流程，这样你理解起来更直观。

粘包发生流程图 客户端 send("Hello") send("World") send("TCP") send("Sticky") send("Packet") TCP传输层 Nagle算法合并 小包合并成一个大段 合并后的TCP段 "HelloWorldTCPStickyPacket" 服务端 recv(1024) 一次收到所有数据 结果：5条消息粘成一个包，服务端无法区分消息边界

4.6 粘包与拆包的对比

为了让你更清楚地区分这两个概念，我整理了一个对比表：

现象 描述 发生原因 典型场景
粘包 多个消息合并成一个包 发送端连续发送小包，Nagle算法合并；或接收端读取不及时 连续发送多条短消息，中间无延迟
拆包 一个消息被拆成多个包 消息体超过MSS（最大段大小），TCP必须分片 发送大文件或长消息时

粘包和拆包是同一个问题的两面。粘包是多个消息合并，拆包是一个消息分裂。但它们的本质都一样——TCP不保证消息边界。

4.7 避坑指南：我曾经踩过的坑

我曾经在一个物联网项目中，设备上报数据时频繁出现解析错误。排查了两天才发现，是设备端连续发送了多条传感器数据，服务端一次recv收到了好几条，结果按单条消息解析，全乱了。

那次教训让我养成了一个习惯：只要涉及TCP通信，第一件事就是定义消息边界协议。不管是固定长度、特殊分隔符，还是TLV格式，必须先定好。

我的建议：初学者可以先从固定长度消息开始练手。比如每条消息固定4字节，不够补0。这样最简单，也最容易理解。

4.8 本章小结

这一章我们亲手造了一个粘包场景。你看到了，5条消息在服务端被合并成了一条。这不是TCP的错，而是应用层没有处理好消息边界。

记住三个关键点：

  • 粘包是TCP流式传输的必然结果
  • 连续发送小包且不加延迟，最容易复现粘包
  • 解决粘包的唯一方法：应用层自己定义消息边界
← 上一章 📖 返回目录 下一章 →