由于DoIP现协议是基于以太网技术的车辆诊断协议，所以诊断数据在OSI参考模型各分层传递方式与传统以太网一致。DoIP协议规范了网络通信中TCP/UDP数据包中有效载荷（Payload）部分内容，在TCP/IP与更高层诊断协议之间提供了统一接口，DoIP报文由DoIP报头和有效载荷组成，其中有效载荷根据DoIP报文的不同功能有不同的类型，其与传统以太网帧的关系如下图所示。

DoIP报头 由协议版本 、反向协议版本、有效载荷类型和有效载荷长度组成，下表展示了DoIP报头结构。

协议版本用来表示DoIP协议版本的编号，其范围为0x00到0xFF。0x01代表ISO/DIS13400-2：2010，是第一版DoIP协议草案；0x02代表ISO13400-2：2012；0x03代表目前最新的ISO13400-2：2019。0xFF为默认值，用于在客户端DoIP实体支持多个协议版本，且没有有关实体支持的DoIP版本信息时，测试设备发送的DoIP报文才使用此默认值。但是建议提前确认好使用的协议版本，以便数据传输的可靠性，一般以最新版本为准。

反向协议版本是协议版本与16进制字节0xFF之间逻辑异或运算的结果，该值与DoIP协议版本配合起到协议版本验证的作用，以确保能接收到正确的DoIP报文。

有效载荷类型用于标识DoIP通信中使用的不同类型报文，也 可 被 称 为 DoIP 报 文 类 型 。其 中 主 要 分 为 三 种 分 组 ：节 点 管 理 报 文 、车辆信息报文和诊断报文，三个分组下又被分成了不同类型报文，包括对应传输层协议如下表所示。

节点管理消息：用于节点管理的消息组成。从通信阶段来看，车辆识别和路由激活阶段的消息，以及车辆与测试设备连接后用于查询测试设备是否仍处于活跃状态的活动检查消息一起属于该类别。

车辆信息消息：用于收集执行诊断之前可能有用的DoIP实体和特定车辆的信息，例如检索当前被诊断车辆的诊断电源模式以及其他车辆工作条件信息，以此来判断当前车辆条件是否适合进行诊断。

诊断消息：封装有上层的诊断协议，在本文中讨论的为目前应用较为广泛的UDS协议。

有效载荷长度：用来表示包含DoIP报文是数据的长度，该长度以字节为单位，且不包括DoIP报头字节。根据DoIP报文有效载荷类型的不同，有的类型长度固定，有的类型长度可变。但是范围需要控制在0到4294967295个字节，这要求在数据传输之前根据报文类型的不同对数据的大小进行计算以确保数据完整正确的传输。

1.3  DoIP 报头处理

DoIP报头一方面能够标识其为DoIP报文，另一方面通过DoIP协议中的报头处理机制，能够屏蔽错误或无法处理等情况的报文，如果报文不能被正确的处理，DoIP实体需要响应一个长度为1字节的否定响应代码（Not Acknowledge，NACK）。否定应答代码用来指示在DoIP报头中检测到的特定错误，并指示接收到否定响应代码的DoIP实体执行后续操作。需要注意的是，如果出现特殊的错误情况，不得进行否定响应，具体情况可参考ISO 13400文档。

下表展示了ISO 13400文档中描述的5种错误报文对应的否定响应代码和跟进操作，包括如何处理消息和通信连接，并对未来可能出现的情况保留的更新空间。

下面将结合ISO 13400文档中相关“需求”，进一步讨论DoIP报头处理机制是如何在数据传输之初提供可靠性保障，并解释这些机制背后的思想。

需求[DoIP-039]指出，DoIP实体应该忽略带有否定响应代码（NACK）的DoIP报文，换句话说，否定响应只有DoIP实体发送至测试设备单向有效，而在另一个方向无效。随后的[DoIP-040]指出测试设备不得发送带有错误响应代码（NACK）的报文。这两个需求共同阻止DoIP实体与测试设备之间来回重复的错误响应代码（NACK）发送，避免了恶意消耗带宽的网络攻击手段。

需求[DoIP-031]指出，接收节点应忽略任何以多IP或广播IP为源地址的数据包。从安全角度来说，有助于防止攻击者将此类数据发送至合法主机，如防止DoIP实体回复多播或广播地址。

