为什么 TCP 协议有粘包问题

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

585 字

2 分钟

为什么 TCP 协议有粘包问题

2023-06-23

技术科普

TCP/IP

/

技术科普

/

底层原理

TCP 粘包问题是网络编程中最常见的问题之一。发送方连续发送多个数据包，接收方却可能一次收到多个合并的数据，或者一个数据包被拆分成多次接收。这是为什么？

一、TCP 的本质：字节流#

1.1 TCP vs UDP 的核心区别#

flowchart LR subgraph UDP（数据报） U1[数据包 A] U2[数据包 B] U1 -->|独立| R1[接收 A] U2 -->|独立| R2[接收 B] Note: 有明确边界 end subgraph TCP（字节流） T1[数据流 A] T2[数据流 B] T1 -->|合并| R3[混合流] T2 -->|合并| R3 Note: 无边界 end

协议	语义	边界
UDP	数据报	有边界，每个 Send 对应一个 Recv
TCP	字节流	无边界，Send 和 Recv 次数无关

1.2 TCP 字节流的本质#

1
# TCP 的读写是字节流，不是消息流
2
# 发送
3
socket.send(b"Hello")      # 5 字节
4
socket.send(b" World")      # 6 字节
5
# 接收
6
data = socket.recv(1024)    # 可能收到 "Hello World" 或其他组合

二、粘包的原因#

2.1 Nagle 算法#

Nagle 算法合并小数据包以减少网络开销：

flowchart LR subgraph Nagle 算法 A[小数据包] --> B{累积？} B -->|是，等待| C[等待 ACK] B -->|否| D[立即发送] C --> E[合并发送] end

合并规则：

如果有未确认的数据，新数据等待 ACK 后发送
如果没有未确认数据，立即发送

2.2 滑动窗口与批量发送#

sequenceDiagram participant S as 发送方 participant N as 网络 participant R as 接收方 S->>N: 数据包 1 S->>N: 数据包 2 S->>N: 数据包 3 N->>R: 可能乱序或合并 Note over R: 接收缓冲区合并数据

滑动窗口允许批量发送，多个数据包可能同时在网络中传输。

2.3 接收缓冲区#

1
# 接收方看到的
2
data = socket.recv(1024)
3
# data 可能是：
4
# - 部分数据包
5
# - 一个完整数据包
6
# - 多个合并的数据包

三、粘包的表现形式#

3.1 粘包（多个包粘在一起）#

1
# 发送
2
send(b"Hello")
3
send(b"World")
4

5
# 接收（可能）
6
recv(1024) -> b"Helloworld"  # 粘在一起

3.2 半包（一个包被拆分）#

1
# 发送
2
send(b"HelloWorld")
3

4
# 接收（可能）
5
recv(5) -> b"Hello"   # 只收到一半
6
recv(1024) -> b"World"  # 另一半

3.3 图解#

flowchart LR subgraph 发送 P1[包 1: ABC] P2[包 2: DEF] end subgraph 网络 N1[ABCDEF] // 粘包 N2[A, BC, DEF] // 半包 end P1 --> N1 P2 --> N1 P1 --> N2 P2 --> N2

四、如何解决粘包问题#

4.1 方案一：固定长度#

1
# 发送方：固定长度 100 字节，不足补空格
2
def send_fixed(sock, data):
3
    if len(data) < 100:
4
        data = data + b' ' * (100 - len(data))
5
    sock.send(data)
6

7
# 接收方：固定长度接收
8
def recv_fixed(sock):
9
    data = b''
10
    while len(data) < 100:
11
        chunk = sock.recv(100 - len(data))
12
        data += chunk
13
    return data.strip()

优点：简单缺点：浪费带宽

4.2 方案二：分隔符#

1
# 使用换行符作为分隔符
2
def send_line(sock, data):
3
    sock.sendall(data + b'\n')
4

5
def recv_line(sock):
6
    data = b''
7
    while True:
8
        chunk = sock.recv(1)
9
        if chunk == b'\n':
10
            return data
11
        data += chunk

优点：直观缺点：数据中不能包含分隔符

4.3 方案三：长度前缀（推荐）#

1
import struct
2

3
def send_length_prefixed(sock, data):
4
    # 先发送 4 字节长度
5
    length = len(data)
6
    sock.sendall(struct.pack('!I', length) + data)
7

8
def recv_length_prefixed(sock):
9
    # 先读取 4 字节长度
10
    length_data = recv_exact(sock, 4)
11
    length = struct.unpack('!I', length_data)[0]
12
    # 再读取对应长度的数据
13
    return recv_exact(sock, length)
14

15
def recv_exact(sock, n):
16
    data = b''
17
    while len(data) < n:
18
        chunk = sock.recv(n - len(data))
19
        if not chunk:
20
            raise ConnectionError("Connection closed")
21
        data += chunk
22
    return data

优点：高效、通用缺点：需要计算长度

4.4 方案四：消息边界协议#

1
// Protocol Buffers 自动处理消息边界
2
message Packet {
3
    required int32 length = 1;
4
    required bytes payload = 2;
5
}

五、应用层协议设计#

5.1 HTTP/1.1 的处理#

HTTP/1.1 使用Content-Length 头处理粘包：

1
HTTP/1.1 200 OK
2
Content-Type: text/plain
3
Content-Length: 13
4

5
Hello, World!

5.2 WebSocket 的处理#

WebSocket 使用帧来定义消息边界：

1
┌────────┬─────────┬───────────┐
2
│ Opcode │ Length  │ Payload   │
3
│ 1 byte │ 1-8B   │ Variable  │
4
└────────┴─────────┴───────────┘

5.3 自定义协议#

1
# 协议格式：Header(4B) + Body(N bytes)
2
# Header: [Version(1B)][Type(1B)][Length(2B)]
3

4
HEADER_SIZE = 4
5

6
def send_packet(sock, packet_type, body):
7
    header = bytes([1, packet_type, len(body) >> 8, len(body) & 0xFF])
8
    sock.sendall(header + body)
9

10
def recv_packet(sock):
11
    header = recv_exact(sock, HEADER_SIZE)
12
    version, ptype, length = header[0], header[1], header[2] << 8 | header[3]
13
    body = recv_exact(sock, length)
14
    return ptype, body