第三章 OTA架构设计基础：云端分发层、设备端接收层、差分升级与全量升级的选择

各位好，我是老周。做了这么多年物联网安全，OTA这块我踩过的坑真不少。今天咱们聊聊OTA架构的基础设计。说白了，就是搞清楚升级包从哪来、到哪去、怎么传。

很多团队一上来就急着写代码，结果云端和设备端各搞各的，最后联调时发现根本对不上。我建议先画清楚架构图，再动手。

3.1 云端分发层：不只是上传个文件那么简单

云端分发层，我习惯叫它「OTA的大脑」。它管三件事：包管理、策略下发、通道维护。

我记得有个项目，客户要求所有设备必须在一小时内完成升级。结果云端没做限流，十万台设备同时拉包，CDN直接被打爆。后来我加了「分批下发+随机延迟」的策略，问题才解决。

3.2 设备端接收层：资源受限下的生存之道

设备端才是真正的战场。云端可以堆服务器，设备端呢？可能只有几百KB的RAM、几MB的Flash。

设备端接收层要搞定三件事：

1. 下载管理：支持断点续传。网络一断就重头下载？用户会骂娘的。
2. 存储管理：A/B分区是最稳妥的方案。一个区跑着，另一个区写新固件，写完了切换。
3. 升级执行：校验签名、校验完整性、然后才敢刷进去。

我曾经在一个智能门锁项目上吃过亏。设备只有512KB Flash，做不了A/B分区。最后用了「压缩+差分」的方案，升级包从1MB压到200KB，才勉强塞进去。

3.3 差分升级 vs 全量升级：怎么选？

这是大家问得最多的问题。我直接给结论：

对比维度	全量升级	差分升级
包大小	完整固件，通常几MB到几十MB	仅差异部分，通常几十KB到几百KB
传输时间	长，耗流量	短，省流量
设备要求	低，只需解压和写入	高，需要CPU算力做差分合并
可靠性	高，包损坏容易发现	中等，依赖旧固件版本精确匹配
适用场景	首次烧录、大版本升级、设备资源极受限	小版本迭代、NB-IoT/2G等低带宽网络

说白了，全量升级就是「不管你现在是什么，我给你一套全新的」。差分升级就是「我只给你变动的部分，你自己拼起来」。

3.4 差分升级的实现细节

差分升级的核心算法，我常用bsdiff和hdiffpatch。bsdiff适合二进制差异，hdiffpatch对嵌入式更友好。

一个典型的差分升级流程：

1. 云端用旧固件和新固件生成差分补丁（.patch文件）
2. 设备下载补丁，同时保留旧固件在Flash中
3. 设备用差分算法将旧固件+补丁合并成新固件
4. 校验新固件的签名和哈希
5. 写入新分区，切换启动

// 伪代码：设备端差分合并流程
bool apply_delta_update(const uint8_t* old_fw, uint32_t old_size,
                        const uint8_t* patch, uint32_t patch_size,
                        uint8_t* new_fw, uint32_t* new_size) {
    // 1. 校验补丁签名
    if (!verify_signature(patch, patch_size)) return false;

    // 2. 执行差分合并
    if (!hdiffpatch_merge(old_fw, old_size, patch, patch_size, new_fw, new_size)) {
        return false;
    }

    // 3. 校验新固件完整性
    if (!verify_firmware_hash(new_fw, *new_size)) return false;

    return true;
}

3.5 安全合规视角下的OTA架构

从合规角度看，OTA架构必须满足几个硬性要求：

• 升级包签名：必须用硬件安全模块（HSM）或安全元件（SE）存储私钥
• 传输加密：TLS 1.2以上，不能用明文HTTP
• 版本回滚防护：防止攻击者把设备降级到有漏洞的旧版本
• 升级失败处理：必须能回滚到上一个可用版本

我记得有个客户做智能摄像头，OTA没做版本回滚防护。黑客拿到旧固件的漏洞，把设备降级后远程控制了摄像头。后来我们加了「版本号防降级」机制，才通过合规审计。