连续的 0 和 1 流过网线，网卡怎么知道从哪开始、到哪结束？

阶段 2 · 数据链路层 · 第 8 课

在第 4 课中，我们看到物理层将电信号或光脉冲还原成了二进制比特流。但如果你是接收端电脑的网卡，面对网线上源源不断涌来的 010000010110...，你马上会陷入迷茫：这串比特流里，哪个才是第一位？哪个是最后一位？如果中间有一位被电磁干扰篡改了，我们怎么查出来？

物理层只管“傻傻地搬运信号”，它完全看不懂比特的业务含义。从这一课开始，我们进入阶段 2 · 数据链路层。数据链路层的第一道神技，就是把一维无休止的比特流切割成一段段有头有尾、能检错的规整包裹——帧（Frame）（Frame）。

学完本课后，你将能够：

1. 画出标准以太网帧（Ethernet II）的结构图，说出目的 MAC、源 MAC、Type、Payload 和 FCS 各自的字节长度。
2. 解释为什么以太网帧规定最小长度为 64 字节，以及当上层数据过短时网卡如何进行填充（Padding）。
3. 推导接收端网卡基于 循环冗余校验（CRC） 校验 帧校验序列（FCS） 的处理机制（为什么链路层只丢弃、不重传）。

1. 先看图：一个标准以太网帧长什么样？

目前全球局域网中最通用的以太网帧格式是 Ethernet II（又称 DIX 以太网帧格式）。如上图所示，当网卡要在双绞线或光纤上传输一段数据时，它会严格按照下列次序进行封装：

字段名称	英文缩写	占用字节数	它的核心职责是什么？（通俗大白话）
前导码 + 帧起始定界符	Preamble + SFD	$7\text{ 字节}+1\text{ 字节}$	告诉接收端 PHY 芯片：“注意！列车要进站了，快把时钟节拍对齐！”（SFD 为 10101011，最后两位 11 宣告帧正文开始）
目的 MAC 地址	DMAC	$6\text{ 字节}(48\text{ bit})$	这个包裹最终要交给局域网内的哪块网卡？
源 MAC 地址	SMAC	$6\text{ 字节}(48\text{ bit})$	这个包裹是由局域网内的哪块网卡发出的？
协议类型	Type / Length	$2\text{ 字节}$	拆开外壳后，里面的载荷交给哪种上层协议处理？（如 0x0800 代表 IPv4，0x0806 代表 ARP，0x86DD 代表 IPv6）
数据载荷	Payload	$46\sim 1500\text{ 字节}$	真正要传递的应用数据或网络层 IP 数据包（最大不能超过 MTU 1500 字节，不足 46 字节必须补齐）
帧校验序列	FCS	$4\text{ 字节}(32\text{ bit})$	像包裹底部的防伪封条，用于检查整个帧在传输中有没有被噪声改动哪怕一个比特

关键认知： 前导码和 SFD 是在物理层发送时实时打上的“打卡信号”，接收端接收后直接剥离。我们在 Wireshark 抓包或网络计算中所说的“以太网帧长度”，指的严格是：从目的 MAC 到 FCS 这一段（$6+6+2+\text{Payload}+4$ 字节）！

2. 为什么以太网规定最小长度必须是 64 字节？

在以太网规范中，有两条铁打的边界：

• 最大帧长：$6+6+2+1500+4=\mathbf{1518}\text{ 字节}$（不计前导码）。
• 最小帧长：$6+6+2+46+4=\mathbf{64}\text{ 字节}$。

你可能会好奇：如果我只想发送一个字母 A（载荷只有 1 个字节），直接发一个 $6+6+2+1+4=19\text{ 字节}$ 的超短帧，岂不是更省带宽？网卡为什么偏偏要强制填充（Pad） 45 个无用字节，硬凑满 64 字节？

这要追溯到以太网早期的核心机制——CSMA/CD（载波侦听多路访问/碰撞检测）：

1. 早期以太网是多台电脑插在同一根同轴电缆或集线器上的半双工网络，大家共享介质。
2. 电脑 A 发送数据时，信号在电缆里以光速向前传播，需要一定时间才能到达最远端的电脑 B。
3. 如果帧太短（比如只发了 10 微秒），电脑 A 刚把最后一个比特推上网线就以为发完了；而此时这束信号还在半路上，正好撞上了电脑 B 刚发出的信号（发生冲突碰撞）。当冲突碎片反射回电脑 A 时，A 早就关掉了冲突检测监听，根本不知道自己发的数据已经被撞烂了！
4. 为了确保发送端在整帧还没发完之前，必定能听到网络中最远端反弹回来的冲突信号，以太网标准计算得出了“争用期（Slot Time）”，对应在 $10\text{ Mb/s}$ 速率下恰好是 64 字节 的发送时间（$51.2\mu \text{s}$）。

