2、DoIP协议栈架构：物理层、传输层、网络层、会话层、应用层详解
各位工程师朋友，咱们今天来聊聊DoIP的协议栈。说白了，DoIP就是把UDS诊断报文，塞进以太网的“信封”里发出去。但这个过程不是简单粗暴地往里一扔，而是分了好几层，各司其职。
我刚开始接触DoIP时，也觉得分层很抽象。后来在调试一个OBD（车载诊断系统）远程刷写项目时，遇到个奇怪问题：诊断仪能连上ECU（电子控制单元），但一执行刷写就超时。查了三天，最后发现是传输层窗口大小没配好。嗯，从那以后，我对协议栈的每一层都格外上心。
今天咱们就一层层剥开来看。你想想看，数据从诊断仪发出去，到ECU收到，中间经历了什么？
2.1 物理层：信号的基础
物理层，说白了就是网线和接口。DoIP通常跑在100BASE-TX（百兆以太网）或1000BASE-T（千兆以太网）上。现在新车基本都支持千兆了，但老车型可能还是百兆。
关键点：
- 连接器： 标准RJ45接口，但车载环境会用更坚固的H-MTD或MATEnet连接器。我个人习惯在测试时，先检查一下接口有没有松动，很多奇怪问题都是接触不良引起的。
- 线缆： 要求至少CAT5e（超五类）以上。我曾经在实验室用一根劣质网线，结果丢包率高达10%，换了根屏蔽线立马正常。
- 电气特性： 车载环境有严格的EMC（电磁兼容性）要求，所以物理层芯片通常要符合AEC-Q100（车规级芯片认证）标准。
2.2 传输层：TCP与UDP的选择
传输层主要用两个协议：TCP和UDP。为什么需要两个？因为用途不同。
| 特性 | TCP | UDP |
|---|---|---|
| 可靠性 | 可靠，有重传机制 | 不可靠，无重传 |
| 连接性 | 面向连接 | 无连接 |
| 用途 | 诊断数据（如刷写、读取故障码） | 发现车辆、状态通知 |
| 端口 | 13400（DoIP默认） | 13400（与TCP共用） |
避坑指南： 我曾经在调试时，发现UDP的车辆公告消息收不到。查了半天，原来是防火墙把UDP广播包给拦了。所以，记得检查一下网络设备的防火墙规则。
2.3 网络层：IP地址与路由
网络层就是IP协议。DoIP设备通常使用IPv4，但新标准也开始支持IPv6了。
关键点：
- IP地址分配： 诊断仪和ECU通常通过DHCP（动态主机配置协议）获取地址，或者用Auto-IP（自动私有IP地址）在无DHCP服务器时自动分配。我建议在测试时，先确认一下IP地址是否在同一个子网内。
- 路由： 如果诊断仪和ECU不在同一个网段，就需要路由器转发。但DoIP通常设计为直连，避免路由带来的延迟和丢包。
- VLAN（虚拟局域网）： 有些车载网络会划分VLAN，把诊断流量和其他数据隔离开。嗯，这里要注意，如果VLAN没配好，诊断仪可能根本找不到ECU。
2.4 会话层：连接管理与状态机
会话层负责管理诊断会话。DoIP的会话层其实很简单，就是三个状态：
- 未连接： 初始状态，啥也不干。
- 已连接： TCP连接建立后，进入此状态。可以发送诊断请求了。
- 已激活： 收到有效的诊断请求后，进入激活状态。此时可以进行刷写等高级操作。
我遇到过的问题： 有一次，诊断仪发送了请求，但ECU一直不响应。抓包一看，发现ECU的会话层状态机卡在了“未连接”状态。原因是TCP连接虽然建立了，但ECU没有收到有效的DoIP激活报文。所以，记得检查一下激活报文的格式。
2.5 应用层：UDS诊断协议
应用层就是咱们熟悉的UDS（统一诊断服务）协议。DoIP只是把UDS报文封装在以太网帧里，但UDS本身的内容不变。
常见的UDS服务：
- 0x10： 诊断会话控制（切换会话模式）
- 0x22： 读取数据标识符（读DID）
- 0x2E： 写入数据标识符（写DID）
- 0x31： 例程控制（执行特定功能）
- 0x34/0x36： 请求下载/数据传输（刷写用）
代码示例： 一个简单的DoIP诊断请求（读取VIN码）：
// 构建DoIP头部
uint8_t doip_header[] = {
0x02, 0xFD, // 协议版本（ISO 13400-2）
0x80, 0x01, // 负载类型（诊断请求）
0x00, 0x00, 0x00, 0x04 // 负载长度（4字节）
};
// 构建UDS请求（0x22读取VIN）
uint8_t uds_request[] = {
0x22, // 服务ID
0xF1, 0x90 // DID（VIN码标识符）
};
// 发送数据
send(doip_header, sizeof(doip_header));
send(uds_request, sizeof(uds_request));2.6 各层之间的交互
你想想看，数据从诊断仪发出，到ECU收到，流程是这样的：
- 应用层： 生成UDS请求（如读取故障码）。
- 会话层： 检查当前会话状态，如果未激活，则先发送激活报文。
- 传输层： 将UDS报文封装成TCP段，加上端口号。
- 网络层： 加上IP头部，包含源和目标IP地址。
- 物理层： 转换成电信号，通过网线发送出去。
ECU收到后，反向解析，最终把UDS请求交给应用层处理。
避坑指南： 我曾经遇到一个案例，诊断仪发送的UDS请求长度超过了TCP的MSS（最大分段大小），导致数据被分片。ECU收到后无法正确重组，直接丢弃了。所以，记得控制一下诊断报文的大小，或者启用TCP的Nagle算法来优化。
2.7 总结
好了，咱们把DoIP协议栈的五层都过了一遍。说白了，每一层都有自己的“规矩”，你遵守了，诊断就顺畅；你不遵守，就等着抓包排查吧。
我个人习惯在调试时，先用Wireshark抓一下物理层的信号，看看有没有CRC（循环冗余校验）错误。然后检查TCP连接是否建立，再确认UDP广播是否正常。最后才看UDS报文的内容。这样一层层排查，效率最高。
下一章，咱们会聊聊DoIP的车辆发现机制，也就是诊断仪怎么找到车上的ECU。到时候再细聊。