3、链路层与MAC：MAC地址与帧结构、VLAN标签（802.1Q）在车内的应用、MAC安全（MACsec）基础
各位同学，咱们今天聊聊链路层。说实话，很多做上层应用的朋友觉得链路层就是「搬砖」的，没什么技术含量。但我在车载领域摸爬滚打这些年，发现恰恰是这层最容易出问题。你想想看，物理层把比特流传上来了，链路层要是处理不好，上层再好的协议也是白搭。
3.1 MAC地址与帧结构——别小看这48位
MAC地址，48位，6个字节。听起来简单吧？但我在项目里见过太多因为MAC地址配置出问题导致的通信故障。
先看一个标准的以太网帧结构：
+----------------+----------------+----------------+----------------+----------------+----------------+
| 前导码(7B) | SFD(1B) | 目的MAC(6B) | 源MAC(6B) | 类型/长度(2B) | 数据(46-1500B) |
+----------------+----------------+----------------+----------------+----------------+----------------+
| FCS(4B) |
+----------------+这里我要强调几个关键点：
- 前导码和SFD：这是物理层的事，但链路层得知道它们存在。我调试时经常用抓包工具看这些字段，能快速定位同步问题。
- 目的MAC和源MAC：48位，前24位是OUI（组织唯一标识符），后24位是厂商分配的。车载场景下，我建议用私有OUI，避免冲突。
- 类型/长度字段：大于1536表示类型（如0x0800是IPv4），小于等于1500表示长度。这个设计挺巧妙的，但容易混淆。
重要提醒：车载以太网帧最小46字节，最大1500字节。如果上层数据不够46字节，需要填充。我曾经遇到过一个ECU发送的UDP包只有20字节，结果填充了26个0，接收端解析时没处理好，导致数据错位。嗯，这个坑我踩过。
3.2 VLAN标签（802.1Q）在车内的应用——隔离的艺术
为什么车内要用VLAN？说白了，就是隔离。你想想看，一辆车上可能有几十个ECU，ADAS的数据流、娱乐系统的视频流、控制指令的实时流，全混在一起？那不乱套了。
802.1Q标签长这样：
+----------------+----------------+----------------+----------------+
| TPID(2B) | PCP(3bit) | DEI(1bit) | VID(12bit) |
| 0x8100 | 优先级 | 丢弃指示 | VLAN ID |
+----------------+----------------+----------------+----------------+我在实际项目中，一般这样划分VLAN：
| VLAN ID | 用途 | 优先级(PCP) | 典型延迟要求 |
|---|---|---|---|
| 1 | 控制指令（制动、转向） | 7（最高） | <1ms |
| 10 | ADAS传感器数据 | 6 | <10ms |
| 20 | 娱乐系统视频流 | 4 | <50ms |
| 100 | 诊断与OTA | 2 | 可容忍延迟 |
我个人习惯把控制指令放在VLAN 1，优先级最高。为什么？因为制动指令晚到1ms，可能就是一场事故。我曾经在测试中发现，如果不做VLAN隔离，娱乐系统的大流量数据会把控制指令的延迟拉到5ms以上——这绝对不可接受。
实战技巧：802.1Q标签会增加4字节，这会改变帧的最小长度计算。如果你的交换机或PHY不支持巨帧（Jumbo Frame），注意MTU设置。我一般把MTU设为1522字节（1500+4+18），留点余量。
3.3 MAC安全（MACsec）基础——别让黑客钻了空子
说到安全，很多人第一反应是IPsec或TLS。但你想过没有，如果链路层本身就不安全，上层再加密也没用。MACsec（802.1AE）就是在MAC层提供加密和完整性校验。
MACsec的核心机制：
- 加密：使用GCM-AES-128/256，对数据部分加密
- 完整性：每个帧都带ICV（完整性校验值），防止篡改
- 重放保护：使用包序号（PN），防止重放攻击
MACsec帧结构变化：
+----------------+----------------+----------------+----------------+----------------+
| 标准以太网头 | MACsec SecTAG | 加密数据 | ICV(8/16B) | 原FCS |
| (14B) | (8-16B) | (可变) | | (4B) |
+----------------+----------------+----------------+----------------+----------------+这里要注意，MACsec会增加8-20字节的开销。我在做ADAS系统时，曾经因为没算这个开销，导致某些关键帧超过了MTU限制，被分片了。分片后的帧在接收端重组失败，整个数据流都断了。嗯，那次排查花了我整整两天。
避坑指南：我曾经在某个项目中，把MACsec的密钥直接硬编码在代码里。结果测试时发现，只要换一块ECU板子，密钥就得重新烧录。后来我改用基于802.1X的密钥协商，虽然复杂了点，但可维护性好了很多。记住：车载环境下的密钥管理，一定要考虑产线和售后场景。
MACsec在车内的典型应用场景：
- 网关到域控制器：保护跨域通信，防止一个域被攻破后横向扩散
- OTA升级通道：确保固件包在传输过程中不被篡改
- 诊断接口：防止通过OBD口注入恶意数据
说实话，MACsec的开销确实不小。我做过测试，开启MACsec后，吞吐量会下降10%-15%，延迟增加20-50微秒。对于大多数车载应用来说，这个代价是值得的。但如果你在做毫秒级的控制环路，就得仔细评估了。
总结一下：链路层不是简单的「搬砖」，MAC地址配置、VLAN划分、MACsec部署，每一个细节都直接影响整车的通信质量和安全。我见过太多项目，因为链路层没做好，导致上层应用怎么优化都达不到效果。记住：基础不牢，地动山摇。
下一章咱们聊聊网络层和传输层，看看IP和UDP/TCP在车载场景下有哪些坑。到时候我会分享一个关于DoIP协议栈调试的真实案例，保证让你有所收获。