4. 车云通信协议
在 T-Box 与车云平台之间，协议选型直接决定了远程控制时延、数据上报成本、弱网可靠性和平台接入复杂度。很多项目把“能连通”当成“选对了”，结果在量产阶段遇到流量费用高、指令下发慢、断网重连丢数据等问题。本节从协议分层、典型特征、适用场景和选型方法四个角度，建立一套可落地的判断框架。
一、先分清协议所处的层次
车云通信不是单一协议，而是一条协议栈。物理层和链路层通常由蜂窝模组完成；网络层使用 IP；传输层在 TCP 与 UDP 之间选择；应用层再叠加 MQTT、HTTP、WebSocket、CoAP 或行业标准协议。JT/T 808 与 GB/T 32960 属于应用层规范，它们既规定了报文格式，也规定了注册、鉴权、心跳、位置上报等业务流程，底层可承载在 TCP 之上。
因此，选型时要先问三个问题：数据是“持续小包”还是“偶发大包”？方向是“车到云单向”还是“云车双向实时”？是否受行业监管强制约束？这三个问题基本能锁定协议族。
二、核心协议特征对比
下表从连接方式、时延、开销、可靠性和典型用途五个维度对比常用协议。注意：MQTT 与 WebSocket 都基于 TCP，但 MQTT 有主题路由和 QoS 机制，更适合设备侧；WebSocket 更适合浏览器或需要全双工文本流的场景。
| 协议 | 传输层 | 连接模式 | 典型时延 | 报文开销 | 可靠性机制 | 典型用途 |
|---|---|---|---|---|---|---|
| MQTT | TCP | 长连接/发布订阅 | 低（百毫秒级） | 小（2 字节起） | QoS 0/1/2、遗嘱、保留消息 | 远程控制、状态上报 |
| HTTP/HTTPS | TCP | 短连接/请求响应 | 中（秒级） | 大（头部冗长） | TCP 重传、TLS 加密 | OTA、文件上传、配置拉取 |
| WebSocket | TCP | 长连接/全双工 | 低 | 小（帧头 2~14 字节） | TCP 重传、心跳保活 | 实时监控、调试通道 |
| CoAP | UDP | 请求响应/观察模式 | 极低 | 极小（4 字节头） | CON 重传、块传输 | 低功耗传感器采集 |
| JT/T 808 | TCP | 长连接/自定义报文 | 低 | 中 | 流水号、重传、心跳 | 营运车辆监管 |
| GB/T 32960 | TCP | 长连接/自定义报文 | 低 | 中 | 应答、重传、时间戳 | 新能源车数据上报 |
三、选型方法与判断流程
选型不是“选一个协议用到底”，而是按业务通道分别决策。推荐按以下流程判断：
- 识别业务类型：远程控制、实时状态推送优先 MQTT；大文件传输、OTA 优先 HTTPS；浏览器实时展示优先 WebSocket；低功耗小数据可考虑 CoAP。
- 确认监管要求：营运车辆必须支持 JT/T 808；新能源车数据上报必须符合 GB/T 32960，不能只用私有 MQTT 替代。
- 评估网络条件：弱网、频繁切换基站时，MQTT 的会话保持和 QoS 1 比 HTTP 短连接更稳；UDP 场景要自行处理丢包与乱序。
- 核算流量成本：按“单条报文大小 × 上报频率 × 车辆数”估算月流量，HTTP 头部开销在低频小包场景下可能占比超过 50%。
- 确定安全方案：公网传输必须启用 TLS；MQTT 使用用户名密码或双向证书；JT/T 808 与 GB/T 32960 按规范实现鉴权和校验。
四、典型场景与配置示例
以 MQTT 远程控制通道为例，T-Box 作为客户端连接车云 Broker，订阅控制主题，发布状态主题。关键参数包括心跳间隔、QoS 等级和遗嘱主题。
# T-Box MQTT 客户端关键配置示例
broker: mqtts://tbox.example.com:8883
client_id: TBOX_${VIN}
username: ${VIN}
password: ${DEVICE_SECRET}
keepalive: 60 # 心跳间隔，秒
clean_session: false # 保持会话，断线后恢复订阅
will_topic: vehicle/${VIN}/offline
will_qos: 1
will_payload: {"status":"offline","ts":${TS}}
# 订阅：云端下发控制指令
subscribe: vehicle/${VIN}/cmd QoS 1
# 发布：车辆状态上报
publish: vehicle/${VIN}/status QoS 1
对于 GB/T 32960 上报，需按规范封装命令标识、应答标志、VIN、加密方式和数据单元。下面是一个简化的报文结构示意：
# GB/T 32960 数据单元结构（简化）
起始符(##) | 命令标识 | 应答标志 | VIN(17字节) | 加密方式 | 数据长度 | 数据单元 | 校验码
命令标识 0x02：车辆登入
命令标识 0x03：实时信息上报
命令标识 0x04：补发信息上报
命令标识 0x05：车辆登出
五、常见误区与复盘
- 误区一：所有数据都走 MQTT。OTA 大包走 MQTT 会阻塞控制通道，且 Broker 对单包大小有限制。应拆分通道，大文件走 HTTPS。
- 误区二：HTTP 轮询代替长连接。轮询在车辆规模大时会造成平台连接风暴和流量浪费，远程控制时延也不可控。
- 误区三：忽略 QoS 与幂等。QoS 1 可能重复投递，控制指令必须带唯一指令 ID，车端做去重，避免重复执行。
- 误区四：只做协议连通，不做弱网测试。应在隧道、地库、高速切换等场景验证重连时间、消息补发和本地缓存策略。
- 误区五：用私有协议替代国标。监管平台只认 JT/T 808 或 GB/T 32960，私有协议无法完成合规接入。
总结来看，车云协议选型的核心是“分通道、按业务、合规范、算成本”。控制类走 MQTT，文件类走 HTTPS，展示类走 WebSocket，低功耗采集可评估 CoAP，监管类必须落地 JT/T 808 与 GB/T 32960。把每条通道的时延、流量、可靠性和合规要求写进设计输入，才能在量产阶段少走弯路。