1. 轨道交通售货机网络协议概述
各位同学好，我是老张。在嵌入式通信和轨道交通这个行当摸爬滚打了十几年，今天咱们来聊聊轨道交通售货机的网络通信协议定制。
说实话，这个题目听起来有点大。但你别怕，我会用最接地气的方式，把这块硬骨头啃下来。
1.1 行业背景：为什么售货机进了地铁就不一样了？
先说说背景。普通售货机大家见得多了——商场里、写字楼里，4G模块一插，云平台一对接，完事。但轨道交通场景，完全不是一回事。
我2018年参与过上海地铁某条线路的售货机项目。当时客户提了个需求：售货机要能实时上报库存，还要支持远程升级固件。听起来简单吧？结果一落地，问题全来了。
轨道交通售货机面临的核心挑战：
- 网络环境恶劣：地铁隧道里信号时有时无，高峰期人挤人，Wi-Fi干扰严重。你想想看，一个售货机在站台，高峰期几千人从它面前走过，手机信号都费劲，何况售货机？
- 安全要求极高：轨道交通系统是国家级关键基础设施。售货机虽然是个小设备，但它连在轨交网络上，一旦被攻破，后果不堪设想。我曾经见过一个项目，因为售货机用的还是HTTP明文通信，直接被安全审计打回重做。
- 运维成本敏感：地铁站里换一台售货机，人工成本比机器本身还贵。所以协议必须支持远程诊断、远程升级、远程配置。说白了，能远程解决的问题，绝不让工程师跑一趟。
- 多厂商互通：一条地铁线可能有3-5家售货机厂商。每个厂商的协议都不一样，后台系统怎么管？我见过最夸张的，一个地铁公司后台要对接7种不同的协议，运维人员都快疯了。
核心观点：轨道交通售货机的网络协议，不是简单的"能通信就行"。它要在恶劣环境下保证可靠，在严格安全要求下保证合规，在低成本运维下保证高效。这就是我们定制协议的根本原因。
3.2 协议定制的重要性：不定制，你就等着踩坑
有人可能会问：直接用现成的MQTT或者HTTP不行吗？
嗯，这个问题我当年也问过自己。答案是：可以，但你会踩很多坑。
我总结了几条血的教训：
- 标准协议太重：HTTP的头部动不动几百字节，在弱网环境下，一个心跳包都发不出去。我做过测试，在信号强度-110dBm的地铁站台，HTTP的TCP三次握手成功率不到60%。
- 安全机制缺失：MQTT虽然轻量，但它的安全机制主要依赖TLS。而轨道交通场景要求的是双向认证、国密算法、甚至物理层加密。这些MQTT原生不支持。
- 业务语义不匹配：售货机有它独特的业务逻辑——货道状态、支付流程、补货通知、故障上报。这些用通用协议表达，要么太啰嗦，要么表达不清。
- 离线处理能力差：地铁隧道里经常断网。售货机必须能在离线状态下完成交易，等网络恢复后再同步。这个"离线-在线"的切换逻辑，标准协议基本没考虑。
我的建议：不要试图用一把钥匙开所有的锁。轨道交通售货机这个场景，值得你花时间定制一套专属协议。我在做深圳地铁项目时，就是基于CoAP协议做了深度定制，最终效果比直接用MQTT好了不止一个量级。
1.3 课程目标：学完你能干什么？
这门课不是讲理论，是讲实战。学完之后，我希望你能做到：
- 独立设计一套轨道交通售货机的通信协议，从帧结构到会话管理，从安全认证到数据压缩，全链路打通。
- 解决实际工程问题：弱网环境下的重传策略、离线交易的数据一致性、多厂商协议的兼容性设计。这些坑我都踩过，我会把避坑指南一一告诉你。
- 通过轨道交通行业的安全认证：我会重点讲国密算法、双向认证、安全启动这些轨道交通特有的安全要求。你学完可以直接拿去用。
- 降低运维成本：协议设计好了，远程升级、远程诊断、远程配置都不是问题。我曾经帮一个客户优化协议后，他们的现场运维次数减少了80%。
1.4 学习路径：怎么学最有效？
我个人习惯把学习分成三个阶段：
| 阶段 | 内容 | 时间建议 |
|---|---|---|
| 第一阶段 | 协议基础 + 轨道交通行业特点 | 2周 |
| 第二阶段 | 协议设计实战（帧结构、会话、安全、压缩） | 4周 |
| 第三阶段 | 协议实现与测试（嵌入式移植、压力测试、兼容性测试） | 4周 |
具体建议：
- 每学完一章，自己动手写一个小demo。比如学完帧结构，就写一个简单的协议解析器。
- 遇到不懂的，先记下来，继续往下看。很多问题在后面章节会自然解开。
- 多问自己"为什么"——为什么帧头要用0xAA55？为什么重传间隔要指数退避？想明白了，你就真的懂了。
注意：这门课不要求你精通所有网络协议，但你需要有基本的嵌入式C语言编程能力和网络通信基础。如果你对TCP/IP协议栈完全陌生，建议先补一下基础。
好了，第一章就到这里。下一章我们会深入协议设计的核心——帧结构。我会用一个实际项目中的案例，带你一步步设计出既高效又安全的通信帧。到时候见。