尽管今天全双工交换网络已经消除了物理碰撞，但为了保持所有软硬件的向后兼容性，64 字节的最小帧长标准一直被保留至今。任何小于 64 字节的残缺碎片（称为“矮帧 / 侏儒帧 Runt Frame”）都会被交换机当成残次品直接扔掉！

课后巩固 · 练习 · 单选

标准以太网帧（Ethernet II）的数据载荷（Payload）最少为 46 字节，为什么不足 46 字节时 MAC 层必须使用填充符（Padding）将其补齐至 46 字节？

A. 为了防止网线里的电磁波速度变慢

B. 为了确保以太网帧满足 64 字节的最小帧长要求，以便能够在争用期内可靠检测冲突

C. 为了给 IPv4 地址预留更多的加密空间

D. 因为双绞线每次只能以 64 的倍数传输数据

3. FCS 与 CRC-32：如何一眼识破比特被篡改？

网线跑过机房强电旁边，电磁噪声有时会把某个 0 颠簸成 1。接收端怎么判断整个包裹是否完好无损？

答案就是尾部的 4 字节 帧校验序列（FCS）。它采用 循环冗余校验（CRC）（Cyclic Redundancy Check，循环冗余校验） 算法：

1. 发送端计算：发送端网卡硬件把从“目的 MAC”到“数据载荷”的全部二进制数当成一个极长的数字，除以 IEEE 802.3 标准指定的 33 位除数（CRC-32 校验多项式），做一种特殊的二进制模 2 除法，算出一个 32 位（4 字节）的余数，作为 FCS 贴在帧尾。
2. 接收端验算：接收端网卡收到整帧后，用同样的除数对整帧（包括前面的数据和后面的 FCS）做模 2 除法。
   • 如果余数为 0：说明传输过程没有发生任何比特翻转，验算通过！网卡剥除 FCS，把载荷呈报给操作系统。
   • 如果余数不为 0：说明传输中至少有 1 位比特被干扰篡改了，验算失败！

数据链路层的铁律：只检错，不纠错，更不重传

请牢记一个关键设计哲学：接收端网卡发现 FCS 错误后，会直接在硬件层把这帧数据静默丢弃（Drop），并在网卡错误统计里将 CRC errors 加 1。

网卡绝对不会向发送端发一条消息说“嘿，你刚才那一帧第 5 位错了，请重发一遍”。为什么？

• 如果每个底层物理帧都要确认和重传，局域网的硬件逻辑会变得极其复杂，吞吐量暴跌。
• 数据链路层的宗旨是提供高效率的无差错交付；至于丢了包要不要重发，由更高层的可靠传输协议（如传输层 TCP）通过端到端确认和超时机制来负责！

课后巩固 · 练习 · 单选

接收端网卡的 MAC 控制器收到一个以太网帧后，利用 CRC-32 多项式重新计算校验和，发现与帧尾部的 FCS 字段数值不符。此时网卡会如何处理该帧？

A. 自动将错误的比特翻转纠正过来，然后交给操作系统

B. 向发送端立即回发一条以太网重传请求帧

C. 静默丢弃该错误帧，并递增网卡错误计数器（CRC Errors）

D. 强制修改对端交换机的转发表

4. 小结与下一步

• 帧的边界：物理层前导码和 SFD（10101011）帮助接收端对齐时钟，锁定以太网帧的真正起点。
• 帧长范围：以太网标准帧长为 $64\sim 1518\text{ 字节}$（Payload 为 $46\sim 1500\text{ 字节}$），不足 46 字节通过 Padding 补齐。
• 差错校验：尾部 4 字节 帧校验序列（FCS） 基于 循环冗余校验（CRC）-32 校验，接收端验算失败直接静默丢弃，保证上层拿到干净的数据。

现在，我们已经把数据打包成一个个规整的包裹了。但帧头里赫然写着“目的 MAC”和“源 MAC”，这个 48 位的物理地址到底从哪里来？它怎样区分某一台具体电脑、一群电脑还是全网所有电脑？下一课我们深入拆解MAC 地址。