📚 课程目录第4章升级包传输协议

4、升级包传输协议：HTTP/HTTPS、MQTT、CoAP、私有协议

升级包怎么从云端安全地送到设备手里？说白了，这就是传输协议要干的事。我见过不少团队，协议选错了，后面调试起来简直要命。今天咱们就把主流的几种方案掰开揉碎聊一聊。

4.1 协议选型：没有银弹，只有权衡

选协议之前，先想清楚三个问题：设备资源够不够？网络环境稳不稳？安全要求多高？我个人的习惯是，先列个对比表，再根据实际情况拍板。

协议	传输层	开销	适用场景	典型设备
HTTP/HTTPS	TCP	高（头部大）	宽带稳定、大包传输	网关、工控机
MQTT	TCP	中（固定头部2字节）	低带宽、频繁通信	传感器、智能家居
CoAP	UDP	低（4字节头部）	极低功耗、弱网环境	电池供电终端
私有协议	自定义	可控	特殊硬件、极致优化	定制化嵌入式设备

我的经验： 别一上来就选私有协议。除非你团队有足够的人力维护，否则优先用标准协议。标准协议的工具链成熟，出了问题社区能帮你。

4.2 HTTP/HTTPS：最通用的方案

HTTP 做 OTA 升级，其实就是把升级包当文件下载。设备发起 GET 请求，服务器返回二进制流。HTTPS 就是在外面套一层 TLS，保证传输过程不被篡改。

我在项目中遇到过一个问题：设备下载到一半，网络断了。重新下载时，HTTP 不支持断点续传，只能从头再来。后来我加了 Range 头部，才解决了这个问题。

// 请求前100KB
GET /firmware/v2.1.bin HTTP/1.1
Host: ota.example.com
Range: bytes=0-102399

// 服务器响应
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-102399/1048576
Content-Length: 102400

注意： 嵌入式设备的 HTTPS 栈通常只支持有限套件。我曾经因为服务器配置了 ECDHE 套件，而设备只支持 RSA，导致握手失败。建议提前锁定 TLS 版本和加密套件。

4.3 MQTT：适合双向通信的场景

MQTT 是发布/订阅模式。云端发布升级通知，设备订阅相关主题。收到通知后，设备再决定是否下载。这种方式特别适合批量升级——一条消息，所有设备都能收到。

MQTT 的 QoS 等级很关键：

QoS 0：最多发一次，丢了不重传。适合心跳、状态上报。
QoS 1：至少发一次，可能重复。适合升级通知。
QoS 2：恰好发一次，开销最大。适合关键指令。

我个人建议，升级包本身不要走 MQTT 传。MQTT 的 payload 有限制，而且大包传输效率低。正确的做法是：MQTT 只传元信息，比如版本号、下载地址、校验值。设备收到后，再用 HTTP 或 CoAP 去拉包。

// 云端发布升级通知
Topic: ota/device/12345/command
Payload: {
  "version": "2.1.0",
  "url": "https://ota.example.com/firmware/v2.1.bin",
  "md5": "a1b2c3d4e5f6..."
}

4.4 CoAP：为受限设备而生

CoAP 基于 UDP，头部只有 4 个字节。它支持观察模式，设备可以订阅资源变化。一旦有新版固件，服务器主动推送通知。

CoAP 的可靠性靠确认和重传机制保证。每个消息都有 Message ID，超时未确认就重发。我调试过一个项目，设备在弱网环境下，CoAP 的重传间隔设置得太短，导致网络拥塞。后来我把初始超时设为 2 秒，最大重传次数设为 4 次，问题就解决了。

// 设备请求固件信息
GET coap://ota.example.com/firmware/version
// 服务器响应
2.05 Content
{
  "version": "2.1.0",
  "size": 1048576,
  "block": 0
}

// 分块下载（Block-wise Transfer）
GET coap://ota.example.com/firmware/data
Accept: application/octet-stream
Block2: 0/128/1024  // 请求第0块，每块128字节，总大小1024块

  关键点： CoAP 的块传输（Block-wise Transfer）是 OTA 升级的核心。它允许设备分片下载，每片独立确认。即使中间丢了几片，也只重传丢失的部分，不会浪费带宽。

4.5 私有协议：最后的杀手锏

什么时候需要私有协议？我总结了几种情况：

硬件资源极有限，连 CoAP 栈都跑不动。
需要极低延迟，比如毫秒级同步。
有特殊的安全要求，比如自定义加密握手。

私有协议的设计原则：

固定头部：至少包含魔数、版本、长度、校验。解析时先校验魔数，避免误解析。
分片机制：支持任意大小的分片，每片独立校验。
重传策略：指数退避 + 最大重试次数，避免网络风暴。

// 私有协议帧格式示例
| 魔数(2B) | 版本(1B) | 类型(1B) | 长度(2B) | 序列号(2B) | 数据(N) | CRC32(4B) |
| 0xAA55   | 0x01     | 0x10     | 0x0400   | 0x0001     | ...     | 0x12345678|

避坑指南： 我曾经设计过一个私有协议，把校验放在头部后面。结果设备收到畸形包时，先解析了错误的数据，直接崩溃。后来我把魔数和长度放在最前面，先校验再解析，才稳定下来。

4.6 协议对比与选型建议

选协议不是非黑即白。我见过一个项目，网关用 HTTPS 下载大包，终端用 CoAP 接收增量补丁。混合使用反而效果最好。

最后说一句，协议只是载体。真正决定升级成败的，是传输过程中的异常处理。超时怎么办？重传几次？校验失败怎么恢复？这些细节，才是调试时最头疼的地方。下一节，咱们就聊聊这些实战中的坑。