3、DoIP协议栈架构：OSI模型映射、协议分层与通信流程
好，咱们今天聊聊DoIP的骨架——协议栈架构。很多朋友刚开始接触DoIP时，容易把它当成“把UDS报文塞进TCP/IP里就完事了”。其实没那么简单。DoIP在OSI模型里的映射、UDP和TCP各自扮演的角色，以及整个逻辑通信流程，这里面有不少门道。
我个人习惯，看一个协议先看它“长在”网络模型的哪一层。DoIP虽然叫“基于IP的诊断”，但它不是纯应用层的东西，它横跨了传输层、网络层和应用层。
3.1 DoIP在OSI模型中的映射
先看这张映射图，我当年在项目里第一次看到这个分层时，第一反应是：“哦，原来物理层和链路层是借用以太网的。”
核心理解：DoIP没有重新定义物理层和数据链路层，它直接跑在标准以太网上。真正做文章的是网络层以上的部分。
从这张图能看出来，DoIP的应用层其实分了三块：消息处理、会话管理、以及最上层的UDS路由。为什么这么分？因为DoIP不仅要传诊断数据，还要管“谁可以连”、“连接怎么建立”、“消息怎么路由到目标ECU”。
3.2 DoIP协议栈分层详解
咱们把DoIP自己的那三层拆开看看。我建议你把它理解成“一个带门禁的快递分拣中心”。
| 分层 | 类比 | 核心职责 | 典型报文类型 |
|---|---|---|---|
| DoIP应用层 | 快递内容 | 封装UDS请求/响应，处理路由激活 | 诊断消息 (0x8001/0x8002) |
| DoIP消息层 | 快递单 | 定义消息头、负载类型、长度 | 通用DoIP头 (8字节) |
| DoIP会话层 | 门禁系统 | 连接管理、认证、保活 | 车辆识别、路由激活、AliveCheck |
我记得第一次调试DoIP时，抓包看到一堆0x0004、0x0005的报文，当时没仔细看会话层，结果死活连不上。后来才发现是路由激活那步没走对。嗯，这里要注意：会话层的状态机是DoIP通信的“总开关”。
我的经验：调试DoIP时，先看会话层状态。如果车辆没有回复路由激活响应（0x0005），后面的诊断消息发出去也是石沉大海。我习惯在测试脚本里加一个“等待路由激活确认”的断言。
3.3 TCP与UDP在DoIP中的角色
很多初学者会问：“为什么DoIP要用两个传输层协议？一个TCP不够吗？”
你想想看，诊断场景分两种：一种是“我要跟某个ECU建立稳定连接，慢慢聊”，另一种是“我要先找到车在哪，或者告诉全网我来了”。
TCP和UDP的分工，说白了就是：
- UDP（端口 13400）：用于车辆发现、节点通告、状态广播。不需要建立连接，发出去就行。丢了？没关系，多广播几次。
- TCP（端口 13400）：用于真正的诊断通信。必须建立连接，保证数据不丢、不乱序。丢了？TCP会重传。
我见过一个项目，工程师为了省事，把诊断消息也用UDP发。结果在强干扰环境下，诊断响应经常丢，ECU刷写一半就挂了。后来老老实实改回TCP，问题解决。
避坑指南：千万不要用UDP传输诊断请求/响应。ISO 13400明确规定了诊断消息必须走TCP。我曾经在某个原型车上看到有人用UDP传0x8001报文，结果车辆在高速移动时网络抖动，诊断会话频繁超时。UDP只适合做发现和通告。
具体到端口，DoIP固定使用UDP 13400和TCP 13400。为什么是13400？ISO标准定的，咱们记住就行。
3.4 逻辑通信流程
好，现在我们把整个流程串起来。一个完整的DoIP诊断会话，大致分五步。我画了个流程图，你跟着走一遍：
这五步里，最容易出问题的是第三步——路由激活。我遇到过好几次，测试仪发了路由激活请求，但车辆没回复。后来发现是车辆要求必须先通过某种认证（比如安全访问），否则拒绝激活。
关键点：路由激活成功后，车辆会分配一个逻辑地址给测试仪。这个地址在后续的诊断消息中会用到。如果路由激活失败，TCP连接虽然还在，但所有诊断消息都会被车辆忽略。
另外，断开连接这一步也别忽视。有些车辆在TCP连接断开后，会保持一段时间的“半开”状态。如果你立刻重连，可能会被拒绝。我建议在测试脚本里加一个2秒的等待，等车辆状态彻底复位。
好了，这一章的内容就是这些。DoIP的协议栈架构，说白了就是“UDP找车，TCP修车”。把这两条腿站住了，后面的细节就好理解了。