4. OTA通信协议：HTTPS、MQTT、HTTP/2在OTA中的应用与对比
聊到OTA，通信协议是个绕不开的话题。很多刚入行的朋友问我：「老师，OTA不就是下载个包吗？用HTTP不就行了？」嗯，如果真这么简单，我就不用专门花一节课来讲了。
我做过好几个量产车型的OTA项目，踩过的坑比你们想象的多。今天咱们就掰开揉碎，聊聊HTTPS、MQTT、HTTP/2这三个协议在OTA场景下到底该怎么选。
4.1 HTTPS：最稳妥的「老大哥」
先说说HTTPS。说白了，它就是HTTP加了一层TLS/SSL加密。我最早做OTA时，用的就是HTTPS。为什么？因为它成熟、稳定，几乎所有服务器和车机都支持。
HTTPS在OTA里主要干两件事：
- 下载升级包：车机向服务器发起GET请求，拉取固件包
- 上报状态：用POST请求把升级结果发回云端
但这里有个坑。我记得有一次，某款车型在弱网环境下下载一个200MB的包，HTTPS连接频繁超时。为什么？因为HTTPS的握手开销太大了。每次重连都要重新做TLS握手，在信号差的地方简直就是灾难。
HTTPS适合的场景：
- 升级包较大（>50MB）
- 网络环境相对稳定
- 对安全性要求极高
4.2 MQTT：轻量级的「消息快递员」
MQTT这个协议，我一开始是拒绝的。总觉得它太「轻」了，能扛得住OTA这种严肃场景吗？后来真香了。
MQTT是发布/订阅模式，说白了就是有个「消息中间人」（Broker）。车机订阅某个Topic，服务器往Topic里发消息，车机就能收到。这个机制特别适合做OTA的指令下发和状态上报。
我举个例子：
// 车机订阅升级指令
Topic: /ota/vehicle/{vin}/command
Payload: {"action": "download", "url": "https://...", "version": "2.1.0"}
// 车机上报进度
Topic: /ota/vehicle/{vin}/status
Payload: {"progress": 65, "status": "downloading"}MQTT最大的优势是什么？低带宽、低功耗。一个控制报文最小只有2个字节。你想想看，在车机用4G网络的环境下，这能省多少流量费？
但MQTT也有短板。它不适合传大文件。虽然可以分片传输，但效率远不如HTTPS。所以我的习惯是：MQTT管控制，HTTPS管数据。
4.3 HTTP/2：新时代的「多面手」
HTTP/2是HTTP/1.1的升级版。它最大的改进是支持多路复用——一个连接可以同时处理多个请求。这对OTA来说太重要了。
我记得有个项目，车机需要同时下载固件包、上报日志、拉取配置。如果用HTTP/1.1，得开三个连接。用HTTP/2，一个连接全搞定。
HTTP/2在OTA中的典型用法：
- 服务器推送：服务器可以主动把升级包推给车机，不用等车机来问
- 头部压缩：HPACK算法能把请求头从几百字节压缩到几十字节
- 二进制分帧：数据以帧为单位传输，更高效
但HTTP/2也有个问题：它依赖TLS。而且有些老款车机的网络协议栈不支持HTTP/2。所以我在做方案时，一般会留一个降级到HTTP/1.1的备选方案。
4.4 三个协议怎么选？一张表说清楚
| 特性 | HTTPS | MQTT | HTTP/2 |
|---|---|---|---|
| 传输模式 | 请求-响应 | 发布-订阅 | 请求-响应 + 服务器推送 |
| 连接开销 | 高（TLS握手） | 低（长连接） | 中（多路复用） |
| 大文件传输 | ✅ 适合 | ❌ 不适合 | ✅ 适合 |
| 实时性 | 低 | 高 | 中 |
| 安全性 | 高（TLS） | 中（可加TLS） | 高（TLS） |
| 车机资源占用 | 高 | 低 | 中 |
| 典型OTA用途 | 固件下载 | 指令下发、状态上报 | 混合场景 |
4.5 我的推荐方案
做了这么多年OTA架构，我个人习惯用MQTT + HTTPS的组合方案。为什么？
- MQTT负责控制面：下发升级指令、查询状态、推送通知。这些消息小、频率高，MQTT的轻量特性完美匹配。
- HTTPS负责数据面：下载固件包、上传日志。这些数据大、需要断点续传，HTTPS的成熟生态更靠谱。
- HTTP/2作为备选：如果车机支持且网络条件好，可以用HTTP/2替代HTTPS，提升并发效率。
核心思路：别指望一个协议搞定所有事。OTA通信的本质是「控制」和「数据」两条线，分开处理才是正道。
最后说一句，协议选型没有银弹。我见过用纯MQTT做OTA的，也见过全用HTTP/2的。关键看你的车机硬件、网络环境和业务需求。嗯，这个咱们后面讲架构设计时还会细聊。