4. 自定义协议设计：协议头设计、协议体设计、校验和算法、协议版本控制
讲完了基础的数据封装和解析，咱们得聊聊更实际的东西了——自定义协议。
说实话，我在刚入行那会儿，总觉得协议设计是件特别高大上的事。后来自己动手做项目才发现，说白了就是约定好「咱们怎么聊天」。你发一段数据给我，我怎么知道这数据从哪开始、到哪结束？中间有没有被篡改？版本变了怎么办？
嗯，这一章我们就把这些事掰开揉碎讲清楚。
4.1 协议头设计：聊天的开场白
协议头，就像两个人见面打招呼。你得先告诉对方「我要开始说话了」，然后再说具体内容。
我个人习惯把协议头设计成固定长度。为什么？因为解析起来简单、高效。你想想看，如果协议头长度不固定，你得先读一部分数据才能知道头有多长，这不是给自己找麻烦吗？
一个典型的协议头长这样：
| 字段名 | 长度（字节） | 说明 |
|--------------|--------------|--------------------------|
| 起始标识 | 2 | 固定值 0xAA 0x55 |
| 协议版本 | 1 | 当前版本号 |
| 消息类型 | 1 | 请求/响应/心跳等 |
| 消息体长度 | 4 | 后面消息体的字节数 |
| 校验和 | 2 | 对整个包做校验 |
| 保留字段 | 2 | 留给未来扩展 |
| 总长度 | 12 | 固定 12 字节 |这里有个细节：起始标识。我建议用两个字节，而且不要用常见的 ASCII 字符。0xAA 0x55 就是个经典选择，二进制看起来像「10101010 01010101」，不容易跟普通数据混淆。
4.2 协议体设计：核心内容怎么装
协议头打完招呼，就该说正事了。协议体就是真正的数据内容。
协议体的设计，我一般分三种情况：
- 固定结构体：所有字段长度固定，解析最快。适合传感器数据、状态上报这类场景。
- TLV 格式：Type-Length-Value，每个字段都带类型和长度。灵活，但解析稍慢。
- JSON/XML 文本：可读性好，但解析开销大。适合配置下发、日志上报。
举个例子，一个固定结构的协议体：
| 字段名 | 类型 | 长度（字节） | 说明 |
|------------|----------|--------------|--------------|
| 设备ID | uint32 | 4 | 设备唯一编号 |
| 温度 | int16 | 2 | 单位 0.1°C |
| 湿度 | uint16 | 2 | 单位 0.1% |
| 状态标志 | uint8 | 1 | 位标志 |
| 总长度 | | 9 | |这种设计，解析的时候直接按偏移量读就行，性能极高。我在做嵌入式项目时，基本都是用这种方式。
4.3 校验和算法：数据有没有被篡改？
数据在传输过程中，可能会被干扰、篡改。校验和就是用来检测这个的。
常见的校验和算法有几种：
| 算法 | 长度 | 强度 | 适用场景 |
|---|---|---|---|
| 累加和 | 1-2 字节 | 低 | 简单校验，性能要求高 |
| CRC8/CRC16 | 1-2 字节 | 中 | 工业控制、通信协议 |
| CRC32 | 4 字节 | 高 | 文件传输、数据完整性 |
| MD5/SHA | 16-32 字节 | 极高 | 安全场景，但开销大 |
我个人最常用的是 CRC16。它比累加和可靠得多，又不像 MD5 那么重。在嵌入式设备上，硬件 CRC 模块基本是标配，算起来飞快。
一个简单的 CRC16 实现：
def crc16(data: bytes) -> int:
crc = 0xFFFF
for byte in data:
crc ^= byte
for _ in range(8):
if crc & 0x0001:
crc = (crc >> 1) ^ 0xA001
else:
crc >>= 1
return crc4.4 协议版本控制：别让新旧设备打架
协议不是一成不变的。随着产品迭代，协议字段会增删改。这时候就需要版本控制。
我的做法很简单：在协议头里放一个版本号字段。解析器先读版本号，再根据版本号选择对应的解析逻辑。
版本控制有几个原则：
- 向前兼容：新版本解析器能解析旧版本数据。比如新增字段时，旧版本数据里没有这个字段，解析器要能处理。
- 向后兼容：旧版本解析器遇到新版本数据，至少能识别出版本号，然后优雅地拒绝或降级处理。
- 版本号递增：不要跳版本。1.0 → 1.1 → 2.0，每个版本都要有明确的变更记录。
举个例子，版本 1.0 的协议体只有温度和湿度，版本 1.1 新增了气压字段：
# 版本 1.0 解析
if version == 0x01:
temp = read_int16()
hum = read_uint16()
# 版本 1.1 解析
elif version == 0x02:
temp = read_int16()
hum = read_uint16()
pressure = read_uint32() # 新增字段4.5 完整协议设计示例
说了这么多，咱们来画一张完整的协议结构图，把上面这些概念串起来。
这张图把整个流程串起来了：先发协议头，再发协议体，整个包做校验，版本号控制解析逻辑。每一步都环环相扣。
4.6 设计时的几个坑
最后，分享几个我踩过的坑：
- 协议头长度别太短：2 字节的起始标识 + 1 字节版本号，看起来够用。但如果你要支持几十种消息类型，1 字节就不够了。预留空间很重要。
- 校验和算法别选太弱：累加和虽然快，但两个字节互换位置时检测不出来。CRC16 是性价比最高的选择。
- 版本号从 1 开始：别用 0 做初始版本。0 在调试时容易跟未初始化数据混淆。
- 保留字段别浪费：协议头里的保留字段，可以用来做未来扩展。我见过有人把保留字段全填 0，后来想加功能发现没地方了。