4. 拆包现象演示：发送一条大数据，观察被拆分成多个TCP段接收

上一章我们聊了粘包，这次来聊聊它的“亲兄弟”——拆包。说白了，就是发送方一次发了一大块数据，TCP 觉得“这玩意儿太大了，我得切几刀再送”。接收方那边呢，就得分好几次才能收完。

我刚开始学 Socket 的时候，总觉得 TCP 是“水管”，发多少就流过去多少。后来用 Wireshark 一抓包，才发现根本不是那么回事。数据在传输层被切成了小块，每一块都带着自己的序号，像快递包裹一样各自上路。

为什么 TCP 要拆包？

原因其实很简单——MSS（最大报文段长度）的限制。MSS 是 TCP 层能承载的最大数据量，它通常等于 MTU（最大传输单元）减去 IP 头和 TCP 头的长度。

举个例子：

  • 以太网的 MTU 一般是 1500 字节
  • IP 头占 20 字节，TCP 头占 20 字节
  • 所以 MSS = 1500 - 20 - 20 = 1460 字节

你想想看，如果你一次发送 5000 字节的数据，TCP 就得把它切成至少 4 个段（1460 + 1460 + 1460 + 620）。每个段独立发送，独立确认。

核心概念：拆包不是 Bug，是 TCP 的正常行为。它保证了数据能在不同网络环境下顺利传输。如果网络中间有个路由器 MTU 更小，TCP 还会继续切。

实战演示：发送大数据，观察拆包

我们来写一个简单的例子。服务端接收 10000 字节，客户端一次性发送 10000 字节。看看服务端要 recv 多少次才能收完。

服务端代码（拆包观察者）

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("[服务端] 等待客户端连接...")

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

    total_received = 0
    recv_count = 0
    buffer_size = 1024  # 每次最多读 1024 字节

    while total_received < 10000:
        data = conn.recv(buffer_size)
        if not data:
            break
        recv_count += 1
        total_received += len(data)
        print(f"[第 {recv_count} 次 recv] 收到 {len(data)} 字节，累计 {total_received}/10000")

    print(f"[服务端] 接收完成，共 recv {recv_count} 次")
    conn.close()
    server_socket.close()

if __name__ == '__main__':
    tcp_server()

客户端代码（一次性发送）

import socket

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

    # 构造 10000 字节的数据
    data_to_send = b'A' * 10000
    print(f"[客户端] 准备发送 {len(data_to_send)} 字节")

    # 一次性发送
    sent = client_socket.send(data_to_send)
    print(f"[客户端] send 返回 {sent} 字节")

    client_socket.close()

if __name__ == '__main__':
    tcp_client()

运行结果（典型输出）

[服务端] 等待客户端连接...
[服务端] 客户端已连接: ('127.0.0.1', 54321)
[第 1 次 recv] 收到 1024 字节，累计 1024/10000
[第 2 次 recv] 收到 1024 字节，累计 2048/10000
[第 3 次 recv] 收到 1024 字节，累计 3072/10000
[第 4 次 recv] 收到 1024 字节，累计 4096/10000
[第 5 次 recv] 收到 1024 字节，累计 5120/10000
[第 6 次 recv] 收到 1024 字节，累计 6144/10000
[第 7 次 recv] 收到 1024 字节，累计 7168/10000
[第 8 次 recv] 收到 1024 字节，累计 8192/10000
[第 9 次 recv] 收到 1024 字节，累计 9216/10000
[第 10 次 recv] 收到 784 字节，累计 10000/10000
[服务端] 接收完成，共 recv 10 次

看到了吗？客户端只调了一次 send()，但服务端调了 10 次 recv() 才收完。这就是拆包现象。

个人经验：我在做一个文件传输工具时，客户端一次 send 了 10MB 的文件，服务端 recv 了上千次。当时我以为是代码写错了，后来才明白——TCP 就是这样工作的。你永远不能假设一次 recv 就能拿到完整的数据包。

拆包背后的 TCP 机制

TCP 拆包的核心逻辑可以用一张图来说明：

TCP 拆包过程示意图 应用层：10000 字节 段1：1460 字节 段2：1460 字节 段3：1460 字节 段4：620 字节 网络传输（IP 层分包 + 路由） 第1次 recv：1024 第2次 recv：1024 第3次 recv：1024 ... 共 10 次 注意：接收缓冲区大小（1024）小于 TCP 段大小（1460） 所以一次 recv 只能读一部分，需要多次读取才能收完

影响拆包数量的因素

拆包到底拆成几段，不是固定的。它受下面几个因素影响：

因素 说明 对拆包的影响
MSS 最大报文段长度，通常 1460 字节 数据量超过 MSS 时必然拆包
接收缓冲区大小 服务端 recv 时指定的 buffer_size 缓冲区越小，recv 次数越多
网络拥塞 TCP 拥塞控制算法 拥塞时可能减小发送窗口，导致更多拆包
Nagle 算法 延迟发送小包，合并后再发 可能减少拆包次数，但增加延迟

避坑指南：我曾经在一个高并发服务里，把接收缓冲区设成了 64 字节做测试。结果一个 100KB 的请求，服务端 recv 了 1600 多次，CPU 直接飙到 90%。后来我把缓冲区调到 8192 字节，recv 次数降到了 13 次，性能瞬间正常了。所以，缓冲区大小不是越小越好，要根据实际数据量来调。

如何判断发生了拆包？

在实际开发中，你不需要去数 recv 次数。真正需要关注的是：应用层消息是否完整。拆包本身不是问题，问题在于你的代码能不能正确处理它。

判断拆包的方法：

  1. 抓包分析：用 Wireshark 或 tcpdump 看 TCP 段的长度
  2. 日志记录：在 recv 循环中打印每次收到的字节数
  3. 应用层协议：在消息头部加上长度字段，接收时先读长度，再读完整消息

嗯，这里要注意：拆包和粘包经常同时出现。比如你连续发送两条消息，TCP 可能把第一条的尾部跟第二条的头部粘在一起，也可能把一条消息拆成两段。所以，应用层协议的设计才是解决这些问题的根本。

← 上一章 📖 返回目录 下一章 →