TCP 粘包是什么？
TCP 粘包（TCP Packet Merging） 是指多个小的数据包在 TCP 传输过程中被合并在一起，接收方读取时无法正确分辨数据边界，导致数据解析错误。
TCP 是流式协议 ，没有数据包的概念，它只是保证数据按照字节流 的顺序传输，不保证接收方能按照原始发送时的数据边界来接收数据。因此，TCP 可能会把多个数据包合并（粘包）或者拆分（拆包）。
1. TCP 粘包的两种情况
（1）发送端导致的粘包
当发送方的数据量较小 ，TCP 不会立即发送 ，而是等缓冲区满了再一起发送 ，这样可以减少网络开销 。导致多个小数据包合并成一个大的数据包，产生粘包。
示例
假设我们在 TCP 连接中连续发送三条消息：
send(socket, "Hello", 5, 0);
send(socket, "World", 5, 0);
send(socket, "!!!", 3, 0);
如果 TCP 将这三次 send 的数据合并在一起，接收方可能会收到：
HelloWorld!!!
这样就无法判断消息边界，导致解析困难。
原因
- TCP 有 Nagle 算法 （默认开启）：
-
小数据会被合并，等待缓冲区满了才一起发送，减少小包，提高传输效率。
-
适用于高并发场景，但会导致粘包问题。
-
可以通过
setsockopt关闭：int flag = 1; setsockopt(socket, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int));
-
（2）接收端导致的粘包
接收方 读取数据不及时或者一次性读取了多个数据包 ，导致多个包的数据合并读取，形成粘包。
示例
如果发送方连续发送：
send(socket, "Hello", 5, 0);
send(socket, "World", 5, 0);
send(socket, "!!!", 3, 0);
接收方可能这样读取：
char buffer[20];
recv(socket, buffer, 20, 0);
如果 recv() 读取到了所有数据，buffer 里存的是：
HelloWorld!!!
但接收方可能预期每条消息是独立的，所以会出现粘包问题。
原因
- TCP 是 流式传输 ，没有边界概念，
recv()读取数据时，可能一次读取多个包的内容。 - 如果接收方缓冲区没满 ，但程序没有及时读取，新的数据到来后会追加到原有数据里，造成粘包。
2. TCP 拆包（包被拆分）
除了粘包，拆包（packet fragmentation） 也是常见问题。
如果单次发送的数据超过了 TCP 最大传输单元（MTU） ，TCP 会自动拆分数据包。
示例
假设 send() 发送 5000 字节，而 TCP 的 MTU 设为 1500 字节，则会拆分成：
Packet 1: 1500 bytes
Packet 2: 1500 bytes
Packet 3: 1500 bytes
Packet 4: 500 bytes
这样接收方 recv() 时可能会一次只收到部分数据 ，需要多次 recv() 才能完整还原。
3. 如何解决 TCP 粘包/拆包问题？
由于 TCP 没有消息边界 ，需要在应用层手动处理数据边界：
（1）固定长度协议
如果每条消息长度固定，可以按照固定字节数读取：
recv(socket, buffer, 10, 0); // 一次读取 10 字节
但这种方法仅适用于所有消息长度一致的情况。
（2）特殊分隔符
在消息结尾添加特殊字符，接收方按照这个字符分割数据：
send(socket, "Hello|", 6, 0);
send(socket, "World|", 6, 0);
接收方：
char buffer[1024];
recv(socket, buffer, 1024, 0);
然后通过 | 来拆分数据：
char *token = strtok(buffer, "|");
while (token) {
printf("Received message: %s\n", token);
token = strtok(NULL, "|");
}
缺点：
- 需要保证
|不会出现在正常数据中。 - 需要解析和处理数据，稍微增加了协议复杂度。
（3）消息头 + 消息体（推荐）
在数据前面加上消息长度，接收方先读取长度，再读取完整数据：
struct Message {
uint32_t length; // 4字节，表示消息长度
char data[1024]; // 消息体
};
发送数据：
uint32_t len = htonl(strlen(data)); // 转换为网络字节序
send(socket, &len, 4, 0); // 先发送长度
send(socket, data, strlen(data), 0); // 再发送数据
接收方：
uint32_t len;
recv(socket, &len, 4, 0); // 先读取 4 字节长度
len = ntohl(len); // 转换回主机字节序
recv(socket, buffer, len, 0); // 再读取数据
优势：
- 适用于任何长度的消息，比定长方案更灵活。
- 不会出现边界问题，比分隔符方案更可靠。
4. 总结
粘包的原因
- 发送端合并小数据包（TCP 缓冲区满了才发，Nagle 算法）。
- 接收端一次性读取多个数据包（TCP 没有消息边界）。
如何解决
| 方案 | 适用场景 | 复杂度 |
|---|---|---|
| 固定长度消息 | 适用于消息长度固定的协议 | 低 |
特殊分隔符 （如 \n、` |
`） | 适用于文本协议（如 HTTP） |
| 消息头 + 消息体（推荐） | 适用于二进制协议（如 TCP 长连接） | 高 |
重点
- TCP 是流式协议，没有边界，需要应用层协议解决粘包问题！
- 消息头 + 消息体方式最通用，适用于大部分场景。🚀
这样就能高效避免 TCP 粘包问题啦！🎯