4. 网络层与传输层：IP地址规划原则、UDP与TCP的选择依据、端口号分配、组播通信在车地通信中的应用
各位好，我是老张。今天咱们聊聊网络层和传输层。说实话，很多刚入行的工程师觉得这层就是个“管道”，数据能通就行。但我在项目里吃过不少亏，才明白这层的设计直接决定了整个系统的稳定性和实时性。
咱们先看一个实际场景：一列时速80公里的列车，每100毫秒就要向地面发送一次位置报告。如果网络层规划不好，数据包可能绕路；如果传输层选错协议，重传机制可能让数据“迟到”。嗯，咱们一个一个来拆解。
4.1 IP地址规划原则：别让地址成为瓶颈
IP地址规划，说白了就是给每个设备发一个“门牌号”。但轨道交通系统里，设备数量多、层级复杂，规划不好就容易乱套。
我个人习惯用这三条原则：
- 分段清晰：把车载设备、地面设备、维护终端分成不同的网段。比如车载用10.1.x.x，地面用10.2.x.x。这样一眼就能看出设备归属。
- 预留扩展：别把地址段用满。我见过一个项目，规划时只留了20个地址给车载，结果后来加车时发现不够用，只能重新划网段，那叫一个折腾。
- 静态为主：车地通信里，设备位置相对固定。我建议用静态IP，别依赖DHCP。万一DHCP服务器挂了，整列车都连不上地面，这风险你扛不起。
重要提醒：IP地址规划时，一定要考虑冗余。比如双网冗余的车载设备，两个网口要分属不同子网，避免单点故障。
4.2 UDP与TCP的选择依据：实时性 vs 可靠性
这个问题我几乎每次培训都会被问到：“老师，车地通信到底用UDP还是TCP？”
我的回答是：看场景。别一刀切。
先说说TCP。TCP有确认重传机制，数据丢包了会重发。听起来很完美对吧？但你想过没有，重传需要时间。在车地通信里，如果列车位置报告丢了，地面等0.5秒才收到重传的数据，那列车可能已经跑出去十几米了。对于安全相关的数据，这0.5秒的延迟可能是致命的。
再聊聊UDP。UDP没有重传，发出去就不管了。但它的延迟低、开销小。对于实时性要求高的数据，比如列车位置、速度、控制命令，UDP是更好的选择。你想想看，地面每100毫秒发一次控制命令，丢一包没关系，下一包马上就到。但如果是文件传输，比如列车运行日志，那还是用TCP靠谱。
我建议这样选：
| 数据类型 | 推荐协议 | 原因 |
|---|---|---|
| 实时控制命令 | UDP | 低延迟，允许少量丢包 |
| 列车位置报告 | UDP | 周期性发送，丢包可容忍 |
| 文件下载/升级 | TCP | 需要完整可靠传输 |
| 诊断日志 | TCP | 数据完整性要求高 |
我的经验：我曾经在一个项目里，所有数据都用TCP。结果列车高速运行时，网络抖动导致TCP频繁重传，控制命令延迟飙升。后来我们把实时数据切到UDP，问题就解决了。记住：别让TCP的重传机制成为你的瓶颈。
4.3 端口号分配：别撞车
端口号就像设备的“服务窗口”。车地通信里，每个应用服务都要绑定一个端口。如果端口号冲突，数据就会发错地方。
我建议的分配原则：
- 使用高端口：避开0-1023的知名端口。车地通信一般用50000-60000之间的端口。
- 按功能划分：比如位置报告用50001，控制命令用50002，诊断数据用50003。这样方便排查问题。
- 文档化：把端口分配表写进设计文档。我见过一个项目，两个团队各自开发，结果用了同一个端口，联调时数据乱套，查了三天才找到原因。
注意：端口号不要用连续的，留一些间隔。万一以后要加新功能，不用大改。
4.4 组播通信在车地通信中的应用
组播，说白了就是“一对多”的通信方式。在车地通信里，这个技术特别有用。
为什么需要组播？
你想想看，地面设备要同时给多列车发送信息，比如线路临时限速。如果用单播，地面要发N次，效率低；如果用广播，所有设备都收到，浪费带宽。组播就解决了这个问题：地面只发一次，只有订阅了该组播组的列车才能收到。
组播在车地通信中的典型应用：
- 线路状态广播：地面向所有在线列车广播线路状态，比如前方施工、限速信息。
- 时钟同步：地面通过组播发送NTP时间同步包，所有列车同时校准时钟。
- 紧急消息：比如火灾报警，地面通过组播快速通知所有列车。
组播地址怎么选？
组播地址范围是224.0.0.0到239.255.255.255。车地通信一般用239.x.x.x的本地管理地址。我个人习惯用239.1.1.x，x代表不同的服务类型。
避坑指南：我曾经在一个项目里，组播配置没做好，导致列车进入隧道后收不到组播包。后来发现是交换机没开启IGMP Snooping。记住：组播依赖网络设备的支持，一定要在交换机上配置好IGMP协议。
好了，关于网络层和传输层，咱们就聊这么多。总结一下：IP地址规划要分段清晰、预留扩展；UDP和TCP的选择要看实时性和可靠性需求；端口号要按功能分配、避免冲突；组播是车地通信中“一对多”场景的利器。下一章咱们聊聊应用层的协议设计，到时候见。