乐闻世界logo
5月27日 22:44

TCP 粘包问题是什么？如何解决？

TCP 粘包问题是什么？如何解决？

TCP 粘包是指发送方多次 send 的数据，在接收方被一次性 read 出来，多个消息"粘"在了一起。根本原因是 TCP 是字节流协议，不维护消息边界——它只保证数据可靠、按序到达，但不关心你这条消息从哪开始到哪结束。

粘包是怎么产生的？

发送端：Nagle 算法。多个小包攒成一个大包再发，减少网络开销。这意味着你连续调用两次 send，数据可能被合并成一个 TCP 段发出。

接收端：缓冲区读取时机。应用层 read 的速度慢于数据到达速度，缓冲区里攒了好几条消息，一次 read 全取出来了。

注意：粘包不是 TCP 的 bug，而是字节流协议的设计特性。UDP 就不会有这个问题，因为 UDP 保留消息边界，每次 sendto 对应一次 recvfrom。

怎么解决？

核心思路：在应用层定义消息边界。

1. 固定长度：每条消息固定 N 字节，不够补齐。简单但浪费带宽，实际很少用。

2. 分隔符：消息之间用特殊字符（如 \n）分隔。HTTP/1.1 就是用 \r\n\r\n 分隔头部和 body。缺点是消息内容本身包含分隔符时要转义，处理麻烦。

3. 长度前缀（最常用）：消息头加一个字段表示 body 长度，接收方先读长度再读对应字节数。绝大多数二进制协议都用这种方式。

python
import struct

def send_msg(sock, data: bytes):
    # 前4字节表示消息长度，大端序
    sock.sendall(struct.pack('!I', len(data)) + data)

def recv_msg(sock):
    # 先读4字节拿到长度
    raw = _recv_exact(sock, 4)
    length = struct.unpack('!I', raw)[0]
    # 再读对应长度的body
    return _recv_exact(sock, length)

def _recv_exact(sock, n):
    buf = b''
    while len(buf) < n:
        chunk = sock.recv(n - len(buf))
        if not chunk:
            raise ConnectionError('连接断开')
        buf += chunk
    return buf

面试追问

Q: 关掉 Nagle 算法能解决粘包吗？ 不能。设置 TCP_NODELAY 只解决发送端的合并问题，接收端缓冲区仍然可能一次读出多条消息。粘包的本质是缺乏消息边界，必须由应用层协议解决。

Q: 什么时候不需要处理粘包？ 如果连续发送的数据本身就是一个整体（比如传文件），那接收端粘在一起反而是正确的，不需要额外处理。只有当每条消息是独立的、需要分别处理时，才必须定义边界。

Q: 长度前缀方案，长度字段本身被拆包了怎么办？ 这正是 _recv_exact 函数存在的意义——用循环确保读满指定字节数。这是处理拆包的标准做法。

标签：TCP