4、升级包管理：差分升级算法（bsdiff/hdiff）、升级包加密与签名、升级包版本管理策略
各位同学，咱们接着聊。上一章讲了升级流程，这一章咱们深入聊聊升级包本身。说白了，升级包就是OTA的灵魂。包做不好，流程再顺也没用。
我个人习惯把升级包管理拆成三个核心问题：怎么做小？怎么保安全？怎么管版本？ 咱们一个一个来。
4.1 差分升级算法：为什么非用不可？
你想想看，一个现代ECU，固件动不动就几十兆甚至上百兆。每次升级都全量下载？那流量费谁出？用户等得起吗？
所以，差分升级就派上用场了。它的核心思想很简单：只传变化的部分。
我在项目中遇到过最极端的情况——一个T-Box的固件从v1.0升到v1.1，全量包是32MB，差分包只有1.2MB。用户下载时间从5分钟缩短到15秒。嗯，用户体验的提升是立竿见影的。
4.1.1 bsdiff vs hdiff：怎么选？
目前业界主流的差分算法就两个：bsdiff和hdiff。我两个都用过，说说我的感受。
| 对比项 | bsdiff | hdiff |
|---|---|---|
| 算法原理 | 基于后缀排序，匹配长公共子串 | 基于哈希匹配，速度更快 |
| 差分率 | 通常更优（小5%-15%） | 稍差，但差距不大 |
| 生成速度 | 慢（尤其大文件） | 快（约快3-5倍） |
| 还原速度 | 快 | 快 |
| 内存占用 | 高（生成时） | 低 |
| 适用场景 | 云端生成，ECU端还原 | 资源受限的ECU |
我个人习惯：云端生成差分包用bsdiff，ECU端资源紧张时用hdiff。为什么？因为bsdiff生成时虽然慢，但差分率更好，能省流量。而hdiff在ECU端还原时内存占用低，适合那些只有几百KB RAM的小控制器。
核心结论： 差分算法不是银弹。如果新旧版本差异超过50%，差分包可能比全量包还大。这时候，老老实实走全量升级吧。
4.1.2 差分还原的坑
我曾经踩过一个坑——差分还原时，ECU的Flash写入速度跟不上算法计算速度。结果呢？缓冲区溢出，直接死机。后来我加了个流式处理机制：边计算边写入，分块处理。
伪代码大概是这样：
// 差分还原 - 流式处理示例
void apply_delta(uint8_t *old_firmware, uint32_t old_size,
uint8_t *delta_data, uint32_t delta_size,
uint8_t *new_firmware, uint32_t new_size) {
// 分块处理，每块4KB
#define CHUNK_SIZE 4096
uint32_t offset = 0;
while (offset < new_size) {
uint32_t chunk = MIN(CHUNK_SIZE, new_size - offset);
// 计算当前块的差分数据
delta_decode_chunk(old_firmware, delta_data,
new_firmware + offset, chunk);
// 立即写入Flash
flash_write(FLASH_START_ADDR + offset,
new_firmware + offset, chunk);
offset += chunk;
}
}小技巧： 差分还原时，建议在ECU端保留一份旧固件的CRC校验值。还原完成后，先校验再跳转。我见过太多因为Flash坏块导致还原失败的情况了。
4.2 升级包加密与签名：安全是底线
说实话，没有加密和签名的OTA，就是裸奔。你想想看，如果攻击者伪造一个升级包，把ECU刷成砖，或者植入后门，后果是什么？
我参与的一个项目，客户要求升级包必须满足：机密性、完整性、真实性、不可否认性。嗯，这四个要求，一个都不能少。
4.2.1 加密：防偷窥
加密是为了防止升级包在传输过程中被窃取。常用的对称加密算法有AES-128/256。我个人推荐AES-256-GCM模式，因为它同时提供了加密和完整性校验。
为什么不用RSA加密整个包？因为RSA太慢了。实际做法是：用AES加密包内容，用RSA加密AES密钥。这叫混合加密。
// 升级包加密流程（云端）
1. 生成随机AES密钥 (256位)
2. 用AES密钥加密固件数据 → 得到密文
3. 用ECU公钥加密AES密钥 → 得到密钥密文
4. 打包：密钥密文 + 固件密文 + 元数据
// 升级包解密流程（ECU端）
1. 用ECU私钥解密密钥密文 → 得到AES密钥
2. 用AES密钥解密固件密文 → 得到明文固件
3. 校验固件完整性警告： ECU的私钥必须安全存储！我见过有厂商把私钥硬编码在代码里，结果被反编译出来，整个产品线的安全体系瞬间崩塌。建议使用HSM（硬件安全模块）或eFuse存储密钥。
4.2.2 签名：防篡改
加密只能防偷看，不能防篡改。签名才是保证升级包完整性和真实性的关键。
签名流程：
- 计算固件数据的哈希值（SHA-256）
- 用厂商私钥对哈希值签名（RSA-2048或ECDSA）
- 将签名附加到升级包中
验签流程：
- ECU用厂商公钥解密签名 → 得到哈希值
- ECU自己计算固件数据的哈希值
- 两个哈希值对比，一致则通过
我曾经遇到一个案例：某Tier1厂商只做了签名，没做加密。结果呢？虽然攻击者改不了包，但可以抓包分析固件内容，逆向出很多敏感信息。所以，加密和签名是两回事，缺一不可。
4.3 升级包版本管理策略
版本管理看似简单，但做不好会出大乱子。我见过最离谱的情况：同一个ECU，A车装了v1.2，B车装了v1.3，但v1.3的差分包是基于v1.2生成的。结果B车升级时直接崩溃。
为什么会这样？因为差分包有依赖关系。你只能从v1.2升到v1.3，不能从v1.1直接升到v1.3。
4.3.1 版本号规范
我建议采用语义化版本号：主版本号.次版本号.修订号
| 版本号 | 含义 | 示例 |
|---|---|---|
| 主版本号 | 不兼容的API/协议变更 | v2.0.0 → v3.0.0 |
| 次版本号 | 向下兼容的功能新增 | v2.1.0 → v2.2.0 |
| 修订号 | 向下兼容的问题修复 | v2.1.0 → v2.1.1 |
关键点： 差分包必须明确记录源版本号和目标版本号。ECU在升级前，必须校验当前版本是否匹配源版本。不匹配？直接拒绝升级。
4.3.2 升级路径规划
实际项目中，ECU的版本分布往往很分散。有的车还在v1.0，有的已经升到了v1.5。怎么办？
我建议的做法是：
- 全量包兜底：每个版本都生成一个全量包，用于跨版本升级
- 差分包优化：只生成相邻版本的差分包（v1.0→v1.1，v1.1→v1.2）
- 升级路径计算：云端根据ECU当前版本，自动计算最优升级路径
举个例子：ECU当前是v1.0，目标版本是v1.3。云端会计算：
- 路径A：全量包 v1.0→v1.3（包大，但一步到位）
- 路径B：差分包 v1.0→v1.1 + v1.1→v1.2 + v1.2→v1.3（包小，但步骤多）
云端会根据网络状况、ECU资源等因素，自动选择最优路径。我个人习惯：优先走差分路径，但如果差分路径超过3跳，直接走全量。因为多跳差分累积的误差风险会增大。
4.3.3 版本回滚策略
升级失败了怎么办？必须能回滚。我建议采用A/B分区 + 版本标记的方案。
具体做法：
- ECU有两个固件分区：A区和B区
- 当前运行在A区（v1.2），升级目标写入B区（v1.3）
- 升级完成后，标记B区为"待验证"
- ECU重启从B区启动，运行一段时间无异常后，标记B区为"已确认"
- 如果启动失败或运行异常，自动回滚到A区
避坑指南： 我曾经遇到过一个问题——回滚时，A区的版本号比B区还新。为什么？因为A区是v1.3，B区是v1.2，但回滚逻辑写反了。所以，版本号比较逻辑一定要写对，并且要经过充分测试。
4.4 总结
好了，这一章的内容就这些。咱们回顾一下核心要点：
- 差分算法：bsdiff省流量，hdiff省资源。根据ECU能力选型。
- 加密与签名：加密防偷窥，签名防篡改。两者都要做，别偷懒。
- 版本管理：语义化版本号，明确差分依赖，规划升级路径，做好回滚策略。
下一章，咱们聊聊升级过程中的异常处理与断点续传。嗯，这部分内容很实用，尤其是那些网络不稳定的场景。到时候见。