4、更新包管理：签名验证机制、增量更新 vs 全量更新、压缩与加密、版本号管理规范
更新包管理这事儿，说白了就是「怎么把补丁安全、高效地塞到设备里」。我见过太多团队只关注业务功能，结果更新包被篡改、传输中断、版本混乱，最后设备变砖。嗯，这一章咱们就把这几个关键点掰开揉碎。
4.1 签名验证机制：别让恶意包混进来
签名验证是更新包的第一道防线。没有它，攻击者随便伪造一个包就能控制你的设备。我个人习惯用 RSA-SHA256 或 ECDSA，前者兼容性好，后者性能更优。
核心流程：
- 服务端用私钥对更新包哈希值签名
- 设备端用公钥验证签名
- 验证通过才允许安装
我曾经遇到一个项目，设备端公钥硬编码在固件里，结果固件被逆向，公钥泄露。从那以后，我要求公钥必须存储在安全区域（如 TEE 或 SE），并且支持密钥轮换。
避坑指南：签名算法别用 MD5 或 SHA-1，已经被攻破了。至少用 SHA-256，密钥长度 2048 位起步。
4.2 增量更新 vs 全量更新：选对策略省带宽
全量更新简单粗暴，但带宽消耗大。增量更新只传输差异部分，省流量，但复杂度高。我一般这样选：
| 对比维度 | 全量更新 | 增量更新 |
|---|---|---|
| 带宽消耗 | 高（整个包） | 低（仅差异） |
| 实现复杂度 | 低 | 高（需 diff 算法） |
| 失败恢复 | 容易（重传即可） | 困难（依赖基线版本） |
| 适用场景 | 首次部署、大版本升级 | 小补丁、频繁更新 |
你想想看，如果设备数量上万，每次全量更新几百 MB，CDN 费用都够你喝一壶的。我建议：大版本用全量，小补丁用增量。但增量更新必须保证基线版本一致，否则差异文件会乱套。
注意：增量更新失败时，设备必须能回退到上一个稳定版本。我曾经见过一个设备，增量更新到一半断电，结果系统文件损坏，只能返厂刷机。
4.3 压缩与加密：既要小又要安全
更新包压缩能减少传输时间，加密能防止内容泄露。我常用的组合是 gzip + AES-256-GCM。
- 压缩：gzip 或 zstd，后者压缩比更高，但解压速度稍慢
- 加密：AES-256-GCM，带认证加密，能检测篡改
- 密钥管理：每个设备使用独立密钥，或基于设备 ID 派生
举个例子，一个 100MB 的固件，gzip 压缩后可能只剩 30MB，再加密传输，既省带宽又防窃听。但要注意，加密必须在压缩之后进行，否则压缩效果会大打折扣。
实操命令：
# 压缩并加密
gzip -c firmware.bin | openssl enc -aes-256-gcm -pass pass:your_key -out firmware.enc.gz
# 解密并解压
openssl enc -d -aes-256-gcm -pass pass:your_key -in firmware.enc.gz | gzip -d > firmware.bin4.4 版本号管理规范：别让版本乱飞
版本号混乱是运维的噩梦。我见过一个团队，版本号用日期命名，结果同一天发布两个版本，根本分不清哪个新。我推荐 语义化版本号（SemVer）：
| 格式 | 示例 | 含义 |
|---|---|---|
| 主版本号 | 2 | 不兼容的 API 变更 |
| 次版本号 | 3 | 向下兼容的功能新增 |
| 修订号 | 1 | 向下兼容的问题修复 |
比如 2.3.1，一看就知道是主版本 2 的第 3 次功能更新后的第 1 个补丁。另外，我习惯在版本号后加构建元数据，比如 2.3.1+build20241015，方便追溯。
避坑指南：版本号一旦发布，就不能修改。如果发现 bug，发布新版本，而不是重新上传旧版本号。否则设备端会认为已经更新过，跳过安装。
4.5 知识体系总览
下面这张图把更新包管理的核心逻辑串起来了，你可以对照着看：
这四个环节环环相扣。签名验证保证来源可信，增量更新节省带宽，压缩加密保护内容，版本号管理避免混乱。少了任何一个，更新策略都可能出问题。
总结一下我的经验：
- 签名用 ECDSA，性能好，密钥短
- 增量更新用 bsdiff，全量更新用 gzip
- 加密用 AES-256-GCM，别用 ECB 模式
- 版本号严格遵循 SemVer，加构建时间戳