需求[DoIP-041]到[DoIP-045]包含了上面表格中几种不同类型错误的详细描述和采取跟进操作，ISO13400-2：2019文档中图16通过状态机描述了对DoIP报头检查顺序，也就是说定义了按照什么顺序处理消息和Socket连接。这两点有助于减轻由协议版本或DoIP报文类型识别错误而产生的数据解析歧义。

[DoIP-041]规定DoIP实体接收到的DoIP报头中协议版本和反向协议版本应为ISO 13400标准中规定的值，对报文协议版本进行提前确认有助于保证了数据解析的正确性。此机制也是一种简单的数据完整性检查机制，但其仅覆盖8个报头字节的前两个字节，显然无法较好确保数据完整。

[DoIP-042]的要求与[DoIP-041]类似，DoIP报文类型需要满足ISO 13400标准规定的值。由于这些值定义明确，因此DoIP实体能够明确接收的是哪种类型报文。针对协议的攻击一般采用发送随机消息，发送的数据无意义，以上两种检测机制有效降低了这类攻击的效果。

[DoIP-043]和[DoIP-044]的规定类似，都是对有效载荷长度的检查，区别在[DoIP-043]是将有效载荷长度与接收实体设置的最大处理长度比较，检查是否有处理能力，而[DoIP-044]则是与接收实体中内存最大容量相关，可能出现满足最大处理长度但内存空间被占用，暂时无法接收的情况。此机制可以防止数据溢出，避免占用接收实体过多资源，某些网络攻击也会利用数据溢出使ECU产生故障。

[DoIP-045]规定接收数据的DoIP实体应检测有效载荷长度与DoIP报文类型要求的长度是否匹配。如果两者不匹配，则该报文的内容存在问题，接收实体不需要处理。

1.4 DoIP报头传输层端口分配

由于DoIP是基于Socket的网络通信方式，所以实现通信之前，需要对数据传输使用的端口进行分配。ISO 13400文档依据不同的功能对TCP和UDP协议的端口使用进行了建议。

在建立TCP通信过程中，测试设备自动选择端口号作为发送端口，向车内DoIP实体的13400端口发送消息；建立UDP通信过程分为两类，一类是测试设备主动发送的请求报文，另一类是测试设备被动接收的报文，这两类报文的目标端口都是13400端口。下表展示了DoIP诊断过程中各类报文的端口使用情况。

UDP_TEST_EQUIPMENT_REQUEST：动态分配。

1.5 DoIP诊断的主要阶段

车辆声明（0x0004）和车辆识别响应（0x0004）：拥有同样的有效载荷结构，其内容都为描述DoIP实体基本信息的数据，但车辆声明和车辆识别响应的应用场景不同。车辆声明用于在没有接收到测试设备请求的情况下，主动向网络广播自己的信息，测试设备依据需求判断是否需要与正在广播的DoIP实体建立连接。车辆识别响应是DoIP实体接收到车辆识别请求后，对请求作出的积极响应（如上文提到的包含EID或VIN的车辆识别请求）。车辆声明和车辆识别响应有效载荷的结构如下图所示。

ISO 13400规定，当测试设备需要通过车载DoIP网关将报文路由到车辆内部网络之前，需要执行路由激活阶段，用于激活TCP_DATA Socket上的路由。该阶段包括路由激活请求和路由激活响应。路由激活请求报文由测试设备发送至DoIP实体，路由激活响应由DoIP实体发送至测试设备，详细信息如下表所示。

路由激活请求报文（0x0005）的有效载荷中包含测试设备的源地址（SourceAddress，SA）、激活类型（Activation Type）、保留给ISO 13400-2今后扩展使用的部分和可以主机厂自定义的部分。其有效载荷的格式如下图所示。

源地址（Source Address，SA）的类型为上文中描述的逻辑地址，此处源地址为路由激活报文发送方，也就是测试设备的逻辑地址，地址范围应遵守ISO13400-2：2019中的规定，用于标识该报文由哪个测试设备发出。

激活类型（Activation Type）用来指示不同的身份验证或确认路由激活的特定类型。具体来说分为默认激活模式、法规要求的诊断通信激活（例如全球调和车载诊断系统（WWH-OBD））和由主机厂定义的激活类型，如主机厂可能需要在路由激活过程中添加安全验证。

ISO保留部分为未来文档完善升级保留了空间，目前默认用0x00填充。

主机厂自定义部分非强制要求项（Mandatory），由企业根据自身需求决定是否在有效载荷中保留此项。

路由激活响应报文（0x0006）为对路由激活请求报文的响应，是在车内DoIP实体成功接收到路由激活请求报文，并通过一系列验证处理，允许车辆外部报文路由到车内之前发送的报文。其有效载荷的格式如下图所示。

