3、OTA通信协议：HTTPS/TLS协议基础、MQTT协议在OTA中的应用、UDS协议与OTA、安全通信协议选择

聊到OTA，通信协议是绕不开的坎。我见过不少团队，功能做得很漂亮，结果一上路，通信被中间人攻击截获了升级包——那场面，真是欲哭无泪。今天咱们就把OTA通信协议这块掰开揉碎，讲讲我这些年踩过的坑和总结的经验。

3.1 HTTPS/TLS协议基础

先说HTTPS。说白了，它就是HTTP加了一层TLS加密。为什么OTA要用它？因为升级包一旦被篡改，后果可能是灾难性的。我参与过一个项目，客户坚持用明文HTTP传固件，结果测试阶段就被白帽截获了——嗯，后来他们乖乖改成了HTTPS。

TLS的核心机制，我总结为三步握手：

• 证书验证：客户端确认服务器身份，防止中间人冒充
• 密钥协商：通过非对称加密交换对称密钥
• 加密通信：后续数据用对称加密传输，效率高

这里有个关键点——证书校验不能跳过。我曾经调试一个TLS连接，发现客户端总是报证书错误，查了半天，原来是系统时间没同步，证书过期了。你想想看，车机如果时间不准，TLS握手就会失败，OTA直接卡住。

TLS 1.3相比1.2，握手时间缩短了一半。对于车机这种资源受限的环境，我建议优先选用TLS 1.3。它减少了往返次数，而且废弃了那些不安全的加密套件。

3.2 MQTT协议在OTA中的应用

MQTT，很多人以为它只是物联网传感器用的。其实在OTA场景里，它是个宝贝。为什么？因为它轻量、支持发布/订阅模式，而且有三级QoS保障。

我做过一个项目，需要给上千台车同时推送升级通知。如果用HTTP轮询，服务器压力巨大。换成MQTT后，云端一条消息推下去，所有订阅了升级主题的车机都能收到——这才是真正的实时推送。

MQTT在OTA中的典型应用场景：

• 升级通知推送：云端发布升级任务，车机订阅后触发下载
• 状态上报：车机将升级进度、结果发布到指定topic
• 断点续传控制：通过MQTT消息协调下载断点位置

但要注意，MQTT本身不加密。我建议MQTT over TLS，也就是MQTT跑在TLS之上。另外，QoS等级要选对：

QoS等级	含义	OTA场景建议
0	最多一次	不推荐，可能丢消息
1	至少一次	可用于状态上报
2	恰好一次	升级指令建议用此等级

3.3 UDS协议与OTA

UDS（统一诊断服务）是汽车ECU诊断的标准协议。很多人觉得它跟OTA没关系，其实大错特错。UDS在OTA中扮演着刷写执行层的角色。

具体来说，UDS的0x34（请求下载）和0x36（传输数据）服务，就是用来刷写ECU固件的。OTA下载完升级包后，车机通过CAN或DoIP（基于IP的诊断协议）调用UDS服务，把固件刷进ECU。

我参与过一个项目，OTA下载没问题，但刷写时总失败。后来发现是UDS的安全访问（0x27服务）没处理好。ECU要求先解锁才能刷写，而解锁算法需要种子和密钥交换。嗯，这里要注意，种子不能明文传输，否则容易被重放攻击。

UDS在OTA中的典型流程：

1. 车机通过DoIP建立与ECU的通信
2. 发送0x10 03（诊断会话控制）进入编程会话
3. 发送0x27（安全访问）进行解锁
4. 发送0x34（请求下载）告知ECU即将刷写
5. 循环发送0x36（传输数据）传输固件块
6. 发送0x37（请求退出传输）结束刷写
7. 发送0x11 01（ECU复位）让新固件生效

这里有个坑——传输数据块大小。CAN总线一帧最多8字节，如果固件有几十兆，那得传多少次？所以现在主流方案是用DoIP，基于以太网传输，一帧能传上千字节，效率高得多。

3.4 安全通信协议选择

讲到这里，你可能会问：到底该选哪个协议？我的建议是分层组合，而不是单选。

我习惯这样搭配：

• 传输层：TLS 1.3，保证端到端加密
• 应用层：HTTPS用于下载大文件（固件包），MQTT用于控制指令和状态上报
• 执行层：UDS over DoIP，负责ECU刷写

为什么这么分？你想想看，固件包动辄几百兆，用MQTT传不现实，HTTPS有断点续传和分块下载，更合适。而升级指令只有几十字节，MQTT的实时性优势就体现出来了。

另外，别忘了证书管理。车机端要预置CA证书，云端要定期轮换服务器证书。我见过一个案例，证书有效期设了10年，结果第8年被破解了——因为私钥泄露。现在行业最佳实践是证书有效期不超过2年，并支持远程更新。

最后说一句，协议选择还要考虑硬件资源。有些低端MCU跑不了TLS，那就得用轻量级的DTLS或者自定义加密。但无论如何，明文传输绝对不行——这是我用真金白银换来的教训。