3、以太网协议栈基础：TCP/IP协议族在车载环境下的裁剪、UDP与TCP的选型对比、ARP与ICMP在诊断中的应用
各位好，我是老张。今天咱们聊聊车载以太网协议栈里那些绕不开的基础知识。说实话，很多刚入行的朋友一上来就扎进SOME/IP、DoIP这些应用层协议，结果底层一知半解，出了问题根本定位不到根因。我个人习惯是，先把TCP/IP协议族在车载环境下的“变形”搞清楚，后面才能走得稳。
3.1 TCP/IP协议族在车载环境下的裁剪
标准的TCP/IP协议栈是为IT机房设计的，那套东西拿到车上，很多地方得动刀子。为什么？因为车载网络对实时性、确定性、成本和功耗的要求，跟办公网络完全是两码事。
我举个例子。标准TCP/IP里有个IP分片功能，数据包太大就自动切碎。这在车上就是灾难。你想想看，一个紧急制动指令被分成了3个包，第二个包丢了，ECU还得等超时重传——车都撞上了。所以车载协议栈通常强制关闭IP分片，或者把MTU（最大传输单元）设得死死的，比如1500字节，谁也别想超。
另外，ARP协议在车上也被“阉割”了。标准ARP是广播式的，一喊全车都听见。但在域控制器架构下，你一个广播包发出去，所有ECU都得起来响应，总线负载瞬间飙升。我见过一个项目，就因为ARP广播风暴，导致ADAS摄像头丢帧。后来怎么解决的？静态ARP表，或者干脆用ACD（地址冲突检测）替代。
还有TCP的重传机制。标准TCP的指数退避算法，在车上根本等不起。车载环境要求的是“快速失败”，而不是“死磕到底”。所以很多OEM会修改TCP参数，把重传次数从默认的15次砍到3次，超时时间从3秒缩到200毫秒。说白了，宁可丢包，也不能让系统卡死。
- IP分片：强制关闭，或固定MTU
- ARP：减少广播，使用静态表或ACD
- TCP重传：降低重传次数，缩短超时时间
- ICMP：仅保留必要类型（如Destination Unreachable），关闭Redirect
- DHCP：通常用Auto-IP或静态配置替代
3.2 UDP与TCP的选型对比
这个问题，几乎每次培训都会被问到。我的回答很简单：看你的数据要不要“命”。
先看TCP。它提供可靠连接，有确认、重传、流控。听起来很完美对吧？但代价是延迟。一个TCP握手就要1.5个RTT（往返时间），加上慢启动，前几个包根本快不起来。我在项目中遇到过，用TCP传诊断数据，结果ECU启动时网络还没稳定，三次握手死活握不上，诊断会话建立失败。后来换成UDP+应用层确认，问题就解决了。
再看UDP。它无连接、无确认、无重传，说白了就是“发出去就不管了”。但正是这种“不管”，带来了极低的延迟和极小的开销。适合什么场景？传感器数据流（摄像头、激光雷达）、周期性状态广播、时间同步（gPTP）。这些数据丢了就丢了，下一帧马上来，没必要重传。
那什么时候用TCP？我个人建议：需要保证数据完整性的场景。比如固件升级（OTA），一个字节都不能错；再比如诊断日志上传，丢了就得重新来。还有DoIP的某些诊断消息，标准里明确要求用TCP。
| 对比维度 | TCP | UDP |
|---|---|---|
| 可靠性 | 高（确认+重传） | 低（无确认） |
| 延迟 | 高（握手+流控） | 低（无连接） |
| 开销 | 大（20字节头部） | 小（8字节头部） |
| 适用场景 | OTA、诊断、文件传输 | 传感器流、广播、时间同步 |
| 车载裁剪 | 缩短超时、减少重传 | 通常不做裁剪 |
如果你不确定选哪个，先问自己三个问题：
- 数据丢了会死人吗？→ 选TCP
- 延迟超过10ms会出问题吗？→ 选UDP
- 数据量很大但允许丢少量？→ 选UDP+应用层FEC
3.3 ARP与ICMP在诊断中的应用
很多人觉得ARP和ICMP就是底层协议，跟诊断没关系。嗯，我以前也这么想，直到被现实狠狠教育了一回。
先说ARP。在DoIP（基于IP的诊断）里，ECU的IP地址是怎么确定的？通常是通过Auto-IP或者DHCP。但问题来了：诊断仪怎么知道这个IP对应哪个ECU？这时候ARP就派上用场了。诊断仪可以发送ARP请求，询问“谁的IP是192.168.1.10？”，然后目标ECU回复自己的MAC地址。这样诊断仪就能建立IP到MAC的映射，后续的诊断报文才能正确送达。
我曾经遇到一个坑：某ECU在休眠后，ARP缓存过期了。诊断仪唤醒它之后，发诊断请求，结果ECU没响应。为什么？因为诊断仪的ARP表里还存着旧的MAC地址，而ECU的MAC其实没变，但交换机端口可能变了（比如VLAN重新配置）。后来我们在诊断流程里加了一步：发送诊断请求前，先发一个ARP探测包，确保路径是通的。这个习惯我一直保留到现在。
再说ICMP。ICMP在诊断里最常用的就是Ping（ICMP Echo Request/Reply）。别小看Ping，它是验证网络连通性的第一道防线。我在dSPACE的测试环境里，每次跑DoIP测试用例前，都会先Ping一下目标ECU。如果Ping不通，后面的诊断会话、读取DTC什么的都不用测了，先查网络配置。
除了Ping，ICMP还有两个类型在诊断里很有用：
- Destination Unreachable（Type 3）：当诊断仪发请求到一个不存在的IP或端口时，ECU会回复这个ICMP消息。这能帮你快速定位是IP配错了，还是服务没启动。
- Time Exceeded（Type 11）：如果诊断报文在路由过程中TTL减到0，中间节点会回复这个。在车载网络里，这通常意味着路由配置有环路。
有些ECU为了安全，会关闭ICMP响应。比如某些网关配置了防火墙规则，禁止Ping。这时候你Ping不通，不代表网络不通，可能是ICMP被过滤了。我建议先用UDP或TCP的简单连接测试（比如发一个SYN包）来验证，别只依赖Ping。
最后说一个实战技巧。在dSPACE的以太网仿真环境里，我经常用ARP嗅探来检测ECU的IP冲突。具体做法是：让仿真节点发送一个ARP Probe（请求自己的IP），如果收到其他节点的ARP Reply，说明这个IP已经被占用了。这在多ECU同时上电的场景下特别有用，能提前发现地址分配问题。
好了，这一章的内容就到这里。下一章我们会深入SOME/IP协议，看看它如何在UDP和TCP之上实现服务发现和远程调用。到时候我会结合dSPACE的VN5640设备，给大家演示实际的抓包分析。咱们下期见。