第2章：DoIP协议栈架构：物理层、数据链路层、网络层、传输层、应用层分层解析
好，咱们直接切入正题。DoIP协议栈，说白了就是一套让诊断数据在以太网上跑起来的规矩。我刚开始接触的时候，也觉得这玩意儿分层太多，有点绕。但你真正在项目里调过几次报文，就会发现——每一层都有它存在的道理，少一层都玩不转。
这一章，我带你一层一层往下扒。从最底下的物理层，一直看到最上面的应用层。嗯，咱们按顺序来。
2.1 物理层：信号得先能传出去
物理层是基础。没有它，一切都是空谈。DoIP通常跑在100BASE-TX（百兆）或者1000BASE-T（千兆）以太网上。我个人习惯在项目初期就定好物理层方案，因为这会直接影响线束成本和EMC表现。
关键参数一览：
- 传输介质：双绞线（UTP/STP），车载环境建议用STP，抗干扰好一些
- 连接器：标准RJ45，或者车载专用的H-MTD、MATEnet
- 速率：100Mbps起步，新项目很多已经上1Gbps了
- 最大距离：15米以内（车内完全够用）
我的经验： 曾经有个项目，台架上怎么测都OK，一上车就丢包。查了三天，最后发现是线束供应商把双绞线的绞距搞错了。物理层这东西，看着简单，但细节真能坑死人。
2.2 数据链路层：MAC地址和帧结构
数据链路层负责把物理层收到的比特流，组装成帧。DoIP在这里主要依赖以太网MAC层。你想想看，车上那么多ECU，每个都得有个唯一的MAC地址，不然数据该发给谁？
DoIP的以太网帧结构，和标准以太网基本一致：
| 前导码 | 目标MAC | 源MAC | EtherType | 数据 | FCS |
| 8字节 | 6字节 | 6字节 | 2字节 | 46-1500字节 | 4字节 |这里有个关键点：EtherType字段。DoIP使用的EtherType是0x0800（IPv4）或者0x86DD（IPv6）。说白了，DoIP并不直接在MAC层上跑，它还是依赖IP网络的。
注意： 车载网络里，MAC地址冲突是个很隐蔽的问题。我曾经遇到过两个ECU用了同一个MAC地址，结果诊断仪死活连不上其中一个。排查起来特别痛苦，因为链路层根本不报错，只是数据莫名其妙丢了。
2.3 网络层：IP地址和路由
到了网络层，事情开始变得有意思了。DoIP使用标准的IPv4或IPv6协议。我个人更推荐IPv4，因为目前车载环境里IPv6的生态还不够成熟，很多诊断工具对IPv6的支持有坑。
网络层要解决两个核心问题：
- 寻址： 每个DoIP实体（ECU）必须有一个唯一的IP地址
- 路由： 诊断仪发出的报文，怎么找到目标ECU
DoIP定义了一个特殊的地址分配机制——DoIP实体IP地址分配。通常有两种方式：
- 静态分配： 出厂前写死，简单但不够灵活
- 动态分配（DHCP）： 上电后自动获取，我更喜欢这种方式，方便产线调试
避坑指南： 我曾经在一个项目里用了静态IP，结果后期要增加一个ECU，发现IP段不够用了。改起来牵一发动全身，特别麻烦。所以，除非你有非常明确的理由，否则建议上DHCP。
2.4 传输层：TCP和UDP的选择
传输层是DoIP协议栈里最需要动脑子的一层。DoIP同时支持TCP和UDP，但它们的用途完全不同。
| 协议 | 端口 | 用途 | 特点 |
|---|---|---|---|
| UDP | 13400 | 车辆发现、节点公告 | 无连接、速度快、不保证可靠 |
| TCP | 13400 | 诊断数据交换 | 面向连接、可靠传输、有重传机制 |
你想想看，为什么车辆发现要用UDP？因为诊断仪刚上车时，根本不知道有哪些ECU在线。它需要广播一个请求，所有ECU都得响应。如果用TCP，得先建立连接，那发现过程就变得又慢又复杂。
而诊断数据交换为什么用TCP？说白了，诊断报文丢不得。一条UDS指令发出去，如果因为网络拥塞丢了，ECU没收到，那诊断仪就得傻等超时。TCP的重传机制能保证数据一定到达。
我的习惯： 在实现DoIP协议栈时，我会把UDP和TCP的接收线程分开。UDP线程只处理广播和公告，优先级设低一点；TCP线程处理诊断数据，优先级拉满。这样能避免诊断数据被车辆发现报文干扰。
2.5 应用层：DoIP消息和UDS的融合
终于到了应用层。这里跑的是DoIP自己的协议消息，以及上层封装的UDS诊断服务。
DoIP应用层消息的通用格式是这样的：
| 协议版本 | 反向协议版本 | 负载类型 | 负载长度 | 负载数据 |
| 1字节 | 1字节 | 2字节 | 4字节 | 可变长度 |负载类型（Payload Type）决定了这条消息是干什么的。常见的类型有：
0x0001：车辆识别请求/响应0x0002：车辆识别（VIN）请求/响应0x0003：诊断电源模式请求/响应0x8001：诊断消息（UDS数据就封装在这里面）
嗯，这里要注意：0x8001才是真正干活的消息。UDS的请求和响应，都作为负载数据塞在DoIP消息里。说白了，DoIP就是个搬运工，把UDS报文从诊断仪搬到ECU，再把响应搬回来。
实战经验： 我调试过一个项目，诊断仪发出去的UDS请求，ECU死活不响应。抓包一看，DoIP消息的负载类型写成了0x0001（车辆识别），而不是0x8001（诊断消息）。ECU收到后，以为你在问它叫什么名字，自然不会执行诊断服务。这种低级错误，排查起来最浪费时间。
2.6 各层之间的协作：一个完整的诊断流程
光讲分层有点干巴巴的，咱们走一遍完整的流程，你就全明白了。
假设诊断仪要读取ECU的故障码：
- 物理层： 诊断仪插上OBD接口，网线连通，电平信号建立
- 数据链路层： 诊断仪和ECU的MAC地址被识别，帧开始传输
- 网络层： 诊断仪通过DHCP获取IP地址，ECU也有自己的IP，路由可达
- 传输层： 诊断仪向ECU的13400端口发起TCP连接，三次握手完成
- 应用层： 诊断仪封装一个
0x8001类型的DoIP消息，里面塞着UDS的0x19 0x01（读取故障码）请求 - ECU收到后，解析DoIP消息，提取UDS请求，执行诊断服务，再原路返回响应
你看，每一层各司其职，缺一不可。哪一层出了问题，诊断就卡在哪一层。
最后提醒一句： 很多工程师在调试DoIP时，习惯直接抓应用层的包。但我建议你，遇到问题先从物理层查起。我曾经花了一整天调应用层代码，最后发现是网线接触不良。嗯，这种教训，一次就够了。