4、粘包解决方案（一）：固定长度法——原理、实现、优缺点分析、适用场景

粘包问题，说白了就是接收端不知道一条消息在哪儿结束，下一条又在哪儿开始。TCP 是流式协议，它只管把字节流丢给你，才不管什么消息边界。我早年做第一个网络项目时就被这个坑过——服务端收到一堆乱码，调试了一整天才发现是粘包。

解决思路其实很朴素：让每个数据包都一样长。这就是固定长度法。

4.1 原理：约定长度，按尺寸切分

发送端和接收端事先约定一个固定长度 L。发送时，每条消息都凑够 L 字节再发；接收端每次从缓冲区里读 L 字节，就是一个完整消息。

消息不够长怎么办？补位。用空字符、空格或 \0 填充到 L 字节。接收端拿到后，再根据业务规则把填充部分去掉。

核心公式：

发送：msg → pad(msg, L) → send(L bytes)

接收：recv(L bytes) → trim(padding) → msg

举个例子。假设约定 L = 8 字节：

原始消息: "Hi"
填充后:   "Hi\0\0\0\0\0\0"
发送字节: 48 69 00 00 00 00 00 00

原始消息: "Hello"
填充后:   "Hello\0\0\0"
发送字节: 48 65 6C 6C 6F 00 00 00

原始消息: "TCP粘包"
填充后:   "TCP粘包"  (UTF-8 正好 8 字节)
发送字节: 54 43 50 E7 B2 98 E5 8C 85

接收端每次读 8 字节，然后 trim 掉尾部的 \0，就还原出原始消息了。

4.2 实现：一个简单的 C 语言示例

我习惯用 C 来演示底层逻辑，因为内存操作看得最清楚。下面是一个完整的发送-接收示例：

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>

#define FIXED_LEN 16  // 固定长度

// 发送：填充后发送
int send_fixed(int sockfd, const char *msg, int msg_len) {
    char buf[FIXED_LEN];
    memset(buf, 0, FIXED_LEN);           // 用 \0 填充
    memcpy(buf, msg, msg_len < FIXED_LEN ? msg_len : FIXED_LEN);
    return send(sockfd, buf, FIXED_LEN, 0);
}

// 接收：读取固定长度，去除填充
int recv_fixed(int sockfd, char *out, int out_size) {
    char buf[FIXED_LEN];
    int n = recv(sockfd, buf, FIXED_LEN, 0);
    if (n <= 0) return n;

    // 找到第一个 \0 的位置，截断
    int real_len = strnlen(buf, FIXED_LEN);
    if (real_len > out_size - 1) real_len = out_size - 1;
    memcpy(out, buf, real_len);
    out[real_len] = '\0';
    return real_len;
}

// 使用示例
void demo() {
    int sock; // 假设已连接
    send_fixed(sock, "Hello", 5);
    send_fixed(sock, "World!", 6);

    char recv_buf[32];
    recv_fixed(sock, recv_buf, sizeof(recv_buf)); // "Hello"
    recv_fixed(sock, recv_buf, sizeof(recv_buf)); // "World!"
}

避坑指南：我曾经在填充字符上吃过亏。如果用空格填充，消息本身末尾的空格会被误删。建议用 \0 填充，配合 strnlen 截断，这样二进制数据也能正确处理。

4.3 优缺点分析

固定长度法是最简单的粘包解决方案，但它的优缺点都很极端。

维度	评价	说明
实现复杂度	⭐ 极低	不需要解析协议头，不需要状态机，几行代码搞定
解析性能	⭐ 极高	O(1) 时间复杂度，每次读固定字节，无分支预测开销
内存效率	❌ 极低	短消息浪费大量填充字节，长消息被截断
灵活性	❌ 极差	所有消息必须等长，无法适应变长业务
扩展性	❌ 差	修改长度需要两端同时升级，协议不兼容

说白了，固定长度法是用带宽换简单。你想想看，如果每条消息都固定 1KB，哪怕只传一个 "OK" 也要占满 1KB，这在物联网或高频交易场景下是灾难。

注意：固定长度法对二进制数据不友好。如果消息本身包含 \0 字节，用 strnlen 截断会得到错误结果。处理二进制数据时，建议改用计数法或分隔符法。

4.4 适用场景

固定长度法不是万能药，但在某些场景下它反而是最优解。我根据实际项目经验总结了几类典型场景：

物联网传感器数据：温度、湿度、气压等数值通常用固定字节数表示（如 4 字节 float），每条消息结构完全一致。
金融行情快照：股票买卖盘口数据，每个档位的价格和数量字段长度固定，用固定长度法可以做到纳秒级解析。
音视频帧数据：某些编码格式的帧大小固定（如 G.711 语音帧 160 字节），天然适合固定长度传输。
嵌入式系统通信：MCU 资源受限，固定长度法不需要动态内存分配，代码体积小，运行稳定。
内部 RPC 调用：同一团队维护的微服务之间，如果消息结构简单且长度固定，用这个方法可以省去序列化开销。

嗯，这里要注意：一旦业务消息长度变化超过 20%，就不适合用固定长度法了。比如你原来固定 64 字节，后来某个字段从 int 改成 string，长度可能膨胀到 256 字节，这时候填充浪费就太大了。

4.5 核心逻辑流程图

下面这张图展示了固定长度法的完整数据流。我特意把发送端和接收端的处理步骤分开画，方便你理解。

4.6 总结：什么时候选它？

固定长度法就像一把扳手——功能单一，但拧对螺丝时特别好用。我个人选择它的判断标准就三条：

消息长度是否稳定？ 如果 90% 的消息长度波动在 ±10% 以内，可以考虑。
解析性能是否是瓶颈？ 在网关、防火墙等需要线速转发的场景，固定长度法能省掉大量 CPU 周期。
是否愿意接受带宽浪费？ 内网带宽便宜，公网或无线网络带宽贵，这个要算清楚。

我曾经在一个工业网关项目里用过固定长度法。传感器每 100ms 上报一次数据，每条 12 字节，固定长度 16 字节。虽然浪费了 25% 的带宽，但网关的 CPU 占用率从 60% 降到了 15%。嗯，值了。

当然，如果你的业务消息长度变化很大，或者需要兼容多种客户端，那固定长度法就不太合适了。下一类方案——分隔符法，会更灵活。不过那是另一个话题了。

📚 课程目录

4、粘包解决方案（一）：固定长度法——原理、实现、优缺点分析、适用场景

4.1 原理：约定长度，按尺寸切分

4.2 实现：一个简单的 C 语言示例

4.3 优缺点分析

4.4 适用场景

4.5 核心逻辑流程图

4.6 总结：什么时候选它？