4、通信协议基础：HTTP/HTTPS、MQTT、UDS on CAN、DoIP协议对比与选型
各位同学，咱们今天聊点实在的。做OTA，说白了就是让车跟云“说话”。但车上的环境跟咱们手机不一样，网络不稳定、带宽有限、安全要求还贼高。选什么协议，直接决定了你的升级体验是“丝滑”还是“卡成PPT”。
我这些年折腾下来，发现很多新手容易犯一个毛病：上来就选HTTP，觉得它最通用。嗯，这里要注意，通用不等于适用。今天我就把这四个主流协议掰开揉碎了讲，顺便聊聊我踩过的坑。
4.1 HTTP/HTTPS：最熟悉的陌生人
HTTP，大家都不陌生。做Web开发的天天用。但在车上用，你得多个心眼。
优点很明显：
- 生态成熟，工具链丰富。curl、Postman随便测。
- 基于TCP，可靠性有保障。
- HTTPS加了TLS加密，安全性能过关。
但缺点也致命：
- 头部开销大。 一个HTTP请求，光Header就几百字节。你想想看，车机流量可是要花钱的。
- 实时性差。 它是请求-响应模式。服务器不能主动推数据。你要做远程诊断？得车机不停地轮询。
- 长连接管理复杂。 车载网络经常断线重连，HTTP的Keep-Alive在这种场景下表现一般。
我的经验： 我个人习惯把HTTP/HTTPS用在“大文件下载”和“非实时配置下发”上。比如下载升级包，用HTTPS分块下载，配合断点续传，效果不错。但千万别用它做实时状态上报，否则服务器压力会很大。
避坑指南： 我曾经在一个项目里，用HTTP轮询车辆状态，每5秒一次。结果1000台车同时在线，服务器直接挂了。后来改成MQTT推送，问题才解决。
4.2 MQTT：为物联网而生的轻量级选手
MQTT，我愿称之为“车联网的瑞士军刀”。它设计之初就是为了解决低带宽、高延迟、不可靠网络下的通信问题。
核心特性：
- 发布/订阅模式。 服务器可以主动推消息，实时性比HTTP好太多。
- 报文极小。 最小报文只有2个字节。你想想看，这比HTTP省了多少流量。
- 三种QoS等级。 从“最多发一次”到“确保送达一次”，灵活控制可靠性。
- 遗嘱消息。 设备异常断线时，服务器能收到通知。这个功能在车上很有用。
在OTA中的典型应用：
- 车辆状态实时上报（电量、位置、升级进度）。
- 云端下发升级指令。
- 远程诊断请求与响应。
注意： MQTT虽然轻量，但安全性需要自己加强。默认不加密，建议搭配TLS使用。另外，QoS等级别设太高，否则在弱网环境下反而会增加延迟。我一般用QoS 1，兼顾可靠性和效率。
4.3 UDS on CAN：汽车诊断的“老黄牛”
UDS（统一诊断服务）跑在CAN总线上，这是汽车电子工程师的必修课。它不负责传大文件，但负责“精细控制”。
为什么OTA需要它？
- 刷写前的准备工作。 比如解锁ECU、进入编程会话、检查安全访问权限。
- 刷写中的控制。 比如擦除Flash、写入数据、校验完整性。
- 刷写后的验证。 比如读取故障码、检查软件版本。
技术特点：
- 基于请求-响应，但比HTTP更“硬实时”。
- 报文长度受限（CAN 2.0最大8字节，CAN FD最大64字节）。
- 需要分包传输，逻辑复杂。
我的经验： 我记得有一次做Bootloader开发，UDS的“34服务”（请求下载）和“36服务”（传输数据）配合不好，导致刷写过程中ECU死锁。后来查了三天，发现是分包序号处理有bug。所以，UDS的时序逻辑一定要用状态机严格管理。
4.4 DoIP：当诊断走上IP网络
DoIP（基于IP网络的诊断协议），说白了就是把UDS搬到以太网上。随着车载以太网普及，DoIP越来越重要。
相比UDS on CAN的优势：
- 带宽大。 100Mbps甚至1Gbps，刷写速度提升明显。
- 传输距离远。 不再受CAN总线长度限制。
- 支持并行诊断。 可以同时跟多个ECU通信。
在OTA中的角色：
- 作为“高速通道”，传输大块数据（比如升级包）。
- 作为“远程通道”，通过4G/5G网络进行远程诊断。
避坑指南： 我曾经在DoIP的“路由激活”阶段踩过坑。车辆在行驶中，网络拓扑会变化，DoIP的连接状态需要动态管理。否则，会出现“诊断会话中断”的问题。建议在应用层加心跳机制。
4.5 协议选型对比表
| 特性 | HTTP/HTTPS | MQTT | UDS on CAN | DoIP |
|---|---|---|---|---|
| 传输层 | TCP | TCP | CAN | TCP/UDP |
| 报文开销 | 大（几百字节） | 小（2字节起） | 极小（8字节） | 中等 |
| 实时性 | 低（轮询） | 高（推送） | 高（硬实时） | 高 |
| 适用场景 | 大文件下载、配置下发 | 状态上报、指令下发 | ECU刷写控制、诊断 | 高速刷写、远程诊断 |
| 安全性 | 高（HTTPS） | 中（需自建） | 低（需应用层加密） | 中 |
| 复杂度 | 低 | 中 | 高 | 高 |
4.6 选型建议：别纠结，看场景
说了这么多，到底怎么选？我的建议是：不要只用一种协议，要组合使用。
- 云端到车机： 用MQTT做指令和状态通道，用HTTPS做下载通道。
- 车机到ECU： 用UDS on CAN做精细控制，用DoIP做高速数据传输。
- 远程诊断： 用DoIP over MQTT，把诊断报文封装在MQTT里传输。
最后说一句： 协议只是工具，别为了用而用。我见过有人非要在CAN上跑HTTP，结果性能惨不忍睹。也见过有人用MQTT传升级包，结果丢包率居高不下。选型之前，先想清楚你的核心需求是什么：是实时性？是可靠性？还是带宽？想明白了，答案自然就有了。
好，这一章就到这里。下一章我们聊聊“升级包的结构设计与差分算法”，这可是OTA的核心技术之一，敬请期待。