4. 车载以太网网络层与传输层：IPv4/IPv6双栈，TCP/UDP端口管理，DoIP协议基础（ISO 13400），SOME/IP协议基础
好，咱们进入第四章。这一章讲的是车载以太网的“骨架”——网络层和传输层。
说白了，就是数据怎么在车里找到路，怎么可靠地送到目的地。很多刚入行的朋友觉得这层就是配配IP地址，没什么技术含量。我刚开始也这么想，直到有一次在实车上排查一个远程诊断超时问题，折腾了三天，最后发现是TCP窗口大小没调好。嗯，从那以后我再也不敢小看这层了。
4.1 IPv4/IPv6双栈：为什么车要用两套地址？
传统汽车电子用IPv4，地址池是32位的，大概43亿个地址。听起来很多，对吧？但你想，现在一辆高端车有上百个ECU，再加上OTA、V2X、远程诊断，IPv4的私有地址段（比如192.168.x.x）很快就分光了。
我个人习惯，在设计新平台时直接上双栈。IPv4用来兼容现有诊断工具和售后设备，IPv6留给未来的大规模部署和端到端通信。
我在项目中遇到过一个问题：某Tier1提供的网关模块只支持IPv4，但我们的诊断仪要求IPv6。最后不得不在网关上做NAT64转换，增加了延迟。所以我的建议是——从架构设计阶段就把双栈写进需求文档。
4.1.1 地址分配策略
| 场景 | IPv4策略 | IPv6策略 |
|---|---|---|
| 诊断（DoIP） | DHCP + 链路本地地址 | 无状态地址自动配置（SLAAC） |
| 服务发现（SOME/IP-SD） | 组播 239.192.x.x | 组播 FF02::1 |
| OTA升级 | 静态分配（售后工具固定IP） | DHCPv6 |
4.2 TCP/UDP端口管理：别让端口打架
车载以太网里，端口号是稀缺资源。一个ECU上可能同时跑DoIP、SOME/IP、XCP、AVB等多个协议。端口冲突了，轻则服务不可用，重则整个网络崩溃。
为什么会这样？因为很多工程师习惯用固定端口号，比如DoIP默认用13400，SOME/IP-SD用30490。但如果两个ECU都监听同一个端口，又没有做端口复用，那肯定出问题。
4.2.1 端口分配规范
我建议按照ISO 13400和AUTOSAR的规范来划分端口范围：
- 0-1023： 系统保留端口，不要用。
- 1024-49151： 注册端口，用于标准协议（DoIP: 13400, SOME/IP-SD: 30490）。
- 49152-65535： 动态/私有端口，用于临时连接和自定义服务。
4.2.2 TCP vs UDP 选择
| 特性 | TCP | UDP |
|---|---|---|
| 可靠性 | 有确认重传，可靠 | 无确认，不可靠 |
| 顺序 | 保证数据包顺序 | 不保证顺序 |
| 适用场景 | 诊断请求/响应、OTA下载 | 服务发现、事件通知、流媒体 |
| 车载典型应用 | DoIP、SOME/IP远程过程调用 | SOME/IP-SD、SOME/IP事件 |
我个人习惯：诊断类通信一律用TCP，因为丢一个报文可能导致整个诊断会话失败。服务发现和周期性事件用UDP，延迟低，带宽占用小。
4.3 DoIP协议基础（ISO 13400）
DoIP，全称Diagnostic over Internet Protocol。说白了，就是把传统的CAN诊断（UDS on CAN）搬到以太网上来。
你想想看，CAN诊断一次只能发8个字节，传一个完整的ECU刷写文件得等半天。DoIP一次能发1500字节，速度提升了几十倍。
4.3.1 DoIP协议栈结构
+-------------------------------+
| 应用层 (UDS) |
+-------------------------------+
| 诊断消息层 (DoIP payload) |
+-------------------------------+
| TCP/UDP 传输层 |
+-------------------------------+
| IPv4/IPv6 网络层 |
+-------------------------------+
| 以太网 MAC/PHY 层 |
+-------------------------------+DoIP的核心是逻辑地址。每个ECU有一个逻辑地址（比如0x0E80），诊断仪通过逻辑地址来寻址，而不是直接依赖IP地址。这样做的好处是：IP地址变了，逻辑地址不变，诊断工具不用重新配置。
4.3.2 DoIP关键流程
- 车辆发现： 诊断仪发送广播请求，ECU回复自己的IP和逻辑地址。
- 路由激活： 诊断仪发送路由激活请求，ECU确认后建立诊断会话。
- 诊断通信： 通过TCP连接发送UDS诊断请求/响应。
- 连接关闭： 诊断完成，关闭TCP连接。
4.3.3 避坑：DoIP超时设置
我在项目中遇到过一个问题：诊断仪发送路由激活请求后，ECU没有及时回复。诊断仪等了5秒就超时断开了，但ECU其实正在处理其他任务，3秒后才回复。结果就是诊断会话建立失败。
我的建议：路由激活超时设为10秒，诊断请求/响应超时设为5秒。这两个超时不要混用。
4.4 SOME/IP协议基础
SOME/IP，全称Scalable service-Oriented MiddlewarE over IP。它是AUTOSAR定义的面向服务的通信协议，说白了就是让ECU之间像微服务一样互相调用。
传统CAN通信是信号导向的——你发一个CAN ID，里面打包了几个信号。SOME/IP是服务导向的——你提供一个服务（比如获取车速），其他ECU可以远程调用这个服务。
4.4.1 SOME/IP通信模式
| 模式 | 描述 | 传输层 | 典型场景 |
|---|---|---|---|
| 请求/响应 | 客户端发送请求，服务端回复响应 | TCP/UDP | 读取ECU状态、参数配置 |
| 事件通知 | 服务端主动推送数据给订阅的客户端 | UDP | 车速变化、故障报警 |
| 字段 | 类似事件，但客户端可以主动获取/设置 | UDP | 空调温度设置、车窗位置 |
4.4.2 SOME/IP服务发现（SOME/IP-SD）
SOME/IP-SD是SOME/IP的“黄页”。ECU启动后，通过SOME/IP-SD广播自己提供的服务，同时发现其他ECU提供的服务。
我个人习惯：服务发现周期设为1000ms，不要设得太短（增加网络负载），也不要设得太长（服务发现延迟高）。
4.5 本章知识体系
下面这张图总结了网络层和传输层的核心关系：
这张图从下往上展示了完整的协议栈。每一层都依赖下一层提供的服务。你想想看，如果物理层不稳定，网络层再好的双栈设计也白搭。反过来，如果应用层设计不合理（比如端口冲突），传输层再可靠的TCP也救不了。