4、网络层与传输层：IPv4/IPv6在车上的应用、ARP协议、ICMP、UDP与TCP的选择、端口与Socket
各位同学，咱们今天聊聊网络层和传输层。说实话，很多刚入行的工程师容易把这两层搞混，或者觉得「反正上层应用能跑就行」。但做车载以太网，这两层是绕不开的坎。我当年调试第一个SOME/IP项目时，就是因为在传输层选型上栽了跟头，折腾了整整一周才找到问题。
4.1 IPv4 vs IPv6：车上到底用哪个？
先说说IP协议。目前车上IPv4还是主流，但IPv6的渗透速度比我想象中快得多。为什么？
IPv4的优势：成熟、简单、工具链完善。你随便抓个包，Wireshark里全是IPv4的报文。我习惯在开发阶段先用IPv4做原型验证，毕竟调试方便。
IPv6的优势：地址空间大、自动配置、安全性更好。车联网场景下，每辆车可能有几十个ECU，未来还有V2X通信，IPv4的私有地址段（比如192.168.x.x）其实挺紧张的。
我个人建议：新平台直接上IPv6。为什么？
- 地址够用，不用搞NAT穿透
- 支持SLAAC（无状态地址自动配置），减少人工配置
- 头部固定长度40字节，硬件转发效率更高
避坑指南：我曾经在一个项目中，因为用了IPv4的链路本地地址（169.254.x.x），结果和某个ADAS摄像头的静态IP冲突了。后来换成IPv6的链路本地地址（FE80::/10），问题迎刃而解。记住：链路本地地址只在同一链路上有效，别指望它跨网段通信。
4.2 ARP协议：别小看这个「翻译官」
ARP（地址解析协议）说白了就是「我知道你IP，但不知道你MAC，帮我查查」。在车载以太网里，ARP的坑其实不少。
你想想看，车上那么多ECU，如果每个节点都频繁发ARP请求，广播风暴可不是闹着玩的。我遇到过最夸张的情况：一个域控制器每秒发200多个ARP请求，直接把交换机的CPU打满了。
ARP在车上的几个关键点：
- ARP缓存超时：默认超时时间通常20分钟，但车上建议缩短到2-5分钟。为什么？因为ECU可能频繁上下电，缓存过期了还在用旧MAC，通信就断了。
- 免费ARP（Gratuitous ARP）：节点上线时主动广播自己的IP-MAC映射。我习惯在ECU启动后发一次免费ARP，告诉交换机「我来了，更新一下你的转发表」。
- ARP代理：某些网关会代理下游节点的ARP请求。这个在DoIP（诊断 over IP）场景下很常见。
注意：ARP是纯广播协议，没有安全机制。如果有人伪造ARP响应，就能实现中间人攻击。车载网络虽然相对封闭，但OTA升级后如果刷了恶意固件，ARP欺骗是常见的攻击手段。建议在关键链路上启用ARP检测或静态ARP表。
4.3 ICMP：不只是「ping」那么简单
很多人对ICMP的理解就停留在「ping一下通不通」。其实ICMP在车上的用途远不止这些。
ICMP的主要类型：
| 类型 | 用途 | 车上场景 |
|---|---|---|
| 0/8 (Echo Reply/Request) | 连通性测试 | 诊断时验证链路是否正常 |
| 3 (Destination Unreachable) | 目标不可达 | 路由配置错误时快速定位 |
| 11 (Time Exceeded) | TTL超时 | 检测路由环路，traceroute |
| 5 (Redirect) | 路由重定向 | 网关通知主机走更优路径 |
我个人经验：ICMP不可达报文是调试利器。有一次某个摄像头死活连不上域控，我抓包发现域控一直在发ICMP Type 3 Code 1（主机不可达）。查了半天，原来是摄像头的默认网关配错了。如果没有ICMP，你只能干瞪眼。
小技巧：在车载网络中，建议关闭不必要的ICMP响应（比如重定向、时间戳请求），减少攻击面。但保留Echo和Destination Unreachable，方便调试。
4.4 UDP vs TCP：选错协议，性能腰斩
这是个大话题。很多同学问我：「老师，车上到底用UDP还是TCP？」我的回答是：看场景。
UDP的优势：
- 无连接，延迟低（微秒级）
- 头部只有8字节，开销小
- 支持广播和多播
TCP的优势：
- 可靠传输，自动重传
- 流量控制，避免接收方被淹没
- 拥塞控制，适应网络状况
你想想看，车上哪些数据用UDP？
- 传感器数据流：摄像头、激光雷达的原始数据。丢了几个包没关系，下一帧马上来。
- SOME/IP-SD：服务发现报文，用UDP多播，效率高。
- DoIP诊断：某些诊断请求也用UDP，因为简单快速。
哪些用TCP？
- OTA升级包：必须完整、有序、无差错。丢一个字节，整个固件就废了。
- 日志上传：需要保证数据完整性。
- 远程诊断会话：需要可靠的长连接。
我的经验：曾经有个项目，工程师把所有通信都用了TCP。结果摄像头数据流因为TCP的重传机制，导致延迟抖动高达50ms。ADAS系统直接报警「数据不同步」。后来改成UDP + 应用层简单校验，延迟稳定在2ms以内。记住：不要为了可靠而滥用TCP。
4.5 端口与Socket：通信的「门牌号」
端口号，说白了就是进程的「门牌号」。IP地址找到主机，端口号找到进程。
端口分类：
- 0-1023：知名端口，比如HTTP用80，DoIP用13400
- 1024-49151：注册端口，SOME/IP通常用30501-30509
- 49152-65535：动态/私有端口，客户端临时使用
Socket编程，我习惯用Python做原型验证。给你看个简单的UDP Socket示例：
import socket
# 创建UDP Socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 绑定本地端口（比如SOME/IP服务端口30501）
sock.bind(('0.0.0.0', 30501))
# 接收数据
data, addr = sock.recvfrom(1024)
print(f"收到来自 {addr} 的数据: {data.hex()}")
# 发送响应
sock.sendto(b'\x00\x01\x02\x03', addr)嗯，这里要注意：端口冲突是车上常见的问题。多个ECU如果用了相同的端口号，通信就会乱套。我建议在项目初期就制定端口分配表，比如：
| 服务类型 | 端口范围 | 说明 |
|---|---|---|
| SOME/IP-SD | 30490-30499 | 服务发现多播端口 |
| SOME/IP事件 | 30500-30599 | 每个服务分配一个 |
| DoIP诊断 | 13400 | 标准诊断端口 |
| 日志上传 | 20000-20010 | 预留 |
避坑指南：我曾经遇到一个Bug，两个ECU都用了30501端口，结果SOME/IP事件数据互相串扰。排查了三天才发现是端口冲突。后来我们在每个ECU的配置文件中强制指定端口范围，并在启动时做端口可用性检查。
4.6 小结
网络层和传输层，是车载以太网通信的「骨架」。IP选型决定了网络规模，ARP决定了邻居发现效率，ICMP是调试利器，UDP/TCP的选择直接影响性能，端口和Socket则是应用层的基础。
我个人建议：先理解原理，再动手实践。拿个树莓派或者开发板，搭个简单的UDP/TCP通信，抓包看看报文结构。你会发现，很多书上讲不清楚的东西，一看报文就全明白了。
下一章，咱们聊聊应用层协议——SOME/IP和DoIP。这两个才是车载以太网的核心玩法。