第4章 DoIP传输层机制：TCP与UDP的选择策略、端口号分配（13400）、连接管理状态机
各位工程师，咱们今天聊聊DoIP的传输层。说实话，这一块是很多人在实际项目中容易踩坑的地方。TCP和UDP怎么选？端口号为什么是13400？连接状态机到底怎么跑？我一个个给你讲透。
4.1 TCP与UDP的选择策略
DoIP协议在传输层同时支持TCP和UDP，但两者的分工非常明确。我个人习惯把UDP比作“广播员”，TCP比作“快递员”。
UDP的应用场景：
- 车辆发现：诊断仪发送广播请求，ECU回复“我在这里”。
- 车辆信息通告：ECU主动上报VIN、IP地址等基本信息。
- 简单状态查询：比如ping一下ECU是否在线。
TCP的应用场景：
- 诊断消息传输：UDS诊断请求/响应，必须可靠。
- 大数据传输：比如刷写ECU固件，动辄几十MB。
- 连接控制：路由激活、诊断会话控制等。
核心原则：UDP只管“发现”，TCP负责“干活”。
我在项目中遇到过一个问题：某次测试时，诊断仪发送UDP广播后，ECU回复了，但后续的TCP连接却一直建立不起来。排查了半天，发现是ECU的TCP端口被防火墙挡住了。嗯，这里要注意——UDP能通不代表TCP也能通。
4.2 端口号分配（13400）
DoIP协议规定使用端口号13400。为什么是13400？说实话，我也不知道ISO为什么选这个数字，但咱们记住就行。
端口使用规则：
| 协议 | 端口号 | 用途 |
|---|---|---|
| UDP | 13400 | 车辆发现、状态通告 |
| TCP | 13400 | 诊断消息、路由激活、数据交换 |
你可能会问：为什么TCP和UDP用同一个端口号？其实这是故意的。ECU只需要监听一个端口，简化了实现。诊断仪发送UDP广播时，目标端口是13400；建立TCP连接时，目标端口也是13400。ECU根据协议类型自动区分。
避坑指南：我曾经见过有人把UDP和TCP的端口号分开配置，结果ECU的UDP端口是13400，TCP端口却配成了13401。诊断仪死活连不上，查了三天才发现。记住，DoIP的端口号就是13400，别乱改。
4.3 连接管理状态机
DoIP的连接管理状态机，说白了就是ECU如何管理诊断连接的“生命周期”。我把它分为四个阶段：
- 监听状态（Listen）：ECU启动后，在13400端口上监听TCP连接请求。
- 连接建立（Connected）：诊断仪发起TCP连接，ECU接受后进入此状态。
- 路由激活（Routing Active）：诊断仪发送路由激活请求，ECU验证通过后激活路由。
- 诊断会话（Diagnostic Session）：路由激活后，可以进行UDS诊断通信。
状态机转换图大致如下：
Listen → TCP连接建立 → Connected → 路由激活 → Routing Active → 诊断请求 → Diagnostic Session
↓ ↓
超时/断开 超时/断开
↓ ↓
回到Listen 回到Listen这里有个关键点：路由激活是DoIP特有的机制。诊断仪必须先发送路由激活请求，ECU验证通过后，才会允许后续的诊断消息通过。为什么要多这一步？说白了是为了安全——防止未经授权的设备随意访问ECU。
注意事项：路由激活请求中包含了诊断仪的逻辑地址。ECU会检查这个地址是否合法。我曾经遇到一个案例，诊断仪发送的路由激活请求中逻辑地址填错了，ECU直接拒绝，连接一直卡在Connected状态。所以，逻辑地址一定要配对。
另外，连接管理状态机还涉及超时机制。ISO 13400-2规定了几个关键超时：
- TCP连接超时：默认30秒，超过后ECU会主动断开。
- 路由激活超时：默认5秒，诊断仪必须在5秒内发送路由激活请求。
- 诊断消息超时：默认2秒，ECU等待诊断请求的间隔。
你想想看，如果诊断仪发送路由激活请求后，ECU迟迟不回复，大概率是超时设置有问题。我建议你在开发阶段把这些超时参数打印出来，方便调试。
4.4 实际项目中的经验总结
最后，我分享几个实际项目中的经验：
- UDP广播不要发太频繁：有些诊断仪每秒发10次广播，ECU处理不过来，导致丢包。建议间隔1秒以上。
- TCP连接数有限：ECU资源有限，一般只支持1-2个并发TCP连接。诊断仪不要同时开太多连接。
- 状态机要记录日志：我习惯在ECU中记录连接状态机的转换日志，出问题时一看就知道卡在哪一步。
好了，这一章就讲到这里。下一章咱们聊聊DoIP的消息格式和头部结构，那个更精彩。