测试设备地址（Logical Address Of Client DoIP Entity）和实体地址（LogicalAddress Of DoIP Entity）分别为测试设备与车内发送路由激活响应报文的DoIP实体的逻辑地址，车内进行路由激活响应的节点一般为车内的DoIP边缘接或车载网络各网段的入口节点。

响应代码（Response Code）为DoIP实体对路由请求报文的响应状态，如果车内节点拒绝路由激活请求，则通过该响应代码告知测试设备拒绝原因，成功的路由激活意味着接下来可以通过TCP_DATA路由诊断消息到车内网络。不同响应代码的含义在ISO13400-2：2019中有明确的规定，其中包含强制要求和主机厂可自定义部分。成功的路由激活是测试设备与车内DoIP实体进行诊断通信的前提。

ISO保留部分为未来文档完善升级保留了空间，目前默认用0x00填充。

OEM保留项为主机厂功能扩展使用，与路由请求中保留项一样，是可选项。

在完成车辆识别和路由激活后，诊断数据才能通过网络在车辆与测试设备之间传输，从诊断通信阶段才开始正式的诊断数据的交互。诊断通信报文因为其特定的格式，被允许路由（诊断请求）到车辆网络，并从车辆网络路由（诊断响应）回测试设备，DoIP实体对诊断请求的响应包括肯定响应和否定响应。但当车辆中的DoIP实体向测试设备发送诊断消息时，测试设备不应响应。值得注意的是，DoIP协议增加了对DoIP诊断报文响应，这一点需要与对DoIP上层的高层协议（如UDS协议）的响应区分开，对DoIP报文的响应，包含对逻辑地址、诊断数据长度等信息的响应，后文中会做详细介绍；对高层协议的响应（包括肯定响应和否定响应）被填充在诊断响应报文（DoIP报文）的有效载荷中。

诊断通信阶段的报文有4种，分别为诊断请求和诊断响应报文、DoIP报文ACK响应报文和DoIP报文NACK响应报文，其中诊断请求报文和诊断响应报文有效载荷的格式一致，用于承载高层协议的诊断数据（UDS诊断数据），且其报文类型标识符一致，都为0x8001；DoIP报文ACK响应报文和DoIP报文NACK响应报文结构相似，用于对DoIP报文的响应，响应过程不涉及高层协议，唯一的区别在于响应代码是ACK还是NACK。ACK代表肯定的响应，即当前DoIP报文可以通过检测，并能将高层协议的诊断数据传输到目标车内的DoIP实体进行处理；NACK代表否定响应，即当前DoIP报文的信息未通过检测，则高层协议的诊断数据无法被车内DoIP实体处理。

诊断请求（0x8001）和诊断响应（0x8001）报文有效载荷的格式如下图所示。

源逻辑地址（Source Address）和目标逻辑地址（Target Address）分别为测试设备和车内网络中目标DoIP实体的逻辑地址，用来标识发送方和接收方是否与路由激活阶段建立连接的一致。需要注意的是，不论当前报文为诊断请求还是诊断响应报文，其源逻辑地址都为测试设备的逻辑地址，目标逻辑地址都为车内网络中DoIP实体的逻辑地址。

用户数据（User Data）为高层协议的诊断数据内容（如ISO 14229-1中要求的诊断请求和诊断响应），高层协议的诊断请求和响应被将填充到“用户数据”中，随DoIP诊断通信报文的请求被路由到目标车内DoIP实体。如果网路中的诊断数据的目标节点是不支持DoIP协议的CAN节点，则数据应该通过支持DoIP协议的节点将接收到的用户数据通过CAN总线转发给目标CAN节点，并将CAN节点的诊断响应打包在DoIP报文中发送到网络中，如果其他种类的车载网络节点有同样的需求，也通过类似的方式实现诊断数据的转发。

DoIP报文ACK（0x8002）和NACK（0x8003）响应报文有效载荷的格式如下所示。

接收到以上两种DoIP报文的测试设备会根据有效载荷中ACK或NACK响应代码的含义进行下一步操作。两种响应代码的范围都是0x00至0xFF，其中，ACK代码的值为0x00时指示能够正确接收诊断报文，0x01到0xFF由ISO 13400-2:2019文档保留，暂时不开放使用；NACK代码比较多，不同的代码表示不能正确接收DoIP诊断请求报文的原因，下表展示了NACK代码的内容。