3、DoIP网络层：IPv4与IPv6在DoIP中的应用、DoIP端口号与套接字、DoIP报文格式详解
好，咱们进入第三章节。网络层这块，说白了就是DoIP协议在互联网上跑的基础设施。你想想看，没有IP地址和端口，诊断仪和ECU怎么找到对方？就像寄快递，没有门牌号和收件人姓名，快递员只能干瞪眼。
我个人习惯把网络层比作「高速公路」，IPv4和IPv6就是两种不同规格的车道。而端口号，就是高速路上的出口编号。报文格式呢，就是跑在路上的车必须遵守的交通规则。咱们一个一个聊。
IPv4与IPv6在DoIP中的应用
DoIP协议设计之初就考虑了对两种IP版本的支持。为什么？因为汽车行业更新换代慢，IPv4的设备还在大量服役，而新车型已经开始拥抱IPv6了。
IPv4在DoIP中的表现
IPv4地址是32位的，写成四个十进制数，比如192.168.1.100。DoIP在IPv4环境下，主要靠广播或组播来发现车辆。我记得在早期的一个项目中，客户要求必须兼容IPv4，因为他们的车间网络还是老旧的C类地址段。
这里有个坑——IPv4的广播域有限。我曾经在一条总线上挂了几十台ECU，结果广播报文一多，网络直接卡死。后来我强制要求所有DoIP节点必须支持组播（地址224.0.0.180），才把问题解决。
IPv6在DoIP中的优势
IPv6地址128位，地址空间大到离谱。DoIP在IPv6下，车辆发现机制更优雅——使用链路本地地址（FE80::/10）和组播。你想想看，每个ECU都能自动生成一个唯一的链路本地地址，省去了DHCP的麻烦。
我个人更偏爱IPv6，原因很简单：
- 自动配置：无状态地址自动配置（SLAAC），插上网线就能用
- 安全性：IPsec是IPv6的原生特性，DoIP的安全认证可以省不少事
- 组播效率：IPv6的组播范围控制更精细，不会像IPv4那样广播风暴
重要提示：DoIP规范要求，一个DoIP实体必须同时支持IPv4和IPv6。但在实际项目中，我建议优先测试IPv6链路，因为它的地址分配更可靠，不容易出现地址冲突。
DoIP端口号与套接字
端口号，就是网络层的「门牌号」。DoIP固定使用两个端口：
| 端口号 | 协议 | 用途 |
|---|---|---|
| 13400 | TCP | DoIP数据连接（诊断通信） |
| 13400 | UDP | DoIP车辆发现/公告 |
嗯，这里要注意。TCP和UDP用的是同一个端口号13400，但用途完全不同。UDP负责「喊话」——车辆发现和公告。TCP负责「对话」——真正的诊断数据交换。
套接字（Socket）的生命周期
我在项目中遇到过一个问题：测试人员发现诊断仪连上ECU后，过几分钟就断开了。查了半天，原来是ECU的TCP套接字超时时间设置得太短。DoIP规范建议的默认超时是5秒，但实际项目中，我一般会设置成30秒，给诊断仪留足处理时间。
套接字的状态机其实不复杂：
- 监听状态：ECU在13400端口上等待连接
- 建立连接：诊断仪发起TCP三次握手
- 数据交换：双方通过这个套接字收发DoIP报文
- 关闭连接：诊断完成，或者超时断开
实战技巧：在嵌入式系统中，套接字资源很宝贵。我建议每个ECU最多同时维护4个TCP连接。超过这个数，直接拒绝新连接，并返回「资源不可用」的响应码。
DoIP报文格式详解
DoIP报文，说白了就是一层一层的「信封」。咱们从外到内拆开看。
报文头部结构
所有DoIP报文都遵循统一的头部格式，共8个字节：
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| 协议版本 | 1 | 当前固定为0x02（ISO 13400-2:2012） |
| 反向协议版本 | 1 | 必须等于协议版本，用于校验 |
| 负载类型 | 2 | 标识报文的具体用途（见下表） |
| 负载长度 | 4 | 后续负载数据的字节数（不含头部） |
负载类型详解
负载类型是DoIP报文的核心，它告诉接收方「这包数据是干嘛的」。常见的类型码：
| 类型码（十六进制） | 名称 | 方向 |
|---|---|---|
| 0x0001 | 车辆识别请求 | 诊断仪 → ECU |
| 0x0002 | 车辆识别响应 | ECU → 诊断仪 |
| 0x0003 | 路由激活请求 | 诊断仪 → ECU |
| 0x0004 | 路由激活响应 | ECU → 诊断仪 |
| 0x8001 | 诊断消息（UDS） | 双向 |
我个人习惯把0x0001到0x0004叫做「握手报文」，0x8001才是真正的「干活报文」。你想想看，没有握手确认，谁敢直接发诊断数据？
一个完整的报文示例
假设诊断仪要发送一个UDS诊断请求（读取ECU的VIN码）：
// DoIP头部（8字节）
02 02 80 01 00 00 00 08
// 解释：
// 02 - 协议版本
// 02 - 反向协议版本
// 80 01 - 负载类型（诊断消息）
// 00 00 00 08 - 负载长度（8字节）
// 负载部分（8字节）
// 这里包含UDS请求：22 F1 90（读取VIN码的UDS服务）
// 加上DoIP的源地址和目标地址等信息
// 实际负载内容根据具体实现而定避坑指南：我曾经在调试时发现，ECU总是回复「未知负载类型」。查了两天，结果是协议版本字段写成了0x01。记住，ISO 13400-2:2012要求协议版本必须是0x02。反向协议版本也必须和协议版本一致，否则ECU会直接丢弃报文。
报文分片与重组
DoIP报文最大支持4GB的负载长度（32位长度字段）。但实际网络中，TCP/IP层会做分片。我建议你在应用层控制单个报文不超过64KB，否则在低速链路上容易超时。
嗯，这里有个小技巧。如果你要发送一个很大的诊断数据（比如刷写固件），最好分成多个DoIP报文发送。每个报文独立编号，接收方按顺序重组。我在一个刷写项目中，把固件分成1KB一个的块，配合流控制，成功率从70%提升到了99.9%。
好了，网络层的内容就这些。下一章咱们聊传输层——TCP和UDP在DoIP中的具体玩法，以及那个让人头疼的「路由激活」流程。
本章小结：IPv4和IPv6的选择取决于项目需求，但建议优先支持IPv6。端口13400是DoIP的「命门」，TCP和UDP各司其职。报文格式记住8字节头部+负载的结构，负载类型是区分报文用途的关键。
公众号:蓝海资料掘金营，微信deep3321