2. OTA升级的通信链路：云端到设备端的数据通道

OTA升级说白了，就是让设备自己从云端把新固件“拿”下来。但这条路怎么走？数据怎么传？这里面门道不少。我刚开始接触OTA时，以为就是设备发个HTTP请求下载个文件那么简单。后来踩了坑才发现，通信链路的选择直接决定了升级的成败和安全。

2.1 云端到设备端：这条数据通道长什么样？

先画个全景图。一个典型的OTA通信链路，从云端到设备端，大致经过这几个环节：

你看，这条链路不是简单的“云→设备”直连。中间可能有CDN做加速，有网关做协议转换。每个环节都可能成为攻击面。我个人习惯，在设计OTA系统时，先把这条链路上的每个节点都列出来，逐个分析安全风险。

2.2 HTTP/HTTPS vs MQTT：到底该用哪个？

这是很多初学者纠结的问题。我直接说结论：没有银弹，看场景。

对比维度	HTTP/HTTPS	MQTT
传输模型	请求-响应（客户端主动拉）	发布-订阅（服务器可主动推）
协议开销	头部较大（几百字节）	头部极小（2字节起）
实时性	轮询或长轮询，延迟较高	推送机制，毫秒级延迟
安全性基础	HTTPS = HTTP + TLS，成熟	MQTT over TLS，需额外配置
适用场景	大文件下载（固件包）	小数据、控制指令、状态上报
设备资源消耗	较高（解析HTTP、TLS握手）	较低（适合MCU类设备）

为什么会这样？你想想看，一个固件包动辄几MB甚至上百MB，用MQTT的PUBLISH报文去传？那得拆成几千个小包，效率极低。HTTPS有断点续传、分块下载、CDN加速，天生适合大文件传输。

但MQTT也有它的用武之地。我记得有个项目，设备数量上万，需要批量推送升级通知。如果用HTTP轮询，服务器压力巨大。换成MQTT后，云端一条消息推下去，所有设备同时收到通知，然后各自去下载固件。这个模式，我称之为“MQTT通知 + HTTPS下载”，是目前工业界的主流做法。

2.3 固件包的分发机制：怎么把包安全送到设备手里？

分发机制，说白了就是“怎么发、发什么、发给谁”。这里面有三个核心问题：

1. 增量升级 vs 全量升级——发整个包还是只发差异部分？
2. 分发策略——一次性全发，还是分批灰度？
3. 安全防护——怎么保证包在传输过程中不被篡改？

2.3.1 增量升级：省流量，但麻烦

增量升级只传输新旧固件之间的差异部分。比如固件从v1.0升级到v1.1，可能只改了20KB的代码，那就只发这20KB的差分包。设备端用差分算法（如bsdiff、hdiffpatch）把旧固件和差分包合并成新固件。

2.3.2 分发策略：别一窝蜂

我见过最惨的案例——某公司OTA上线，所有设备同时下载固件，CDN带宽被打满，下载速度降到几KB/s，升级超时率超过60%。

正确的做法是灰度发布 + 分批下发：

• 第一阶段（1%设备）：内部测试设备，验证升级流程
• 第二阶段（10%设备）：小范围灰度，观察稳定性
• 第三阶段（50%设备）：扩大范围，监控异常
• 第四阶段（100%设备）：全量发布

每个阶段之间留出观察窗口，至少24小时。这样即使有问题，也能及时止损。

2.3.3 安全分发：签名 + 加密 + 校验

这是重中之重。固件包在传输过程中，可能被中间人篡改、被恶意替换。怎么防？

我推荐的安全分发流程：

1. 云端签名：用私钥对固件包的哈希值签名，生成签名文件
2. 传输：固件包 + 签名文件 + 公钥证书，通过HTTPS下发
3. 设备端校验：用预置的公钥验证签名，确认固件未被篡改
4. 解密：如果固件包加密了，设备端用密钥解密
5. 完整性校验：计算固件哈希，与云端下发的哈希值比对

// 伪代码：设备端固件校验流程
bool verify_firmware(uint8_t* firmware, size_t size, 
                     uint8_t* signature, uint8_t* cert) {
    // 1. 计算固件哈希
    uint8_t hash[32];
    sha256(firmware, size, hash);
    
    // 2. 用公钥验证签名
    if (!rsa_verify(hash, signature, cert)) {
        return false;  // 签名验证失败，拒绝升级
    }
    
    // 3. 解密固件（如果加密）
    decrypt_firmware(firmware, size, key);
    
    // 4. 再次校验解密后的哈希
    sha256(firmware, size, hash);
    if (hash != expected_hash) {
        return false;  // 完整性校验失败
    }
    
    return true;
}

嗯，这里要注意：公钥要硬编码在设备固件中，不能从网络获取。否则攻击者可以替换公钥，用他自己的私钥签名恶意固件。

2.4 小结：通信链路的安全要点

这一章的内容，我帮你梳理成一张检查清单：

• 协议选择：大文件用HTTPS，控制指令用MQTT，两者配合
• 传输加密：全程TLS 1.2+，禁用不安全的加密套件
• 固件签名：用私钥签名，设备端预置公钥验证
• 完整性校验：传输前后都要计算哈希值
• 分发策略：灰度发布，分批下发，留观察窗口
• 增量升级：合并后必须做完整性校验