第2章：以太网基础回顾：OSI七层模型、TCP/IP协议栈、MAC地址与IP地址、以太网帧结构

各位同学，欢迎来到第二章。

说实话，很多刚入行的工程师，一上来就扎进车载以太网的细节里，结果越学越懵。为什么？因为地基没打牢。今天这一章，咱们就把以太网最核心的基础知识过一遍。这些东西，我在项目里几乎天天都要跟它们打交道。

2.1 OSI七层模型：通信的“分层哲学”

先聊聊OSI七层模型。你想想看，两台设备要通信，中间要经历多少事？从你敲下键盘，到对方屏幕上显示出来，这中间涉及硬件、软件、协议……如果全揉在一起，谁也搞不定。

所以，聪明的前辈们想了个办法——分层。每一层只管自己的事，层与层之间通过接口交互。这就是OSI七层模型的核心思想。

我个人习惯，在调试车载网关时，脑子里始终要有一张“分层地图”。比如，当发现丢包时，我第一反应不是去查应用层代码，而是先看物理层有没有信号问题，再看链路层有没有CRC错误。一层一层排查，效率最高。

2.2 TCP/IP协议栈：实际工业界的“标准答案”

OSI模型是理论上的完美方案，但实际工业界用的是TCP/IP协议栈。它更精简，也更实用。

TCP/IP协议栈通常分为四层：

• 应用层：HTTP、FTP、以及车载专用的SOME/IP、DoIP、AVB等。
• 传输层：TCP（可靠、面向连接）和UDP（快速、无连接）。
• 网络层：IP协议，负责寻址和路由。
• 网络接口层：对应OSI的物理层和数据链路层。

我记得刚做车载网关时，遇到一个棘手的问题：摄像头数据流偶尔会卡顿。查了半天，发现是应用层用了TCP传输视频流。TCP的确认重传机制，在实时性要求高的场景下反而成了累赘。后来改成UDP，问题迎刃而解。

所以，选TCP还是UDP，不是拍脑袋决定的。你得看业务场景：

• 诊断数据、固件升级 → 用TCP，保证数据完整。
• 传感器数据、音视频流 → 用UDP，追求低延迟。

2.3 MAC地址与IP地址：设备的“身份证”与“门牌号”

这两个概念，很多新手容易搞混。我打个比方你就明白了：

• MAC地址：就像你的身份证号。全球唯一，出厂就烧录在网卡里，一般不改。
• IP地址：就像你家的门牌号。可以变，取决于你连到哪个网络。

在车载以太网里，MAC地址通常由芯片厂商分配，但整车厂有时会要求使用自己定义的MAC地址段，方便管理。IP地址则通过DHCP或者静态配置来分配。

你想想看，网关在转发数据时，是怎么知道要把数据发给谁的？它先看IP地址，找到目标网络；再看MAC地址，找到具体设备。这就是ARP协议干的事——把IP地址解析成MAC地址。

2.4 以太网帧结构：数据在线上到底长什么样？

好了，前面都是概念。现在咱们看看数据在网线上到底是怎么跑的。这就是以太网帧结构。

一个标准的以太网帧，长这样：

| 前导码(7B) | 帧起始定界符(1B) | 目标MAC(6B) | 源MAC(6B) | 类型/长度(2B) | 数据(46-1500B) | FCS(4B) |

我来拆解一下：

• 前导码 + 帧起始定界符： 物理层用的，告诉接收端“准备接收数据”。
• 目标MAC & 源MAC： 谁发给谁。
• 类型/长度： 如果值大于1536，表示上层协议类型（比如0x0800是IPv4，0x0806是ARP）。如果小于等于1500，表示数据长度。
• 数据： 真正的有效载荷。最小46字节，最大1500字节（MTU）。
• FCS： 帧校验序列，用CRC32算法计算。接收端算一遍，如果对不上，说明帧在传输中损坏了，直接丢弃。

我记得有一次，在调试车载网关的转发性能时，发现丢包率很高。用抓包工具一看，很多帧的FCS校验失败。最后定位到是PHY芯片的时钟抖动太大，导致数据在传输过程中出现了比特错误。嗯，这种问题，光看软件是看不出来的，必须结合硬件一起排查。

2.5 车载以太网的特殊之处

最后，咱们聊聊车载以太网和普通以太网的区别。毕竟，车规级的东西，要求不一样。

• 物理层不同： 车载以太网通常使用单对非屏蔽双绞线（100BASE-T1或1000BASE-T1），而不是标准的四对线。目的是减重、降成本。
• 实时性要求高： 普通以太网是“尽力而为”的，但车载网络里，刹车信号、转向信号必须实时到达。所以有了AVB/TSN这样的时间敏感网络技术。
• 诊断功能强： 车载以太网支持DoIP（基于IP的诊断协议），可以通过以太网进行远程诊断和刷写。

说白了，车载以太网就是在标准以太网的基础上，加了一层“车规级”的约束和增强。你掌握了标准以太网，再学车载以太网，就是水到渠成的事。

好了，这一章的内容就到这里。下一章，咱们开始真正进入车载以太网的世界，聊聊它的物理层——100BASE-T1和1000BASE-T1。到时候，我会结合我在项目里踩过的坑，给你讲透。