3. 固定长度协议：设计固定长度消息头

大家好，我是你们的老朋友。今天咱们聊聊网络编程里一个很基础、但又特别容易踩坑的话题——粘包与拆包。

嗯，先说说为什么会有这个问题。TCP 是流式协议，它不关心你发的是几条消息，只关心字节流。你发两次 write，对方可能一次 read 全收走，这叫粘包；也可能一次 read 只收到半条消息，这叫拆包。说白了，就是消息边界没了。

那怎么解决？最朴素的办法就是——固定长度协议。

3.1 什么是固定长度协议

固定长度协议，顾名思义，就是每条消息的长度是固定的。比如我规定每条消息都是 1024 字节。发送方如果数据不够，就补空格或特殊字符填满。接收方每次就读 1024 字节，读完一条，再读下一条。

这样做的好处是什么？边界清晰。接收方不用猜，不用等，读够长度就处理。简单粗暴，适合新手入门。

但缺点也很明显——空间浪费。你想想看，如果我要发一个 "hello"，才 5 个字节，却要填满 1024 字节，剩下 1019 个字节全是空格。这在带宽敏感的场景下，简直是灾难。

我个人习惯用固定长度协议做教学演示，因为它逻辑最直白。但实际项目中，我很少用它处理变长数据。

3.2 服务端与客户端实现

下面我写一个简单的例子。服务端和客户端都用 Python，消息长度固定为 64 字节。

服务端代码

import socket

HOST = '127.0.0.1'
PORT = 8888
FIXED_SIZE = 64

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((HOST, PORT))
server.listen(5)
print(f'服务端启动，监听 {PORT} 端口')

while True:
    conn, addr = server.accept()
    print(f'新连接：{addr}')
    while True:
        data = conn.recv(FIXED_SIZE)
        if not data:
            break
        # 去掉尾部空格，还原原始消息
        msg = data.decode('utf-8').strip()
        print(f'收到消息：{msg}')
        # 回显
        conn.send(data)
    conn.close()

客户端代码

import socket

HOST = '127.0.0.1'
PORT = 8888
FIXED_SIZE = 64

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect((HOST, PORT))

messages = ['hello', 'world', '固定长度协议测试']

for msg in messages:
    # 补空格到固定长度
    send_data = msg.ljust(FIXED_SIZE).encode('utf-8')
    client.send(send_data)
    print(f'发送：{msg}')

    # 接收回显
    recv_data = client.recv(FIXED_SIZE)
    print(f'收到回显：{recv_data.decode("utf-8").strip()}')

client.close()

你看，核心就是 ljust 补空格，接收方用 strip 去掉空格。逻辑简单到不能再简单。

小提示： 实际项目中，补位字符不一定用空格。有时候用 '\0' 更安全，因为空格可能本身就是有效数据。我曾经在日志协议里用空格补位，结果消息里带空格，解析全乱了。后来改成 '\0' 才解决。

3.3 优缺点分析

优点 缺点
实现简单，代码量少 空间浪费严重，尤其短消息
接收逻辑清晰，无粘包困扰 不适合变长数据，比如文本、图片
适合固定格式的指令通信 长度固定后，扩展性差
调试方便，容易定位问题 带宽利用率低，网络开销大

说白了，固定长度协议就是「用空间换简单」。如果你的消息长度变化不大，比如心跳包、状态上报，那用这个方案很合适。但如果你要传输用户昵称、文章内容，那还是趁早换别的方案。

注意： 固定长度协议有一个隐藏坑——如果消息长度超过固定值，会直接截断。我曾经在项目中遇到一个用户昵称超长，结果被截成两半，显示出来乱七八糟。所以，一定要在业务层做长度校验。

3.4 什么时候该用固定长度协议

我总结了几种场景，你可以参考一下：

  • 指令类通信： 比如控制灯开关、设备状态查询，每条指令固定几个字节。
  • 嵌入式设备： 内存和带宽都有限，固定长度好管理。
  • 教学演示： 让新手快速理解粘包问题，固定长度是最直观的解法。
  • 高性能场景： 如果消息长度固定，接收方可以用 memcpy 直接拷贝，零解析开销。

但反过来，如果你要传 JSON、XML、图片、视频，那千万别用固定长度。你会被空间浪费逼疯的。

3.5 核心逻辑流程图

下面我用一张 SVG 图，把固定长度协议的核心流程画出来。你一看就明白。

发送方 接收方 TCP 流 原始消息："hello" 补空格到 64 字节 发送 64 字节数据 读取 64 字节 去掉尾部空格 得到原始消息 网络传输

这张图很直白。发送方把消息补到固定长度再发，接收方读够长度再处理。中间没有歧义，没有等待。这就是固定长度协议的精髓。

3.6 避坑指南

最后，我分享几个实战中踩过的坑：

  • 补位字符选择： 别用空格，用 '\0' 或特定标记。我吃过亏。
  • 长度校验： 如果消息超长，要么截断，要么报错。别默默吞掉。
  • 编码问题： 中文 UTF-8 编码后长度可能变长。固定长度按字节算，不是按字符算。
  • 性能考量： 如果每条消息都很大，固定长度会导致带宽浪费。建议用变长方案。
总结一下： 固定长度协议是解决粘包问题的最简单方案。适合固定格式、短消息的场景。但如果你要传变长数据，建议看看下一章——长度字段协议。

好了，这一章就到这里。代码你拿去跑跑看，有问题随时交流。

可可精品资料库

← 上一章 📖 返回目录 下一章 →