4. DoIP连接建立与维护：TCP连接建立、DoIP实体发现、路由激活过程、连接保活机制（AliveCheck）

好，咱们进入正题。这一章讲的是DoIP连接怎么建起来、怎么维持住。说白了，就是让智能驾驶域控制器和诊断仪之间「认识」并「保持通话」的全过程。我当年第一次调DoIP协议栈时，就在连接建立这块踩了不少坑，今天一并分享给你们。

4.1 TCP连接建立——先得「握手」

DoIP跑在TCP/IP之上，所以第一步肯定是TCP三次握手。这个大家都很熟了，但我还是啰嗦一句：DoIP默认使用端口13400，这是ISO 13400标准规定的。

诊断仪作为客户端，主动发起TCP连接。域控制器作为服务端，监听13400端口。握手完成后，TCP连接就建立了。嗯，这里要注意：TCP连接本身不携带任何DoIP协议信息，它只是提供了一个可靠的传输通道。

我在项目中遇到过一个问题：域控制器启动后，诊断仪连上来总是超时。查了半天，发现是TCP backlog设置太小，连接请求被内核丢弃了。你想想看，智能驾驶域控制器上可能同时有多个诊断仪尝试连接，backlog至少设到5以上才稳妥。

4.2 DoIP实体发现——谁在说话？

TCP连接建好了，接下来要做什么？诊断仪得知道对面是不是一个合法的DoIP实体。这就是实体发现（Entity Discovery）的活。

DoIP实体发现有两种方式：

• 主动广播：域控制器启动后，会往特定组播地址发送一个Vehicle Announcement消息。诊断仪收到后就知道「哦，这里有台车」。
• 被动查询：诊断仪也可以主动发送一个Vehicle Identification Request，域控制器收到后回复自己的信息。

我个人习惯用被动查询方式，因为主动广播在网络拥堵时容易丢包。有一次在实车测试中，诊断仪死活发现不了域控制器，后来发现是组播路由没配好。嗯，这个坑我替你们踩过了。

4.3 路由激活过程——拿到「通行证」

实体发现之后，诊断仪还不能直接发诊断请求。为什么？因为DoIP需要先做路由激活（Routing Activation）。说白了，就是让域控制器确认「你确实有权限访问我」。

路由激活的流程很简单：

1. 诊断仪发送Routing Activation Request，里面带上自己的逻辑地址和激活类型。
2. 域控制器检查这个逻辑地址是否合法、激活类型是否支持。
3. 如果一切OK，回复Routing Activation Response，状态码为0x10（成功）。
4. 从此，这个TCP连接就绑定了一个逻辑地址对（源地址+目标地址）。

这里有个细节：激活类型有几种，比如0x00（默认）、0x01（带证书的）。智能驾驶域控制器通常要求带证书激活，因为涉及功能安全。我建议你们在开发初期就把证书校验逻辑加上，不然后期加会很痛苦。

4.4 连接保活机制（AliveCheck）——别让连接「冷掉」

连接建立好了，路由也激活了，是不是就万事大吉了？不是。TCP连接可能因为网络波动、设备休眠等原因意外断开。诊断仪怎么知道连接还活着？这就需要AliveCheck机制。

AliveCheck的工作原理：

• 诊断仪定期发送AliveCheck Request（其实就是一个特殊的DoIP头部，payload为空）。
• 域控制器收到后，回复AliveCheck Response。
• 如果诊断仪连续几次没收到响应，就认为连接已断开，需要重新建立。

我记得标准里建议的间隔是5秒，但实际项目中我一般设成3秒。为什么？因为智能驾驶域控制器对实时性要求高，5秒的空窗期太长了。你想想看，如果刚好在车辆行驶中诊断连接断了，而工程师还以为是系统故障，那多尴尬。

另外，AliveCheck的报文非常小，只有8字节头部。所以不用担心带宽问题。但要注意：不要在AliveCheck期间发送诊断请求，否则可能造成报文交织，导致解析错误。我一般会在诊断请求发送后暂停AliveCheck，等响应回来再恢复。

4.5 总结一下我的经验

好了，这一章的内容就这些。我最后唠叨几句：

• TCP连接建立时，注意端口和backlog设置。
• 实体发现用被动查询更可靠。
• 路由激活失败一定要断开连接。
• AliveCheck的间隔和超时参数要结合实际环境调优。

这些看似基础的东西，恰恰是DoIP协议栈稳定性的基石。我在智能驾驶域控制器项目里，光是连接建立这块就迭代了三个版本。你们现在学这些，至少能少走我一半的弯路。下一章我们讲诊断消息的封装和解析，那个更有意思。