1. DoIP协议概述：背景、架构与角色

大家好，我是你们这门课的老朋友。今天咱们正式开篇，聊聊DoIP协议。

说实话，我第一次接触DoIP是在一个远程诊断的项目里。那时候客户要求用以太网替代传统的CAN诊断，我心想：这不就是把诊断数据塞进IP包吗？后来才发现，事情远没那么简单。

好，咱们不绕弯子，直接进入正题。

1.1 DoIP协议背景：为什么需要它？

先问大家一个问题：传统车载诊断用的是什么？

对，CAN总线。CAN诊断（UDS on CAN）在车上跑了二十多年，稳定可靠。但问题来了——

带宽不够。

CAN总线最高也就1Mbps，刷一个几十兆的固件，你得等半天。我记得有个项目，刷一个ECU要40分钟，工程师在车里都快睡着了。

还有，远程诊断怎么搞？

你想通过4G/5G远程给车刷软件，CAN报文怎么上云？总不能在服务器上挂个CAN卡吧？

所以，DoIP（Diagnostic over Internet Protocol）应运而生。说白了，就是把UDS诊断协议跑在以太网上。这样一来：

• 带宽飙升：100Mbps甚至1Gbps，刷固件从小时级降到分钟级
• 远程友好：IP网络天然支持远程通信，云端直接诊断
• 标准化：ISO 13400系列标准，全球统一

1.2 DoIP协议栈架构：分层看更清楚

DoIP的协议栈，我习惯从下往上分四层看。你想想看，就像盖房子，地基打不好，上层全白搭。

层级	协议/标准	主要功能
应用层	UDS (ISO 14229)	诊断服务（读取DTC、刷写、例程控制等）
传输层	DoIP (ISO 13400-2)	报文封装、路由激活、连接管理
网络层	TCP/UDP + IPv6/IPv4	可靠传输（TCP）与发现/心跳（UDP）
数据链路层	以太网 (100BASE-T1 / 1000BASE-T1)	物理传输、MAC地址、VLAN

嗯，这里要注意：DoIP的传输层不是TCP/IP的传输层，而是ISO 13400定义的逻辑传输层。它负责把UDS报文切成合适大小的块，再交给TCP去发。

我刚开始做DoIP开发时，就犯过一个低级错误——直接把UDS报文塞进TCP payload里，没加DoIP头部。结果测试仪死活不认。后来查标准才发现，每个DoIP报文前面都有个8字节的通用头部，里面包含了版本号、类型、长度等信息。

1.3 DoIP在车载网络中的角色

DoIP在车里到底扮演什么角色？我总结了三个关键词：

• 诊断入口：它是外部诊断仪（或云端）进入车载网络的统一门户
• 数据管道：负责把诊断请求路由到目标ECU，再把响应传回来
• 网关桥梁：连接以太网域和CAN/LIN域，实现跨网络诊断

你想想看，现在的车上有几十个ECU，有的在CAN总线上，有的在以太网上。DoIP网关就像个翻译官，把以太网上的诊断报文转成CAN报文，再转回来。

我记得有个项目，客户要求通过DoIP同时诊断三个不同网段的ECU。一开始我设计的是串行处理，结果发现响应时间超标。后来改成并行处理——每个网段分配一个独立的处理线程，才把性能提上来。

1.4 一个典型的DoIP通信场景

咱们来看个实际例子。假设你拿着诊断仪，要读取某个ECU的故障码：

1. 物理连接：诊断仪插到车载以太网接口（通常是OBD口的某对差分线）
2. IP配置：通过DHCP或链路本地地址获取IP（我习惯用链路本地，省去DHCP服务器依赖）
3. 车辆发现：诊断仪发送UDP广播，询问“车上有没有DoIP节点？”
4. 路由激活：找到节点后，发送TCP连接请求，然后进行路由激活（相当于“我要开始诊断了”）
5. 诊断通信：通过TCP发送UDS诊断请求，DoIP网关路由到目标ECU
6. 断开连接：诊断结束，发送关闭连接请求

整个过程，说白了就是“先找到人，再打招呼，然后办事，最后再见”。

1.5 小结与思考

这一章咱们把DoIP的来龙去脉理清楚了。总结一下：

• DoIP是为了解决CAN诊断带宽不足和远程诊断需求而生的
• 协议栈分四层，核心是ISO 13400定义的传输层
• DoIP在车里是诊断入口、数据管道和网关桥梁

下一章，咱们会深入DoIP的报文格式和状态机。到时候我会拿一个实际抓包的数据给大家分析，看看报文里每个字节到底是什么意思。

好，今天就到这儿。有什么问题，咱们课程群里聊。