3、升级包结构设计：全量包与增量包、包体签名与校验、元数据设计
好，咱们接着聊升级包的结构设计。这一块，说白了就是决定「升级包长什么样」。我见过不少团队，一开始觉得包结构无所谓，结果到了量产阶段，各种兼容性问题冒出来，改都来不及。所以，咱们从一开始就把这事想清楚。
3.1 全量包 vs 增量包：什么时候用哪个？
先说说全量包。全量包，就是把整个固件镜像打包成一个文件。你想想看，不管基站当前跑的是哪个版本，拿到这个包直接刷就行。好处很明显——简单、可靠、无依赖。
我在项目中遇到过，有些基站部署在偏远站点，网络条件很差。如果每次升级都要下载几十兆的全量包，那真是要命。这时候，增量包就派上用场了。
增量包只包含两个版本之间的差异部分。比如从 v1.0 升到 v1.1，可能只改了三个模块，那增量包就只打包这三个模块的二进制差异。体积能缩小 80% 以上。
核心原则：
- 首次部署或跨大版本升级：必须用全量包。因为版本差异太大，增量包可能比全量包还大，而且依赖链太长容易出错。
- 小版本迭代或紧急补丁：优先用增量包。节省带宽，升级速度快。
- 兜底策略：我建议每个增量包都附带一个「如果失败则回退到全量包」的机制。嗯，这个后面会细讲。
3.2 包体签名与校验：别让恶意固件混进来
这一节非常重要。你想想看，基站是运营商的核心设备，如果升级包被篡改，后果不堪设想。所以，签名和校验是必须的。
我个人习惯的做法是：
- 签名阶段（在编译服务器上完成）：用私钥对固件包的哈希值进行签名。私钥一定要保存在离线环境，我见过有人把私钥放在 CI 服务器上，结果被拖库了……
- 校验阶段（在基站上完成）：基站拿到升级包后，先用公钥验证签名是否合法。验证通过后，再计算包体的哈希值，跟包内记录的哈希值比对。
避坑指南：我曾经遇到过一个问题——签名算法选得太复杂，导致基站上的校验耗时超过 10 秒。对于某些实时性要求高的场景，这会影响业务。后来我换成了 ECDSA（椭圆曲线数字签名算法），校验速度提升了 5 倍。所以，选算法时一定要考虑目标硬件的算力。
这里给一个典型的签名校验流程伪代码：
// 基站侧校验流程
bool verify_package(const uint8_t* package, size_t size) {
// 1. 提取签名和元数据
Signature sig = extract_signature(package);
Metadata meta = extract_metadata(package);
// 2. 验证签名
if (!ecdsa_verify(meta.hash, sig, public_key)) {
log_error("签名验证失败，可能被篡改");
return false;
}
// 3. 验证包体完整性
uint8_t computed_hash[32];
sha256_compute(package + HEADER_SIZE, size - HEADER_SIZE, computed_hash);
if (memcmp(computed_hash, meta.hash, 32) != 0) {
log_error("哈希校验失败，包体损坏");
return false;
}
return true;
}
注意：公钥的存储位置也很关键。我建议把公钥固化在 BootROM 中，或者至少放在一个只读分区里。如果公钥可以被篡改，那签名就形同虚设了。
3.3 元数据设计：升级包的「身份证」
元数据，就是升级包的描述信息。它告诉基站：「我是谁，我从哪来，我要到哪去」。设计得好，能省很多麻烦。
我一般把元数据放在包头的固定偏移位置，这样基站不需要解压整个包就能读取。元数据包含以下字段：
| 字段名 | 类型 | 长度（字节） | 说明 |
|---|---|---|---|
| magic_number | uint32_t | 4 | 魔数，用于快速识别包类型，比如 0xFWUP |
| version_from | char[16] | 16 | 源版本号，增量包必填，全量包可填 0 |
| version_to | char[16] | 16 | 目标版本号 |
| package_type | uint8_t | 1 | 0x01 全量包，0x02 增量包 |
| hash_algorithm | uint8_t | 1 | 0x01 SHA256，0x02 SHA512 |
| payload_hash | uint8_t[32] | 32 | 负载部分的哈希值 |
| payload_size | uint32_t | 4 | 负载部分的大小（字节） |
| signature | uint8_t[64] | 64 | ECDSA 签名值 |
| reserved | uint8_t[32] | 32 | 保留字段，用于未来扩展 |
为什么要有保留字段？我吃过这个亏。早期设计时没留扩展空间，后来想加一个「强制升级标志」，结果只能改包格式，导致旧版本基站不兼容。所以，我建议至少留 32 字节的保留区，以备不时之需。
一个小技巧：元数据中的 version_from 和 version_to，我建议用语义化版本号，比如 "2.1.3"。不要用纯数字，因为纯数字没法表达「beta」或「hotfix」这类信息。你想想看，如果版本号是 201，你分不清是 2.0.1 还是 20.1。
3.4 包体布局：实际落地时的样子
好了，理论说完了，咱们看看实际落地时一个升级包长什么样。我习惯用这种布局：
+----------------------------+
| 包头（元数据） | ← 固定 170 字节
+----------------------------+
| 签名数据（64字节） | ← ECDSA 签名
+----------------------------+
| 负载数据 | ← 全量或增量数据
| (全量包：完整固件镜像) |
| (增量包：差异补丁) |
+----------------------------+
| 尾部校验和（4字节） | ← CRC32，用于快速校验
+----------------------------+
这里有个细节：为什么已经有了签名和哈希，还要加一个 CRC32？因为签名和哈希的计算开销比较大，而 CRC32 可以在接收过程中边收边算，一旦发现错误可以立即中断传输，节省时间。说白了，CRC32 是「快检」，签名是「精检」。
个人经验：我曾经在一个项目里，把 CRC32 放在包的最前面，这样接收端收到前 4 个字节就能开始校验。但后来发现这样容易被人伪造 CRC 值。所以最终方案是：CRC32 放在包尾，但接收端先收完整个包再算一次 CRC，跟包尾的 CRC 比对。这样既保证了速度，又防止了篡改。
3.5 增量包的特殊处理：差分算法怎么选？
增量包的核心是差分算法。我试过几种：
- bsdiff：压缩率高，但内存消耗大。适合在 PC 端生成，基站端解压。
- hdiffpatch：平衡型，内存和速度都适中。我目前在多数项目中使用这个。
- 自定义差分：如果固件是分段加载的，可以按段做差分。比如只改了一个驱动模块，那就只打包这个模块的差异。
嗯，这里要注意：增量包的生成和打补丁过程，必须保证原子性。我曾经遇到过，打补丁打到一半断电了，结果基站变砖。后来我加了一个「双备份」机制——打补丁前先把当前固件完整备份到另一个分区，如果补丁失败就回滚。
警告：增量包对版本依赖非常敏感。如果基站当前版本跟增量包的 version_from 不匹配，绝对不能执行升级。我建议在升级前做一次严格的版本比对，比对失败就报错并提示用户下载全量包。
好了，关于升级包结构设计，核心就是这些。记住一句话：全量包保底，增量包提效，签名校验保安全，元数据设计要留余量。下一章咱们聊聊升级流程中的状态机设计，那也是个容易踩坑的地方。