2、DoIP协议栈架构：DoIP实体结构、TCP与UDP端口分配、逻辑通信流程
好，咱们进入第二章。这一章我打算把DoIP的骨架给你拆开看看。
说白了，DoIP协议栈就是一套让车载ECU通过以太网跟外界对话的规矩。你想想看，一辆车上有几十上百个ECU，每个ECU都要能跟诊断仪通信，如果没有一套清晰的架构，那不乱套了？
我个人习惯，在讲任何协议之前，先看它的实体结构。就像盖房子，你得先知道有几根柱子、几面墙。
2.1 DoIP实体结构
一个完整的DoIP实体，在ISO 13400-2里定义得很清楚。我把它简化成三个核心模块：
- 应用层：负责处理诊断消息，比如UDS请求/响应。这一层不关心底层怎么传，只管把数据打包好。
- DoIP协议层：这是核心。它负责消息的封装、拆解、路由、流控制。嗯，这里要注意，DoIP协议层还管理着连接状态和车辆声明。
- 传输层：TCP和UDP。TCP负责可靠传输，UDP负责广播和发现。
我在项目中遇到过一个问题：某款ECU的DoIP实现，应用层和协议层之间的接口没处理好，导致高负载下消息丢失。后来查了半天，发现是缓冲区大小没对齐。所以啊，层与层之间的数据交互，一定要定义清楚。
核心要点：DoIP实体内部，每一层都有明确的职责。应用层只管“说什么”，协议层管“怎么说”，传输层管“怎么传”。千万别让应用层直接操作socket，那是灾难。
2.2 TCP与UDP端口分配
端口分配这事儿，看起来简单，但坑不少。ISO 13400-2规定得很死：
| 协议 | 端口号 | 用途 |
|---|---|---|
| UDP | 13400 | 车辆发现、车辆声明、路由激活 |
| TCP | 13400 | 诊断消息传输、流控制 |
你可能会问：为什么TCP和UDP都用同一个端口？
其实这是故意的。诊断仪只需要知道一个端口号，就能同时处理发现和诊断。但要注意，TCP和UDP是独立的协议栈，同一个端口号不会冲突。
我曾经踩过一个坑：某次测试，诊断仪一直发现不了车辆。查了半天，发现是ECU的UDP端口绑定错了，绑到了13401上。你说冤不冤？
避坑指南：UDP端口13400用于广播和组播，TCP端口13400用于点对点连接。千万不要把TCP的监听端口改成别的，否则诊断仪连不上。
2.3 逻辑通信流程
逻辑通信流程，说白了就是诊断仪和ECU之间怎么“握手”、“说话”、“再见”。我把它分成四个阶段：
- 车辆发现阶段：诊断仪发送UDP广播（Vehicle Identification Request），ECU回复（Vehicle Identification Response）。
- 连接建立阶段：诊断仪发起TCP连接，然后发送路由激活请求（Routing Activation Request），ECU回复路由激活响应。
- 诊断通信阶段：通过TCP传输诊断消息（UDS请求/响应）。
- 连接关闭阶段：诊断仪或ECU主动关闭TCP连接。
这里有个细节：路由激活请求里包含一个“激活类型”字段。我建议你仔细看看ISO 13400-2的表，不同的激活类型对应不同的安全级别。
举个例子，诊断仪发送路由激活请求：
// 路由激活请求报文示例（十六进制）
02 FD 00 05 00 00 00 01 00 00 00 00
// 解释：
// 02 FD - 协议版本
// 00 05 - 数据类型（路由激活）
// 00 00 00 01 - 激活类型（默认激活）
// 00 00 00 00 - 保留位
ECU收到后，会回复：
// 路由激活响应报文示例
02 FD 00 06 00 00 00 10 00 00 00 00
// 解释：
// 02 FD - 协议版本
// 00 06 - 数据类型（路由激活响应）
// 00 00 00 10 - 响应代码（成功）
// 00 00 00 00 - 保留位
你看，逻辑其实不复杂。但实际项目中，我见过很多问题出在“超时”上。比如诊断仪发送路由激活请求后，ECU迟迟不回复，诊断仪就傻等了。
我的经验：在实现DoIP客户端时，一定要给每个阶段设置超时。车辆发现阶段建议2秒，路由激活阶段建议5秒。超时后要主动重试，而不是一直阻塞。
嗯，这一章的内容差不多就这些。记住，DoIP协议栈的架构设计，核心就是“分层”和“端口固定”。你只要把这两点吃透了，后面讲延迟分析的时候，你就能知道瓶颈到底出在哪一层。
下一章，我会带你深入TCP连接的建立过程，以及那些让人头疼的流控制机制。到时候咱们再聊。