3. 升级包制作与管理：差分升级包、全量升级包、升级包签名与校验
好，咱们进入第三个核心话题——升级包的制作与管理。
说实话，很多刚入行的朋友觉得升级包不就是把固件打个包吗？其实远没那么简单。你想想看，一个设备可能有几十万台，升级包一旦出问题，那就是灾难性的。我见过因为升级包校验没做好，导致整批设备变砖的案例，那场面……嗯，咱们还是先打好基础。
3.1 全量升级包 vs 差分升级包
先搞清楚这两个概念。
全量升级包，说白了就是把整个新固件完整地打包。不管设备当前跑的是哪个版本，拿到这个包直接刷就行。优点是简单、可靠，缺点是包体大。一个 32MB 的固件，全量包就是 32MB，对于 NB-IoT 这种窄带网络，传输时间会让你崩溃。
差分升级包（也叫增量包），只包含新旧版本之间的差异部分。比如你只改了一个驱动文件，差分包可能只有几百 KB。我做过一个项目，固件 20MB，差分包最小做到过 300KB，传输时间从 40 分钟缩短到 2 分钟。
怎么选？我的建议是：
- 首次升级或跨大版本升级：用全量包。因为版本差异太大，差分包反而可能更大，而且容易出错。
- 日常小版本迭代：用差分包。节省流量，也节省用户等待时间。
- 关键安全设备：我建议强制用全量包。差分算法偶尔会有边界情况处理不好，安全第一。
3.2 差分算法与工具链
差分升级的核心是算法。目前主流的有几种：
| 算法 | 特点 | 适用场景 |
|---|---|---|
| bsdiff/bspatch | 基于二进制差异，压缩率高 | 通用场景，但内存消耗大 |
| HDiffPatch | 小米开源，支持大文件 | 嵌入式 Linux 场景 |
| xdelta | 基于 VCDIFF 标准 | 文件级别差分，简单稳定 |
| 自定义差分 | 针对特定文件系统优化 | 资源极度受限的 MCU |
我个人习惯用 bsdiff，虽然它吃内存，但压缩率确实好。不过要注意，bsdiff 在生成差分包时，会把新旧两个固件都加载到内存里。如果你的编译服务器内存不够，可能会卡死。我曾经在 4GB 内存的服务器上跑 64MB 固件的差分，直接 OOM 了……后来加了 swap 才搞定。
生成差分包的命令很简单：
# 生成差分包
bsdiff old_firmware.bin new_firmware.bin delta.patch
# 应用差分包
bspatch old_firmware.bin updated_firmware.bin delta.patch嗯，这里有个坑要注意：差分包的生成和应用的固件必须完全一致。哪怕旧固件只差一个字节，应用差分包后得到的固件也是错的。所以，我建议在生成差分包之前，先对旧固件做一次哈希校验。
3.3 升级包签名——防篡改的第一道防线
升级包在传输过程中可能被篡改。你想想看，如果攻击者替换了你的升级包，设备刷了恶意固件，后果不堪设想。
签名就是解决这个问题的。流程是这样的：
- 在服务器端，用私钥对升级包进行签名，生成签名文件。
- 设备端用公钥验证签名，确认升级包是官方发布的，且未被篡改。
常用的签名算法有 RSA 和 ECDSA。我个人更推荐 ECDSA，因为同样的安全强度下，它的签名更短，计算也更快。对于资源受限的 MCU，这点优势很明显。
签名操作示例（使用 OpenSSL）：
# 生成 ECDSA 密钥对
openssl ecparam -genkey -name prime256v1 -out private.pem
openssl ec -in private.pem -pubout -out public.pem
# 对升级包签名
openssl dgst -sha256 -sign private.pem -out firmware.bin.sig firmware.bin
# 验证签名
openssl dgst -sha256 -verify public.pem -signature firmware.bin.sig firmware.bin3.4 升级包校验——确保数据完整性
签名验证通过后，是不是就万事大吉了？不是。签名验证的是「谁签的」，而校验验证的是「数据对不对」。传输过程中可能发生比特翻转、丢包等问题，导致固件损坏。
常用的校验方式：
- CRC32：速度快，但安全性低，只能检测随机错误。
- MD5：已经不推荐使用，有碰撞风险。
- SHA256：目前推荐，安全性足够，计算速度也可以接受。
我建议的做法是：签名 + SHA256 双重校验。签名保证来源可信，SHA256 保证数据完整。具体流程：
- 设备下载升级包后，先计算 SHA256 哈希值。
- 与升级包元数据中的哈希值对比，如果不一致，说明数据损坏，直接丢弃。
- 哈希校验通过后，再用公钥验证签名。
这样做的好处是：如果哈希校验失败，就不需要做耗时的签名验证了，节省资源。
3.5 升级包的元数据设计
升级包不能只有固件数据，还得有「说明书」。这个说明书就是元数据。我一般会在升级包头部或单独的文件中包含以下信息：
| 字段 | 说明 | 示例 |
|---|---|---|
| 固件版本 | 新固件的版本号 | v2.1.0 |
| 兼容版本 | 该升级包适用的旧版本范围 | v2.0.0 - v2.0.9 |
| 包类型 | 全量包还是差分包 | delta |
| 固件大小 | 解压后的固件大小 | 16777216 |
| 固件哈希 | 固件的 SHA256 值 | a1b2c3d4... |
| 签名 | 对元数据+固件的签名 | （二进制数据） |
| 发布时间 | 升级包生成时间 | 2024-03-15 10:30:00 |
元数据的设计要尽量精简，但关键信息不能少。我见过一个项目，元数据里没写兼容版本，结果设备从 v1.0 直接升级到 v3.0，中间跳过了 v2.0 的数据库迁移脚本，上线就崩了……
3.6 升级包的管理策略
最后聊聊管理。升级包不是生成完就完事了，你得考虑版本管理、灰度发布、回滚等问题。
我的建议：
- 版本号规范：采用语义化版本（SemVer），比如 v2.1.0。主版本号、次版本号、修订号，每个都有明确含义。
- 存储策略：保留最近 N 个版本的升级包，方便用户跨版本升级。我一般保留 5 个版本。
- 灰度发布：先让 1% 的设备升级，观察 24 小时没问题再全量推送。这个机制需要在服务器端实现，但设备端也要做好配合，比如上报升级结果。
- 回滚包：每次发布新版本时，同时生成对应的回滚包。万一新版本有问题，可以快速回退。
核心要点回顾：
- 全量包简单可靠，差分包省流量，按场景选择
- 差分算法推荐 bsdiff，注意内存消耗
- 签名防篡改，校验防损坏，两者缺一不可
- 元数据要包含版本兼容信息，避免升级错乱
- 做好版本管理和灰度发布，降低风险
好了，这一章的内容就到这里。升级包制作是 OTA 的基础，基础打牢了，后面的回滚和故障恢复才能玩得转。下一章咱们聊聊升级包的存储分区设计，那可是个容易踩坑的地方。