3. DoIP网络层与传输层：地址分配、端口规划与Socket通信

各位好，我是老张。今天咱们聊点实在的——DoIP的“血管”和“心脏”。网络层和传输层，说白了就是数据怎么找到路、怎么安全到达。我见过不少项目，应用层写得漂漂亮亮，结果底层网络配置一塌糊涂，车连不上、诊断超时，最后全得返工。

嗯，咱们直接切入正题。DoIP在IPv4和IPv6上都能跑，但策略完全不同。端口规划更是有讲究，UDP 13400和TCP 13400，别看端口号一样，干的活可不一样。

3.1 IPv4/IPv6地址分配策略

先说说地址分配。DoIP节点要通信，首先得有个IP地址。怎么拿到这个地址？两种方式：自动配置和手动配置。

IPv4场景：

• 自动配置（DHCP）：车辆接入诊断仪的网络后，通过DHCP获取IP地址。这是最常用的方式。我个人习惯在测试台架上用DHCP，省事。
• 链路本地地址（Auto-IP）：如果DHCP服务器没响应，节点会自动生成169.254.x.x的地址。注意，这个地址只能在本地链路通信，不能路由。
• 静态配置：用于固定测试环境或ECU开发阶段。我建议别在生产车上用静态IP，万一地址冲突，排查起来很头疼。

IPv6场景：

• 无状态地址自动配置（SLAAC）：DoIP节点通过路由器通告（RA）获取网络前缀，再结合自己的接口ID生成地址。这是IPv6的推荐方式。
• 有状态配置（DHCPv6）：类似IPv4的DHCP，但用得少。我在项目中遇到过，某些OEM要求必须用DHCPv6来记录诊断设备的IP，方便审计。
• 链路本地地址（FE80::/10）：每个IPv6接口自动生成，用于邻居发现和本地通信。DoIP的车辆发现机制就依赖这个地址。

3.2 UDP与TCP端口规划（UDP 13400 / TCP 13400）

端口号13400，这是DoIP的“门牌号”。但UDP和TCP虽然端口号一样，用途完全不同。你想想看，如果搞混了，数据发出去没人收，或者收错了，诊断会话就建立不起来。

UDP 13400：用于车辆发现和诊断请求的广播/组播。

• 诊断仪发送UDP广播报文，询问“谁是DoIP节点？”
• 车辆上的DoIP节点收到后，回复自己的IP地址、VIN码、逻辑地址等信息。
• UDP是无连接的，速度快，但不保证可靠。所以只用于发现和简单的心跳检测。

TCP 13400：用于诊断消息的可靠传输。

• 一旦车辆被发现，诊断仪和ECU之间建立TCP连接。
• 所有的诊断请求/响应（比如UDS诊断服务）都通过这个TCP连接传输。
• TCP保证数据不丢失、不重复、按序到达。诊断数据必须可靠，你总不希望读到错误的故障码吧？

特性	UDP 13400	TCP 13400
用途	车辆发现、广播/组播	诊断消息传输
可靠性	不可靠（无确认）	可靠（有确认和重传）
连接性	无连接	面向连接
典型报文	车辆识别请求/响应、心跳	UDS诊断请求/响应
我踩过的坑	防火墙没开UDP端口，发现失败	TCP连接数超限，诊断仪无法连接

3.3 Socket通信模型

Socket，说白了就是网络通信的“管道”。DoIP的Socket模型，我习惯把它分成三层：应用层Socket、传输层Socket和网络层接口。

咱们直接看一个典型的DoIP Socket通信流程：

1. 诊断仪创建UDP Socket，绑定端口13400，发送车辆发现广播。
2. ECU创建UDP Socket，监听端口13400，收到广播后回复。
3. 诊断仪创建TCP Socket，连接到ECU的IP地址和TCP 13400端口。
4. ECU接受连接，建立TCP Socket，开始诊断会话。
5. 双方通过TCP Socket发送和接收DoIP诊断报文。
6. 会话结束，关闭TCP Socket。

嗯，这里要注意：一个ECU可以同时处理多个TCP连接吗？理论上可以，但DoIP规范建议每个ECU只维护一个活跃的诊断连接。我见过有些实现开了多个连接，结果状态机乱套了。

下面这张图，展示了DoIP Socket通信的完整模型。从诊断仪到ECU，数据怎么走，一目了然。

最后，我总结一下Socket通信的几个关键点：

• UDP Socket：用于广播和组播，不建立连接，速度快。适合车辆发现和心跳。
• TCP Socket：用于点对点可靠传输，需要建立连接。适合诊断数据交换。
• 端口复用：同一个端口（13400）可以同时用于UDP和TCP，互不干扰。
• Socket选项：建议设置SO_REUSEADDR，防止端口被占用后无法重启。