4、DoIP传输层协议：TCP与UDP在DoIP中的应用场景
聊到DoIP的传输层，很多人第一反应就是端口13400。嗯，没错，TCP和UDP都用这个端口。但为什么同一个端口要跑两种协议？它们各自负责什么？我刚开始接触DoIP时也困惑过。
说白了，DoIP的设计者把任务分得很清楚：UDP负责发现和轻量通信，TCP负责可靠的大数据交换。你想想看，一个诊断工程师在车间里拿着笔记本，第一件事是什么？肯定是先找到车上的ECU。这时候UDP就派上用场了。
4.1 UDP在DoIP中的应用场景
UDP在DoIP里主要干三件事：
- 车辆发现：客户端发个广播，问「谁在车上？」
- 车辆声明：ECU回应「我在这里，这是我的信息」
- 诊断仪激活：确认诊断会话的建立
我个人习惯把UDP比作「敲门」——先确认门后面有人，再决定要不要进去聊。UDP报文结构很简单，没有握手、没有重传，发出去就不管了。这在车辆发现阶段特别合适，因为这时候你根本不知道目标在哪。
核心要点：UDP在DoIP中只用于控制面，不传输诊断数据。诊断数据必须走TCP。
我记得有一次在项目现场，客户抱怨说诊断仪连不上ECU。我抓了个包一看，UDP广播发出去后，ECU根本没回应。后来发现是网关配置把UDP广播给过滤了。嗯，这种坑踩过一次就记住了。
4.2 TCP在DoIP中的应用场景
TCP才是DoIP真正干活的协议。诊断请求、诊断响应、大数据传输，全走TCP。为什么？因为诊断数据不能丢，不能乱序。
TCP在DoIP里负责：
- 诊断消息传输：UDS请求/响应
- 大数据分包传输：比如刷写ECU固件
- 连接管理：建立、维持、关闭诊断会话
你想想看，刷写一个ECU可能要传几MB的数据。如果走UDP，丢一个包就得整个重来，那效率太低了。TCP的三次握手、确认重传、流量控制，说白了就是为这种场景量身定做的。
实战技巧：抓包时注意TCP的窗口大小。如果窗口突然变成0，说明接收方处理不过来了。我曾经遇到过ECU的接收缓冲区太小，导致刷写速度上不去，最后调整了TCP窗口才解决。
4.3 DoIP的TCP端口与UDP端口（13400）
端口13400是IANA分配给DoIP的官方端口。TCP和UDP都用这个端口，但用途完全不同：
| 协议 | 端口 | 用途 | 可靠性 |
|---|---|---|---|
| UDP | 13400 | 车辆发现、声明、激活 | 无 |
| TCP | 13400 | 诊断消息传输、大数据交换 | 有 |
为什么用同一个端口？因为ECU只需要监听一个端口，简化了实现。客户端发UDP广播时，目标端口是13400；建立TCP连接时，目标端口也是13400。ECU根据IP头里的协议字段区分是UDP还是TCP。
注意：有些防火墙会默认屏蔽13400端口。部署DoIP系统时，一定要确认网络设备没有拦截这个端口。我曾经在客户现场排查了一整天，最后发现是交换机ACL把13400给封了。
4.4 DoIP的传输层可靠性机制
DoIP本身不提供传输层可靠性——它把这件事交给了TCP。但DoIP在应用层做了一些补充：
- 超时重传：发送诊断请求后，如果超过一定时间没收到响应，应用层会重发
- 序列号校验：DoIP报文头里有协议版本和负载类型，接收方会校验这些字段
- 连接状态机：DoIP定义了完整的连接建立和关闭流程
说白了，DoIP的可靠性是分层实现的：TCP保证数据不丢不乱，DoIP保证语义正确。举个例子，TCP可能把两个诊断请求合并成一个包发出去，但DoIP的报文头能让接收方准确拆分。
我建议你在抓包时重点关注TCP的重传和重复ACK。如果看到大量重传，说明网络质量有问题。如果看到重复ACK，可能是ECU处理太慢。这些细节在诊断故障时特别有用。
避坑指南：我曾经遇到一个案例，诊断仪发请求后ECU没响应。抓包发现TCP连接正常，请求也发过去了，但ECU就是不回。后来发现是ECU的DoIP状态机卡在了某个状态，需要发送一个特定的控制报文才能恢复。嗯，这种问题光看TCP层是看不出来的，必须结合DoIP应用层分析。
4.5 本章知识体系
下面这张图总结了DoIP传输层的核心逻辑：
从这张图可以看得很清楚：UDP和TCP共享同一个端口13400，但分工完全不同。UDP在上层，负责轻量级的控制通信；TCP在下层，负责可靠的数据传输。两者通过IP层的协议字段区分。
好了，这一章的内容就到这里。记住一句话：UDP敲门，TCP干活。搞清楚了这一点，DoIP的传输层你就掌握了八成。
个人建议：刚开始学DoIP抓包时，先过滤UDP的13400端口，看看车辆发现的过程。然后再过滤TCP的13400端口，看看诊断会话的建立。这样分开看，思路会清晰很多。