1. 课程导入

大家好，我是这次课程的主讲。在车联网这行摸爬滚打了十几年，从最早的2G T-Box做到现在5G+V2X，踩过的坑确实不少。今天咱们先聊聊车云通信的来龙去脉，把地基打牢。

1.1 车联网发展历程：三个阶段的演进

车联网不是一天建成的。我个人习惯把它分成三个阶段来看：

阶段	时间	核心能力	典型技术
1.0 远程信息处理	2000s-2010s	GPS定位、紧急呼叫	2G/3G、T-Box
2.0 智能网联	2010s-2020s	OTA升级、远程控制	4G LTE、MQTT
3.0 车路云一体化	2020s-至今	协同感知、高精地图实时更新	5G、V2X、HTTP/2

1.0时代，说白了就是给车装个能打电话的盒子。我在2010年参与过一个项目，T-Box用2G网络上报GPS位置，协议是自己拼的二进制流。那时候能远程看个车在哪，就觉得挺牛了。

2.0时代，4G普及后，带宽上来了。车企开始搞远程空调、车门控制，还有最重要的OTA。我记得2016年帮某主机厂设计OTA协议，MQTT刚火起来，我们纠结了很久要不要用——后来真香了。

3.0时代，也就是现在。车不再是孤岛，它要和路侧设备、云端大脑实时对话。你想想看，自动驾驶需要毫秒级的低延迟，4G扛不住了，5G和V2X必须上。协议也从简单的上报，变成了双向实时交互。

1.2 车云通信的典型应用场景

场景决定协议选型。我见过太多团队上来就选MQTT，结果发现高精地图下发根本跑不动。咱们先看看几个核心场景：

场景一：车辆状态监控与远程诊断

• 数据特征：小包、高频（秒级）、上行为主
• 典型数据：车速、转速、电池SOC、故障码
• 协议倾向：MQTT、CoAP（轻量级）

场景二：OTA远程升级

• 数据特征：大包、低频、下行为主
• 典型数据：固件包（几百MB）、差分补丁
• 协议倾向：HTTP/HTTPS（断点续传是关键）

场景三：高精地图与协同感知

• 数据特征：超大包、实时、双向
• 典型数据：点云数据、道路模型
• 协议倾向：HTTP/2、WebSocket、自定义UDP

场景四：远程控制（空调、车门、车窗）

• 数据特征：小包、低延迟、高可靠性
• 典型数据：控制指令、状态回执
• 协议倾向：MQTT（QoS 1/2）、私有TCP长连接

1.3 通信协议选型的关键考量

选协议不是拍脑袋。我总结了一个五维评估模型，每次做架构设计前都会过一遍：

1. 带宽与延迟：车端网络环境复杂（地下车库、高速移动），协议头越小越好。
2. 可靠性要求：远程控制丢包会出大事，必须QoS保障；但状态上报偶尔丢一包无所谓。
3. 功耗与算力：T-Box的CPU和内存有限，别上太重量的协议栈。
4. 安全性：车是移动的，证书管理、TLS握手开销都得算进去。
5. 生态与维护：选社区活跃的协议，别自己造轮子——除非你团队够强。

协议	带宽开销	实时性	可靠性	适用场景
MQTT	低（2字节最小头）	中	高（QoS 0/1/2）	状态上报、远程控制
HTTP/HTTPS	高（请求头大）	低	高	OTA、日志上传
WebSocket	中	高	中	实时交互、数据订阅
CoAP	极低（基于UDP）	高	中	传感器、低功耗设备
自定义TCP	可控	高	高	极端定制化场景

1.4 车云通信架构全景图

下面这张图是我自己画的车云通信架构全景。它把端、管、云三层的关系理清楚了，后面每一章都会围绕这张图展开。

嗯，这张图其实透露了一个关键信息：协议选型不是孤立的。车端用什么协议，网络层能不能透传，云端能不能解析，必须拉通考虑。我见过最惨的案例是车端用了MQTT over TCP，但云端网关只开了HTTP端口，结果数据全堵在防火墙外面。

1.5 本章小结

这一章我们走马观花看了车联网的过去、现在和典型场景。说白了，车云通信的核心就三件事：连得上、传得稳、算得快。后面的29章，我们会一个一个协议、一个一个坑地拆解。你准备好了吗？