3、升级包制作与管理：升级包格式设计、差分升级算法、升级包签名与加密、版本管理策略
各位同学，咱们今天聊聊升级包的制作与管理。说实话，这部分是OTA协议栈里最「接地气」的活儿。你协议栈写得再漂亮，升级包做不好，车机刷成砖，那可就尴尬了。
我个人习惯把升级包看作一个「黑盒子」——它必须自包含、自校验、自描述。什么意思？就是拿到这个包，不用查任何外部资料，就能知道它要升级谁、怎么升、安不安全。
3.1 升级包格式设计
先说说格式。我见过不少团队，上来就搞自定义二进制格式，结果后面维护成本高得吓人。我的建议是：用标准容器 + 自定义载荷。
目前主流做法是用 ZIP 或 TAR 作为外层容器，里面放元数据文件和实际固件。为什么？因为标准库支持好，压缩、校验、分卷都现成的。
下面是我在项目里常用的一种结构：
升级包结构示例：
update_package_v1.2.3.zip
├── manifest.json # 元数据清单
├── signature.bin # 数字签名
├── firmware/
│ ├── mcu_app.bin # MCU固件
│ ├── mcu_bootloader.bin # 引导程序
│ └── soc_system.img # SoC系统镜像
└── delta/
└── mcu_app.delta # 差分补丁（可选）
manifest.json 是关键。它记录了版本号、硬件兼容性、校验哈希、升级顺序等。我习惯在里边加一个 dependencies 字段，用来处理「必须先升A才能升B」的场景。
核心原则：升级包必须能「自解释」。哪怕十年后翻出来，看 manifest 就知道怎么用。
3.2 差分升级算法
差分升级，说白了就是「只传变化的部分」。车机网络带宽有限，动不动几百兆的固件全量下发，用户流量扛不住，服务器带宽也扛不住。
我最早接触差分算法是在2016年，当时用的是 bsdiff。这算法对二进制文件效果不错，但有个坑——内存占用极高。嵌入式设备动不动只有几百KB RAM，bsdiff 跑起来直接 OOM。
后来我改用 xdelta3（基于 VCDIFF 标准）。它支持流式处理，内存可控。给大家看个实际用法：
# 生成差分补丁（在PC上执行）
xdelta3 -e -s old_firmware.bin new_firmware.bin delta_patch.bin
# 应用差分补丁（在车机上执行）
xdelta3 -d -s old_firmware.bin delta_patch.bin new_firmware.bin
这里有个经验：差分算法对固件布局敏感。如果你两次编译的固件，只是函数顺序变了，差分包可能比全量包还大。我建议在编译时固定链接顺序，或者用 --sort 选项预处理。
避坑指南：我曾经遇到一个案例，差分包在实验室测了100次都OK，上车就失败。查了两天发现是车机 Flash 的磨损均衡导致旧固件在物理地址上被搬移了。解决方案：应用差分前，先把旧固件从 Flash 读到 RAM 里重组。
3.3 升级包签名与加密
安全这块，我把它分成两层：签名保证完整性，加密保证机密性。
签名我用的是 ECDSA（椭圆曲线数字签名算法）。为什么不用 RSA？因为车机算力有限，ECDSA 的签名验证速度快一个数量级。密钥长度选 P-256 就够，别盲目上 P-521，性能开销大。
加密呢？我建议用 AES-256-GCM。GCM 模式自带认证标签，能同时防篡改。注意一点：加密密钥和签名密钥必须分开。我见过有人图省事用同一个密钥，结果签名私钥泄露后，加密形同虚设。
实际流程是这样的：
制作阶段（PC端）：
1. 计算固件哈希 SHA-256
2. 用私钥对哈希签名 → signature.bin
3. 用 AES 密钥加密固件 → encrypted_firmware.bin
4. 打包 manifest + signature + encrypted_firmware
验证阶段（车机端）：
1. 解包，读取 manifest
2. 用公钥验证 signature 是否匹配固件哈希
3. 用 AES 密钥解密固件
4. 再次计算哈希，确认解密无误
注意：公钥一定要烧死在芯片的 eFuse 里，不能放在文件系统里。否则攻击者替换公钥，你的签名验证就形同虚设了。
3.4 版本管理策略
版本管理，说白了就是「怎么给固件起名字、怎么管依赖」。我见过最乱的版本号是 v2.1.3_fix_bug_20240315_final_v2——这谁看得懂？
我推荐语义化版本（SemVer）：主版本.次版本.补丁版本。比如 v2.1.3：
- 主版本：不兼容的 API 变更，或者硬件平台变化
- 次版本：向下兼容的新功能
- 补丁版本：内部 bug 修复
但光有版本号不够，还得有兼容性矩阵。举个例子：
| 当前版本 | 可升级目标 | 升级方式 |
|---|---|---|
| v1.0.x | v1.1.x | 差分升级 |
| v1.1.x | v2.0.x | 全量升级 |
| v2.0.x | v2.1.x | 差分升级 |
为什么跨主版本要用全量？因为差分算法假设新旧固件结构相似，主版本变更往往涉及底层架构调整，差分包可能比全量还大，而且容易出错。
我的习惯：在 manifest 里加一个 min_supported_version 字段。比如 v2.0.0 的包声明 min_supported_version: "1.5.0"，低于这个版本的必须先升到 v1.5.0 才能继续。这能避免「跳版本升级」导致的兼容性问题。
嗯，升级包这块内容不少，但核心就四点：格式要规范、差分要高效、安全要分层、版本要清晰。你想想看，如果每个环节都做到位，车机升级的失败率能降到多低？我在实际项目中，经过这些优化后，升级成功率从 97.2% 提升到了 99.8%。那剩下的 0.2% 是什么？嗯，那是硬件本身的问题，跟协议栈无关了。