物理层与数据链路层：帧结构解析、MAC地址、以太网帧格式详解

做网络排错，不懂帧结构，就像修车不看发动机。我个人习惯，遇到奇怪的通断故障，第一件事就是一帧一帧地看。这章咱们把物理层和数据链路层这俩兄弟彻底搞明白。

先从物理层说起

说白了，物理层只管把比特（0和1）从A点挪到B点。它不关心这些比特是什么意思，是给谁发的——它只关心电平高低、时钟同步、连接器长什么样。

你可能要问了：“既然物理层只管发比特，那我排错时关注它干嘛？”
嗯，问得好。我遇到过好几次“数据链路层校验老失败”的案例，最后发现是网线太长，信号衰减到接收端根本分不清0和1。物理层是地基，地基不稳，上面全白搭。

数据链路层：帧的骨架

物理层把比特流送上来，数据链路层就得把这些比特组织成“帧”。帧就是一串有头有尾有规矩的比特组合。它负责在同一个网络段里，把数据从一个网卡送到另一个网卡。

你想想看，物理层只负责“发”，不负责“发给谁”。数据链路层就是负责“发给谁”这件事的。

MAC地址：设备身份证

每块网卡出厂时都烧录了一个全球唯一的MAC地址。48位，传统上写成这样：00:1A:2B:3C:4D:5E。

前24位是组织唯一标识符（OUI），相当于品牌编号；后24位是厂家自己分配的序列号。我帮你拆一下：

以太网帧格式详解

最常见的帧格式是Ethernet II（也叫DIX帧），IEEE 802.3是另一个版本，但有重叠。咱们说最常见的Ethernet II：

+----------------+----------------+----------------+----------------+----------------+----------------+
| 前导码 (8B)    | 目的MAC (6B)   | 源MAC (6B)     | 类型 (2B)      | 数据 (46-1500B) | FCS (4B)       |
+----------------+----------------+----------------+----------------+----------------+----------------+

咱们拆开讲每个字段：

1. 前导码（Preamble, 8字节）：用于同步时钟，让接收端知道“数据来了”。前7个字节是101010…，第8个字节是SFD（帧起始定界符）10101011。
2. 目的MAC地址（6字节）：谁收这个帧。可以是单播（唯一设备）、多播（组播组）或广播（FF:FF:FF:FF:FF:FF）。
3. 源MAC地址（6字节）：谁发的这个帧。
4. 类型字段（2字节）：标识上层协议。比如 0x0800 表示IPv4，0x0806 表示ARP，0x86DD 表示IPv6。注意，IEEE 802.3在这里用“长度字段”，所以要通过区分65536以内的值来判断是长度还是类型——这一点当年把我坑过好几次。
5. 数据（46~1500字节）：真正的IP包或其他上层数据。最少46字节，不够的要填充。
6. FCS（帧校验序列, 4字节）：CRC32校验，用于检查这个帧在传输中是否被损坏。

帧检测与排错

抓包时，你看到的每个数据包都会带着MAC地址。我个人习惯排错步骤是：

• 先看源MAC和目的MAC是否与你预期一致？如果不一致，可能是ARP欺骗、二层环路或者网卡配置错误。
• 再看类型字段：抓到的帧到底是IP包还是ARP包？一个常见的坑是：你以为在发IP包，结果抓包发现全是ARP请求——这说明设备没有找到目的MAC，一直在广播询问。网络可能断了，也可能是ARP表被清空了。
• 看长度：数据部分长度合理吗？如果以太网帧里数据长度写着1500，但实际抓到的IP包只有200字节，那你就得仔细看看填充部分是什么了。
• 检查FCS：大部分抓包工具会自动显示“Bad FCS”或“Checksum offloading”。如果FCS错误很多，八成是物理层问题。我曾经收到一个用户的投诉说“网络掉包”，结果发现他的网线有一段穿过了排水管，被水泡到信号乱飘。

实战：用帧结构排错

给你一个我经历过的真实案例。一次，客户说他们的服务器常常“连接不上”。我抓包后发现：

• 目的MAC是广播地址（FF:FF:FF:FF:FF:FF）。
• 类型是0x0806（ARP请求）。
• 问题是，这台服务器明明应该通过路由器通信，它的默认网关IP是对的，但它的ARP表里没有网关的MAC地址。

为什么？你看帧结构：ARP请求发到了广播域里，但网关没回应。于是我跟踪网关的交换机端口，发现那个端口因为“风暴控制”把ARP报文给丢了。原因是什么？这网关上联的链路上有环路，大量广播帧从另一个端口灌回来了，风暴控制触发了。嗯，一个二层帧结构里的广播地址，帮我找到了整个网络架构的隐患。

帧格式里的几个常见坑

• 巨型帧（Jumbo Frame）：超过1518字节。如果交换机不支持，就切包。我曾经在一个视频传输项目里，服务器设了9000字节的巨型帧，但中间某台交换机不支持，结果视频流断断续续。排查了两天才发现。
• 帧填充：当上层数据小于46字节时，以太网会在数据后面加填充字节。你在抓包里看到的“Padding”，其实就是填充。如果你误把填充当数据来读，可能会读到无意义的东西。
• 非标准帧头：有些封装（比如802.1Q VLAN标签）会在源MAC和类型字段之间插入4字节的Tag。那会改变帧的实际头结构，交换机可能不认识。我见过一次奇怪的VLAN不通问题，就是因为一端发了Tagged帧，但接收端交换机端口设置成了Access口，直接把它当普通帧处理了，结果VLAN信息全丢了。