4、粘包拆包解决方案：固定长度法、特殊分隔符法、长度前缀法（TLV编码）、自定义协议设计

上一章我们聊了粘包拆包到底是怎么发生的。说白了，就是 TCP 的流式传输特性，让应用层分不清消息的边界在哪。

那怎么解决？我这些年做过的项目里，基本就四种主流方案。没有银弹，每种都有它的适用场景。今天我把它们掰开揉碎了讲清楚。

4.1 固定长度法

这个思路最简单——每个消息都发一样长。比如约定 1024 字节，不够就补空格或 \0。

// 发送端：固定 1024 字节
char buf[1024] = {0};
snprintf(buf, sizeof(buf), "%s", "hello");
send(sockfd, buf, 1024, 0);

// 接收端：每次读 1024 字节
char buf[1024];
int n = recv(sockfd, buf, 1024, 0);
// 此时 buf 里一定是一条完整的消息

4.2 特殊分隔符法

给每个消息末尾加一个特殊标记，比如 \r\n、\0，或者自定义的 0xFF 0xFE。接收端读到这个标记，就知道一条消息结束了。

// 发送端：末尾加 \r\n
char *msg = "hello\r\n";
send(sockfd, msg, strlen(msg), 0);

// 接收端：逐字节或逐行读取
// 读到 \r\n 就切分出一条完整消息

HTTP 协议就是这么干的。Header 部分用 \r\n 分隔行，用 \r\n\r\n 表示头部结束。

这个方法的优点是灵活，消息可以变长。缺点是性能一般——你需要逐字节扫描查找分隔符。如果消息体很大，扫描开销不可忽视。

4.3 长度前缀法（TLV编码）

这是目前最主流的方案。每个消息前面加一个固定长度的头部，头部里记录消息体的长度。接收端先读头部，拿到长度，再读对应字节数的消息体。

TLV 是 Type-Length-Value 的缩写。Type 表示消息类型，Length 表示 Value 的长度，Value 是真正的数据。

// 一个简单的 TLV 结构
struct tlv_header {
    uint16_t type;   // 2 字节，消息类型
    uint32_t length; // 4 字节，消息体长度
    // 后面紧跟 length 字节的 value
};

// 发送端
struct tlv_header hdr;
hdr.type = htons(1);        // 网络字节序
hdr.length = htonl(strlen("hello"));
send(sockfd, &hdr, sizeof(hdr), 0);
send(sockfd, "hello", strlen("hello"), 0);

// 接收端
struct tlv_header hdr;
recv(sockfd, &hdr, sizeof(hdr), MSG_WAITALL);
uint32_t body_len = ntohl(hdr.length);
char *buf = malloc(body_len);
recv(sockfd, buf, body_len, MSG_WAITALL);

我个人的习惯是，头部至少包含两个字段：消息总长度（或消息体长度）和消息类型。这样接收端可以提前分配缓冲区，也能根据类型做不同的解析。

4.4 自定义协议设计

实际项目中，很少有人直接用裸的 TLV。大家都会在 TLV 基础上加一些自己的东西，形成自定义协议。

一个典型的自定义协议长这样：

字段	长度	说明
魔数 (Magic Number)	2 字节	固定值如 0xABCD，用于快速校验
版本号 (Version)	1 字节	协议版本，便于兼容升级
消息类型 (Type)	1 字节	请求、响应、心跳等
消息体长度 (Length)	4 字节	后面消息体的字节数
消息体 (Body)	Length 字节	真正的数据，可以是 JSON、Protobuf 等
校验和 (Checksum)	2 字节	对整个包做 CRC16 校验

为什么加魔数？我遇到过一种情况：网络闪断后，服务端收到半截数据，如果没有魔数校验，会把垃圾数据当成正常消息解析，直接崩掉。有了魔数，一校验不对，直接丢弃，安全很多。

校验和也很重要。TCP 虽然保证传输不出错，但网卡、内存、应用程序都可能引入错误。加个校验和，心里踏实。

下面这张图展示了四种方案的对比关系：

4.5 如何选择？

我个人的经验是：

• 内部系统、消息长度固定：用固定长度法，省心。
• 文本协议、需要人眼可读：用特殊分隔符法，比如 HTTP、Redis 协议。
• 二进制协议、高性能要求：用长度前缀法或自定义协议。这是目前最通用的方案，gRPC、MQTT、Kafka 都在用。