4、DoIP传输层机制：TCP连接管理、UDP发现机制、DoIP报文头部结构详解

好，我们进入DoIP最核心的传输层机制。这部分内容，说白了就是车和诊断仪之间怎么「打招呼」、「握手」以及「传纸条」的规矩。我个人习惯把传输层拆成三块来看：TCP负责可靠的数据传输，UDP负责设备发现，而报文头部则是所有通信的通用信封。咱们一个一个来聊。

4.1 TCP连接管理：可靠传输的基石

DoIP为什么选TCP？因为诊断数据丢不得。你想想看，刷写ECU固件时丢一个字节，那ECU可能就变砖了。TCP的可靠性在这里是刚需。

DoIP的TCP连接管理，其实就是在标准TCP三次握手之上，加了一层DoIP自己的「应用层握手」。我遇到过不少刚入行的工程师，以为TCP连接建立就算完事了，结果发现诊断仪发过去的请求ECU根本不响应——嗯，这里要注意，DoIP要求客户端先发送一个路由激活请求，服务器回复确认后，才算真正建立了诊断会话。

我曾经在一个项目中，发现诊断仪反复重连，查了半天原来是路由激活的响应超时设置得太短。ECU那边还在处理上电初始化，这边已经等不及了。所以我的建议是：路由激活的超时时间至少给到5秒以上，别太抠。

4.2 UDP发现机制：谁在车上？

UDP在DoIP里干的事，说白了就是「广播找人」。诊断仪刚接入车载网络时，它不知道车上都有哪些ECU支持DoIP，也不知道它们的IP地址。这时候就需要UDP上场了。

DoIP定义了两个关键的UDP端口：

• UDP 13400：用于车辆发现和声明
• UDP 13401：用于诊断仪和ECU之间的简单通信（较少用）

具体的发现流程是这样的：

1. 诊断仪向广播地址发送车辆识别请求（VIN请求）
2. 支持DoIP的ECU收到后，回复车辆识别响应，包含VIN、逻辑地址等信息
3. 诊断仪根据响应内容，决定与哪个ECU建立TCP连接

你可能会问：为什么不用TCP做发现？因为TCP需要先建立连接，而UDP无连接的特性更适合这种「先探路」的场景。说白了，UDP就是敲门砖，敲开门之后的事交给TCP。

4.3 DoIP报文头部结构详解

这是DoIP协议最基础的部分，也是我每次培训必讲的内容。DoIP报文头部，就像一封信的信封，上面写着发件人、收件人、信件类型和长度。没有这个信封，接收方根本不知道该怎么处理里面的内容。

DoIP报文头部固定为8字节，结构如下：

字节偏移	字段名称	长度（字节）	说明
0	协议版本	1	当前为0x02（ISO 13400-2:2012）
1	反向协议版本	1	协议版本的取反，用于校验
2-3	负载类型	2	标识报文类型（如0x0001为路由激活请求）
4-7	负载长度	4	后续负载数据的字节数（不含头部）

这里我特别想强调一下反向协议版本这个字段。它的作用是快速检测协议版本不匹配。比如发送方版本是0x02，反向就是0xFD。接收方收到后一算，如果发现反向版本不对，直接丢弃报文，不用再往下解析了。这个设计很巧妙，我在做协议栈实现时，就利用这个字段做了一层快速过滤。

再看负载类型，它决定了报文的具体用途。常见的负载类型有：

• 0x0001：路由激活请求/响应
• 0x0002：诊断消息（UDS请求/响应）
• 0x0003-0x0005：车辆信息请求/响应
• 0x8001：DoIP实体状态响应

最后，我给大家一个实际的报文解析例子。假设我们抓到一个DoIP报文，头部十六进制如下：

02 FD 00 01 00 00 00 10

解析一下：

• 0x02：协议版本，符合ISO 13400-2:2012
• 0xFD：反向版本，0x02取反后确实是0xFD，校验通过
• 0x0001：负载类型，这是一个路由激活请求
• 0x00000010：负载长度，16字节，后面跟着的就是路由激活的具体参数

你看，就这么简单。8个字节的头部，把通信的「身份」和「意图」说得清清楚楚。我个人觉得，DoIP的头部设计是ISO 13400系列里最优雅的部分之一——简洁、高效、自描述。

好了，传输层机制就讲到这里。下一节我们会深入路由激活的具体流程，以及如何处理各种异常情况。记住，TCP管可靠，UDP管发现，头部管格式——这三者配合好了，远程诊断才能跑得稳。