前言
DoIP(Diagnostic Communication over Internet Protocol) 协议是一种用于汽车诊断通信的协议，它允许通过 IP 网络(如以太网)进行诊断操作。DoIP 协议设计初衷是为了解决传统基于 CAN 总线的诊断通信方式在带宽、灵活性以及远程访问方面的限制。
协议特点：
基于 IP 网络：DoIP 会把 UDS 报文封装在 TCP/IP 进行通信，只要车辆有 IP 连通性(4G/5G 热点、WI-FI 或有线连接)，不需要把诊断仪插到车上的 OBD 口。这样就可以远程访问车辆的诊断系统，进行故障排查、软件更新等操作。
高带宽：相比 CAN 总线，以太网的数据传输速率会更快。
灵活性：DoIP 基于 IP 网络，不必插线，也支持 DoIP 节点自动发现，车辆入网即被识别，支持多种设备和系统的相互操作。
安全性：DoIP 协议支持加密和身份验证机制，叠加个 TLS 加密、IPsec 等，比 CAN 总线的"广播裸奔"强得多。
总的来说，可以理解为 DoIP 让 UDS 报文通过网络层进行通信，速度更快、更安全、更灵活。并且他自定义了如何建立和维护诊断会话、如何发送和接收诊断信息、如何处理错误等。
但是这并不意味着 CAN 总线被放弃，从本人理解来看，DoIP 更多用于车载信息娱乐、自动驾驶等操作，这些功能挂在以太网上，诊断报文走 DoIP。
但是传统 ECU (发动机、变速箱) 可能还挂在 CAN 总线上，诊断报文走 CAN (ISO 15765-2)。
1、OSI 与网络。
DoIP 协议在 OSI 模型中所在位置。
同时，在 ISO 134001-2 中也有关于 DoIP 的定义，用于车辆诊断的网络层和传输层协议以及服务。
2、TCP 套接字状态
DoIP 实体(如车辆上的网关) 如何处理多个诊断设备同时连接的机制，以及外部诊断仪是如何和他建立 TCP 连接的。
(1)、每个 DoIP 实体应支持 n+1 个 TCP 数据套接字，其中 n 是 DoIP 实体支持的并发 TCP 数据连接数。
n：DoIP 实体允许同时进行的并发诊断会话数量(同时能连接多少外部诊断设备)。
n+1：需要预留 n+1 个套接字来处理连接。多出来 1 个套接字用于监听新连接的(如前台接待)，剩下 n 个才是真正传输诊断数据的。
(2)、外部测试设备应能够支持 TCP 数据连接(TCP 数据套接字)。本地端口通常在套接字创建时自动选择，远程端口由车辆上的 TCP_DATA 端口定义。
外部测试设备作为客户端，主动发起 TCP 连接，本地端口：由操作系统自动分配一个空闲端口，远程端口：必须连接车辆上固定用于 DoIP 诊断的端口，即 TCP_DATA 端口，这个端口在 ISO 13400 标准中通常定义为 13400。
(3)、因此诊断流程：诊断仪用随机端口(如54321) -> 连接车辆 IP 地址的 13400 端口 -> 建立 TCP 连接 ->然后在这个连接上传输 DoIP 报文(里面封装 UDS 诊断请求)。
因为一辆车可能同时被产线设备、售后诊断仪、远程云端同时连接，n+1 保证多路并发。
3、报文格式
这是ISO 13400-2:2012中所描述的，下文是参考文章归纳。
DoIP 是应用层协议，报文走 TCP/UDP，DoIP 报文由报头和数据段组成。
拆分一下报文。首先报头由协议版本(1字节)、反向协议版本(1字节)、负载类型(2字节)、负载长度(4字节)组成。
3.1 DoIP 协议版本号
0x00:预留
0x01:DoIP ISO/IDS 13400-2:2010
0x02: DoIP ISO 13400-2:2012
0x03: DoIP ISO 13400-2:2019
0X04:...OxFE:预留
0xFF:车辆识别请求报文（0x0001）中"协议版本"字段可以填的特殊值3.2 反向协议版本
协议版本号取反，对协议版本进行校验，以保正确的 DoIP 格式。
如协议版本0x03，此值为0xFC
3.3 负载类型
这里是 2 字节的负载类型。
3.3.1 DoIP 首部否定响应码(用于检错)
DoIP 报文在发送出去前会进行错误检查，如格式错误、未知负载类型、报文过长、超出内存等，DoIP 实体会响应一帧负载类型为 0000，负载为 1 字节的否定码的报文。
此图中 0x0000 表示负载类型，特殊值，代表 NACK。
负载长度 0x0001，NACK 码占 1 字节。
ISO 13400-2 中定义的 NACK Code 定义如下：
3.3.1.1 网上案例
由于环境配置等问题，这里不进行模拟，用一篇网上文章进行分析。
如下图，发送一个格式错误的Doip请求，Doip实体响应了NACK Code 0x00，并且主动断开TCP连接。
如下图，发送一个车辆识别请求Doip报文，负载长度应该为0，这里写入1，则Doip实体响应了NACK Code 0x04。
3.3.2 车辆声明报文(识别和确认被诊断车辆)
车辆识别和车辆声明报文(0x0001,0x0002,0x0003,0x0004),此类报文用于识别和确认网络上被诊断车辆。
诊断仪可通过获取车辆的 VIN(Vehicle Identification number)、GID(Group identification)和 DoIP 实体的逻辑地址等信息。
车辆声明报文发送流程如下。
3.3.2.1 测试案例
车辆识别请求(0x0001)，客户端发送 02 fd 00 01 00 00 00 00 车辆识别请求，DoIP 实体返回的车辆识别响应报文，车辆识别响应报文内容包含 VIN、逻辑地址、EID、GID等信息。
DoIP 实体的车辆识别报文如下表，负载长度为 33 字节。
其中 Further action required 的可能值如下表所示，一般情况下为0x00。
VIN/GID sync. status 参数的可能值如下表所示，该参数为可选参数。
3.3.2.2 测试案例有 EID 请求车辆识别请求(0x0002)
如下图，客户端发送 02 FD 00 02 00 00 00 06 70 B3 D5 20 00 01，带 EID 的车辆识别请求，如果 EID 正确，则 DoIP 实体返回负载类型为 0x0004 的车辆识别响应报文，否则 DoIP 实体不响应。
3.3.2.3 测试案例有 VIN 请求车辆识别请求(0x0003)
如下图，客户端发送 02 FD 00 03 00 00 00 11 50 41 4E 47 55 30 31 32 30 35 37 34 39 30 08 34 37 带有 VIN 的车辆识别请求，VIN 正确的话，则 DoIP 实体返回负载类型为 0x0004 的车辆识别响应报文，否则 DoIP 实体不响应。
3.3.3 路由激活报文
ISO 13400 规定，当测试设备需要通过车载 DoIP 网关将报文路由到车辆内部网络之前，需要执行路由激活，激活 TCP_DATA Socket 上的路由。
也就是路由激活请求阶段，测试设备向 DoIP 实体发送报文，反之同理。
先与 DoIP 实体通过 TCP 建立连接，然后测试仪发送负载类型为 0x0005 的路由器激活请求，DoIP 实体响应负载类型为 0x0006 的激活响应报文。
下表是路由激活请求的参数和字节大小。
这里来解释一下，这张表是 ISO 13400-2 标准中关于"路由激活请求"报文负载格式的官方定义，它规定了诊断仪在发送路由激活请求时，必须携带的数据，以及每个字段的含义和取值范围。
路由激活请求(负载为0x0005)的负载部分由以下字段组成。
通俗来讲，诊断仪想进入网关，需要先给网关出示我们的 SA 值，并且带上我们的激活类型，网关收到后会根据我们的信息决定是否放行信息(此时返回的是响应码)。
表 47 ：激活类型(Activation type)的含义
第一行，值为 0x00 ，默认，普通诊断没有特殊认证要求， 强制支持。
第二行，值为 0x01,法规要求的诊断，需满足特定法规的场景，强制支持。
第三行，值为 0x02~0xDF,ISO/SAE 预留，暂时不能用，-。
第四行，值为 0xE0,中央安全，涉及高安全级别的认证，可选。
第五行，值为 0xE1~0xFF,车厂自定义，自定义，可选。
此时我们就能大概理解路由激活请求的"内部构造"了。
现在这个报文里面装着 SA、激活类型、预留字段等数据。
路由激活请求(0x0005)的负载部分组成为：
源地址(SA)：诊断仪的逻辑地址，2 字节。
激活类型：占用 1 字节，用于通知网关激活目的。
预留字段：4 字节预留，4 字节车厂自定义，通常为 0。
表 49 是路由激活报文中路由激活响应码的可能值。0x10 激活成功；0x00 不支持的 SA；0x02 同一连接上 SA 已激活；0x03 SA 冲突（已在其他连接激活）。
在路由激活响应报文中的第 5 字节处。
3.3.3.1 不支持的 SA 地址(0x00)
以此图举例，我们能看到我们的 SA 值为0101，但 DoIP 路由不支持该地址，因此返回地路由激活响应码为 0x00。
3.3.3.2 已经激活的 TCP 连接上使用不同的 SA 地址(0x02)
也就是说在已经激活的 TCP 连接上，使用了不同的 SA地址，也就是非正确地址，DoIP 实体报 0x02 状态码。
在这张图中我们依旧能看到，当前 TCP_Socket 已经使用 0E80 地址激活，此时连接上其他 SA 地址如 0E81。DoIP,实体报 0x02 状态码。
也就是这一条，依然被拒绝，其他情况以此类推。
3.3.4 在线检测请求报文
我们至少建立了 1 个 TCP 连接情况下，测试仪再次发送路由激活请求时,DoIP 实体才会发出在线检测请求报文。
这里需知，在线检测请求报文由 DoIP 实体发出，检测仪在超过时间内未回复则 DoIP 将断开 TCP 连接。
3.3.5 诊断报文
诊断报文的负载数据的前 4 字节分别是源逻辑地址(2 字节，诊断仪的逻辑地址)和目的逻辑地址(2 字节，DoIP 实体或路由到子网的某个 ECU 的逻辑地址)。
用户数据部分才是 UDS 数据。
我们能看到用户数据为 10 01,此时是发送诊断带着的用户数据。
诊断请求 10 01 成功时，UDS 正响应为 50 01，表示已切换到默认会话。
我们也会遇到诊断否定的情况，见表 25-26。
正常连接 TCP 和路由激活后，使用无效 SA 地址发送诊断请求，DoIP 实体返回 NACK 为0x02，并主动断开 TCP。
注：这是诊断报文层的否定响应（0x8003），不是 DoIP 首部否定响应（0x0000）。
其他以此类推。
4、物理层
DoIP 物理层上常通过 OBD 接口连接，除使用标准以太网的四根数据线外(TX+/TX-、RX+/RX-)，还额外定义一根"激活线"（Activation Line），用于唤醒车辆端的 DoIP 节点。这根激活线主要功能在于省电和安全、远程唤醒。
但这并不是 DoIP 协议强制的，ISO 13400 标准定义了多种物理层选项。
使用标准以太网(如 RJ45)：不包含激活线，要求 DoIP 节点持续监听或通过其他方式唤醒。
使用 OBD 接口 + 激活线：为了兼容传统诊断接口(OBD),并满足车辆低功耗的方式。
网上找到的某汽车的实体 OBD 接口。
然后基于 ISO 13400 规范，明确 TX 线序、电路要求，即可完成 用RJ45 进行测试。
总结：DoIP 让 UDS 诊断报文跑在以太网上，速度更快、支持远程，但必须经过"路由激活"这道安检门。它不取代 CAN，而是与 CAN 诊断长期共存------娱乐、自动驾驶走 DoIP，动力、车身走 CAN。对测试来说，合规是验证"正确流程"，安全是看"流程被破坏会怎样"。
参考文章：
- 蚂蚁小兵. 车载以太网DoIP协议，万字长文详解. CSDN. https://blog.csdn.net/qq_34414530/article/details/131129542
- 爱思考的发菜_汽车网络信息安全. 车载以太网DoIP协议,详细入门讲解，由浅入深. CSDN. https://blog.csdn.net/2301_76563067/article/details/132697197
- ISO 13400-2:2012. Road vehicles --- Diagnostic communication over Internet Protocol (DoIP) --- Part 2: Transport protocol and network layer services.
注：本文中部分实验数据参考了上述文章，非本人实测，仅用于辅助理解协议。