第2章：OSI模型与TCP/IP协议栈
各位同学，咱们今天聊聊网络通信的骨架——OSI模型和TCP/IP协议栈。说实话，我刚入行那会儿，觉得这些理论模型离实际工程很远。直到后来在项目里被一个物理层问题折腾了三天，才明白这些分层设计有多重要。
2.1 OSI七层模型：一个经典的参考框架
OSI模型，说白了就是国际标准化组织给网络通信画的一张「分层蓝图」。它把通信过程拆成七层，每层只管自己的事。我习惯把这七层记成一句话：「物、数、网、传、会、表、应」。
| 层级 | 名称 | 核心职责 | 汽车以太网中的角色 |
|---|---|---|---|
| 第7层 | 应用层 | 为用户提供网络服务 | SOME/IP、DoIP、AVB等协议 |
| 第6层 | 表示层 | 数据格式转换、加密 | 通常合并到应用层处理 |
| 第5层 | 会话层 | 建立、管理、终止会话 | 在车载中较少独立实现 |
| 第4层 | 传输层 | 端到端可靠传输 | TCP/UDP，DoIP依赖TCP |
| 第3层 | 网络层 | 路由选择、逻辑寻址 | IPv4/IPv6，网关路由 |
| 第2层 | 数据链路层 | 帧封装、MAC寻址、差错检测 | 以太网MAC、VLAN、AVB的FQTSS |
| 第1层 | 物理层 | 比特流传输、电气特性 | 100BASE-T1、1000BASE-T1 |
我的经验之谈：在实际车载项目中，我们很少严格按七层来开发。但遇到故障排查时，这个模型就是你的「故障定位地图」。我曾经遇到一个摄像头图像花屏的问题，从应用层一路查到物理层，最后发现是100BASE-T1的共模电感选型不对。
2.2 TCP/IP协议栈：汽车以太网的实战选择
OSI模型是理论上的「完美方案」，但实际工程中，我们用的是TCP/IP协议栈。它把七层压缩成了四层：应用层、传输层、网络层、网络接口层。
为什么会这样？你想想看，汽车电子开发讲究成本和效率。表示层和会话层的功能，在车载场景下要么用不到，要么直接合并到应用层里处理了。我个人习惯把TCP/IP协议栈在汽车以太网中的映射关系画成下面这张表：
| TCP/IP层级 | 对应OSI层级 | 汽车以太网典型协议 |
|---|---|---|
| 应用层 | 5~7层 | SOME/IP、DoIP、AVTP、HTTP |
| 传输层 | 第4层 | TCP（诊断）、UDP（音视频） |
| 网络层 | 第3层 | IPv4、IPv6、ICMP |
| 网络接口层 | 1~2层 | 100BASE-T1 MAC/PHY、AVB协议 |
2.3 物理层：信号从芯片到线束的第一步
物理层，说白了就是处理「0和1怎么变成电信号」的那一层。在汽车以太网里，这层和传统以太网差别最大。
传统以太网用RJ45连接器，四对差分线。汽车以太网呢？一对非屏蔽双绞线就够了。100BASE-T1就是典型代表，它只用一对线就能实现100Mbps全双工通信。
避坑指南：我曾经在项目里犯过一个低级错误——把100BASE-T1的PHY芯片和普通以太网PHY的PCB布局混用。结果信号完整性测试一塌糊涂。记住，汽车以太网PHY对PCB走线的阻抗匹配要求极高，差分阻抗必须控制在100Ω±10%。
2.4 数据链路层：MAC地址与帧的「交通规则」
数据链路层负责两件事：帧的封装和介质访问控制。在车载以太网中，这层有个特殊的地方——我们经常用到VLAN（虚拟局域网）。
为什么需要VLAN？你想想看，一辆车上可能有几十个ECU，ADAS系统的数据、娱乐系统的数据、诊断系统的数据都跑在同一根网线上。如果不做隔离，诊断流量堵了，摄像头的数据就传不过来了。
VLAN的802.1Q标签就是在以太网帧头里插入了4个字节的VLAN ID。我建议你在设计网络拓扑时，给不同功能域分配不同的VLAN ID：
- VLAN 10：ADAS与传感器域
- VLAN 20：信息娱乐域
- VLAN 30：车身控制域
- VLAN 100：诊断与OTA域
2.5 网络层：IP地址与路由的「导航系统」
网络层的核心是IP协议。在汽车以太网里，我们主要用IPv4，但IPv6也在慢慢渗透进来，尤其是需要海量地址的V2X场景。
这里有个关键点：车载网络中的IP地址分配。传统IT网络用DHCP自动分配，但在车上，很多ECU是静态IP。为什么？因为诊断工具需要知道每个ECU的固定地址。
注意：我曾经遇到一个项目，测试团队把某ECU的IP地址配成了和网关冲突的地址，结果整个网段的通信都瘫痪了。建议你在设计阶段就制定好IP地址分配表，并且用工具做冲突检测。
2.6 传输层：TCP的可靠与UDP的实时
传输层就两个主角：TCP和UDP。
TCP是面向连接的，保证数据不丢、不乱序。在车载里，诊断协议DoIP就依赖TCP。你想啊，诊断命令要是丢了一个字节，ECU可能就误解了指令，这后果很严重。
UDP是无连接的，速度快但不可靠。音视频流媒体传输就用UDP，因为偶尔丢一帧画面，人眼看不出来。但如果用TCP重传，延迟反而会让画面卡顿。
嗯，这里要注意：AVB协议栈在传输层做了增强，它用gPTP（广义精确时间协议）来同步时钟，用FQTSS来保证带宽预留。说白了，就是在UDP的基础上加了「服务质量保证」。
2.7 应用层：SOME/IP与DoIP的实战
应用层是离我们开发者最近的一层。在汽车以太网里，最常用的两个应用层协议是SOME/IP和DoIP。
SOME/IP是面向服务的通信协议。我习惯把它理解成「汽车界的RPC」。一个ECU可以提供服务（比如读取车速），另一个ECU可以远程调用这个服务。它的核心机制是：
- 服务发现：ECU启动时广播自己提供了哪些服务
- 远程过程调用：请求/响应模式
- 事件通知：服务端主动推送数据变化
DoIP则是诊断协议，它把UDS诊断报文封装在TCP/IP包里。这样，诊断仪就可以通过以太网远程诊断车辆，不用再拿着CAN诊断仪到处跑了。
我的建议：刚开始接触SOME/IP时，别急着写代码。先用Wireshark抓包看看服务发现的过程。我记得第一次看到SOME/IP的Service Discovery报文时，才真正理解了「面向服务」是什么意思。
2.8 小结：分层思维是解决问题的利器
回顾这一章，OSI模型给了我们一个「分层思考」的框架。TCP/IP协议栈则是这个框架在汽车以太网中的实战落地。
遇到网络问题时，我的排查思路永远是：先定位问题出在哪一层。物理层的问题看眼图、看信号质量；数据链路层的问题看MAC地址、看VLAN配置；网络层的问题看IP地址、看路由表；传输层的问题看端口号、看重传率；应用层的问题看协议报文、看服务状态。
下一章，我们会深入物理层，聊聊100BASE-T1和1000BASE-T1的硬件设计细节。到时候我会分享一些PCB布局的实战经验，保证让你少走弯路。