vault backup: 2026-05-27 00:12:00

hhs/NETWORK/02-链路层/01-Ethernet帧结构.md

@@ -7,7 +7,29 @@ create time: 2026-05-17 22:50
 
 ## 概述
 
-Ethernet（以太网）是目前最主流的局域网技术，由 Xerox、DEC 和 Intel 在 1980 年联合制定（IEEE 802.3）。理解 Ethernet 帧结构是掌握网络底层通信的基础——每一帧都包含了足够的信息来让网卡判断"这是给我的吗？内容完整吗？上层协议是什么？"
+Ethernet（以太网）是目前最主流的局域网技术。最初由 Robert Metcalfe 在 Xerox PARC 于 1973 年发明，1980 年由 Xerox、DEC、Intel 联合发布 DIX 标准，1983 年 IEEE 正式发布 802.3 标准。
+
+理解 Ethernet 帧结构是掌握网络底层通信的基础——每一帧都包含了足够的信息来让网卡判断"这是给我的吗？内容完整吗？上层协议是什么？"
+
+## 物理层封装：前导码与帧间隔
+
+在以太网帧到达网线之前，物理层（PHY）会自动加上 **前导码 (Preamble)** 和 **帧首定界符 (SFD)**，这部分对软件不可见，但理解它有助于理解"帧"与"包"的边界。
+
+```
+|<---------- Preamble + SFD (8B) -------->|<------------- Ethernet Frame ------------>|
+┌───────────────────────┬────────┬─────────┬──────────┬──────────┬──────────┬─────────┐
+│  Preamble (7 bytes)   │ SFD(1B)│Dest MAC │ Src MAC  │ EtherType│ Payload  │   FCS   │
+│  10101010 × 7         │10101011│ 6 bytes │ 6 bytes  │ 2 bytes  │ 46-1500B │ 4 bytes │
+└───────────────────────┴────────┴─────────┴──────────┴──────────┴──────────┴─────────┘
+                                                                ↑ 14B Header
+```
+
+- **Preamble**: 7 字节的 `10101010` 交替模式，用于接收方的**时钟同步**（位同步）
+- **SFD** (Start Frame Delimiter): `10101011`，最后两个连续 1 表示"帧数据从下一个字节开始"
+- **IFG** (Inter-Frame Gap): 帧与帧之间至少间隔 **12 字节**（96 bit time），让网卡有时间处理上一帧
+
+> [!question] 为什么前导码是 7 字节而不是 8 字节？
+> 前 7 字节用于时钟同步，SFD 单独标记帧起始。接收方需要足够的跳变沿来锁定频率，7 字节 × 8 bit = 56 次跳变，在早期的 10Mbps 以太网中大约需要 5.6μs 完成同步。
 
 ## Ethernet II 帧格式（最常见）
 
@@ -39,34 +61,60 @@ Ethernet（以太网）是目前最主流的局域网技术，由 Xerox、DEC
 
 现代 Gigabit+ 网卡已不用 CSMA/CD，但为了兼容仍保留此限制。
 
-## IEEE 802.3 / 802.3Q（VLAN Tagged）帧
+## IEEE 802.1Q（VLAN Tagged）帧
 
-当网络中使用 VLAN 时，帧中会插入一个 4 字节的 802.1Q Tag：
+当网络中使用 VLAN 时，帧中会**插入**一个 4 字节的 802.1Q Tag。注意：TPID 占据了原本 EtherType 的位置，真正的 EtherType 跟在 TCI 之后：
 
 ```
-┌──────────┬──────────┬──────┬──────┬──────────┬─────────────┬──────────┐
-│ Dest MAC │ Src MAC  │ Type │ TPID │ TCI/VID  │   Payload   │   FCS    │
-│  6 bytes │  6 bytes │ 2B   │2B    │ 2B      │ 46–1500 B   │ 4 bytes  │
-└──────────┴──────────┴──────┴──────┴──────────┴─────────────┴──────────┘
+┌──────────┬──────────┬─────────────┬──────────┬──────────┬─────────────┬──────────┐
+│ Dest MAC │ Src MAC  │ TPID (0x8100)│   TCI    │ EtherType│   Payload   │   FCS    │
+│  6 bytes │  6 bytes │   2 bytes   │ 2 bytes  │ 2 bytes  │  42–1500 B  │ 4 bytes  │
+│          │          │             │ PCP DEI  │  0x0800  │             │          │
+│          │          │             │ 3b  1b   │          │             │          │
+│          │          │             │ VID(12b) │          │             │          │
+└──────────┴──────────┴─────────────┴──────────┴──────────┴─────────────┴──────────┘
+                         ←──────── 4B 802.1Q Tag ────────→
 ```
 
 新增字段：
-- **TPID** (Tag Protocol Identifier): `0x8100` — 标识这是带 VLAN Tag 的帧
-- **TCI** (Tag Control Information): 包含 PCP（优先级，3 bit）、CFI（规范格式指示符，1 bit）、**VID**（VLAN ID，12 bit）
+- **TPID** (Tag Protocol Identifier): `0x8100` — 占据 EtherType 的位置，标识"这不是普通协议类型，而是 VLAN Tag"
+- **TCI** (Tag Control Information): 包含 PCP（优先级，3 bit）、DEI（丢弃适格指示符，1 bit）、**VID**（VLAN ID，12 bit）
 
-VID 取值范围 1–4094，共 4094 个可用 VLAN。
+> [!note] CFI → DEI
+> 早期标准中该位叫 CFI (Canonical Format Indicator)，用于标记 MAC 地址是否为规范格式。802.1Q-2011 修订后改为 DEI (Drop Eligible Indicator)，用于标识在网络拥塞时可优先丢弃的帧。
+
+VID 取值范围 0–4095，其中 **VID 0** 用于表示优先级帧（不含 VLAN 信息），**VID 4095** 为保留值，实际可用 VLAN 为 1–4094（共 4094 个）。
+
+> [!question] 插入 4 字节 Tag 后帧会不会超过最大长度？
+> 会。带 Tag 的帧最大长度从 1518 字节扩展到 **1522 字节**。这也是为什么交换机端口通常区分"最大帧长度"配置。
 
 ## 常见 EtherType 对照表
 
-| EtherType | 十六进制 | 协议 |
-|-----------|---------|------|
+| 协议 | EtherType | 说明 |
+|------|-----------|------|
 | IPv4 | `0x0800` | IP 数据包 |
 | IPv6 | `0x86DD` | IPv6 数据包 |
 | ARP | `0x0806` | 地址解析协议 |
 | RARP | `0x8035` | 反向 ARP（历史遗留） |
-| PPPoE | `0x8864` | PPP over Ethernet |
+| PPPoE Discovery | `0x8863` | PPPoE 发现阶段 |
+| PPPoE Session | `0x8864` | PPPoE 会话阶段 |
 | 802.1Q | `0x8100` | VLAN 标记 |
 | LACP | `0x8809` | 链路聚合控制协议 |
+| LLDP | `0x88CC` | 链路层发现协议 |
+
+### EtherType vs Length：如何区分？
+
+这是以太网中一个经典的历史遗留问题。Ethernet II 和 IEEE 802.3 原始标准在同一个 2 字节位置上使用了**不同的语义**：
+
+| 值范围 | 含义 | 对应标准 |
+|--------|------|----------|
+| ≥ `0x0600` (1536) | **EtherType** — 上层协议标识 | Ethernet II |
+| ≤ `0x05DC` (1500) | **Length** — Payload 字节数 | IEEE 802.3 LLC/SNAP |
+
+由于合法的 Payload 长度最大为 1500 字节，而合法的 EtherType 最小为 1536，两者不会重叠。**现代网络中绝大多数帧都是 Ethernet II 格式**，802.3 LLC/SNAP 仅在一些特殊场景（如 STP、某些工业协议）中出现。
+
+> [!question] 如果你用 Wireshark 抓到一个该字段值为 0x05EE 的帧，它是什么？
+> `0x05EE` = 1518，落在 1501–1535 之间——这是一个非法值，正常的以太网实现不会产生这样的帧。
 
 ## MAC 地址空间与 OUI
 
@@ -83,22 +131,69 @@ link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
 # Linux 也可以用 ethtool -P eth0 查看出厂 MAC
 ```
 
-### 单播/多播位（LSB of First Byte）
+### 第一个字节的两个重要比特位
 
-第一个字节的最低比特位决定寻址类型：
+MAC 地址的第一个字节中，**最低两位**各自承载独立含义（注意：在网络传输中 MAC 地址按 **LSB first** 顺序发送，但日常书写采用 MSB first）：
 
-| LSB | 类型 | 示例 |
-|-----|------|------|
-| 0 | 单播 (Unicast) | `aa:bb:cc:dd:ee:ff` |
-| 1 | 多播 (Multicast) | `01:00:5e:xx:xx:xx`（IPv4 组播） |
-| 1 | 广播 (Broadcast) | `ff:ff:ff:ff:ff:ff` |
+```
+第一字节: b7 b6 b5 b4 b3 b2 b1 b0
+                                ↑ I/G 位 (Individual/Group)
+                           ↑ U/L 位 (Universal/Local)
+```
+
+#### I/G bit（bit 0）— 单播/组播
+
+| 值 | 类型 | 说明 | 示例 |
+|----|------|------|------|
+| 0 | 单播 (Unicast) | 发给单一设备 | `aa:bb:cc:dd:ee:ff` |
+| 1 | 组播 (Multicast) | 发给一组设备 | `01:00:5e:xx:xx:xx`（IPv4 组播） |
+
+广播地址 `ff:ff:ff:ff:ff:ff` 是组播的特例（所有 bit 为 1）。
+
+#### U/L bit（bit 1）— 全局/本地管理
+
+| 值 | 类型 | 说明 |
+|----|------|------|
+| 0 | 全局管理 (GUA) | 由 IEEE 分配 OUI，厂商保证唯一（网卡出厂 MAC） |
+| 1 | 本地管理 (LAA) | 管理员手动设置或软件生成（如 Docker 容器 MAC、虚拟网卡） |
 
 > [!tip] 如何快速判断？看 MAC 第一个字节的十六进制最后一位
-> - `a` → 1010 → LSB=0 → 单播
-> - `3` → 0011 → LSB=1 → 多播/广播
+> - `a` → 101**0** → I/G=0, U/L=0 → 单播 + 全局管理
+> - `3` → 001**1** → I/G=1, U/L=1 → 组播 + 本地管理
+> - `2` → 001**0** → I/G=0, U/L=1 → 单播 + 本地管理（如 Docker 生成的 MAC）
+
+### MAC 地址的比特序
+
+MAC 地址在网线上传输时采用 **LSB first**（小端序），这与我们日常书写 `aa:bb:cc:dd:ee:ff` 的 MSB first 习惯相反。这也解释了为什么 IPv4 组播 MAC 的前缀是 `01:00:5e` 而不是 `01:00:5f`——因为 `01` 的实际传输顺序是 `10000000`，I/G 位确实是第 1 个被发出的比特。
+
+## MTU、MSS 与 Jumbo Frame
+
+### 关键概念区分
+
+| 概念 | 层级 | 标准值 | 说明 |
+|------|------|--------|------|
+| **MTU** (Maximum Transmission Unit) | 链路层 | 1500 bytes | 帧中 Payload 的最大长度（不含 Header 和 FCS） |
+| **MSS** (Maximum Segment Size) | 传输层 (TCP) | 1460 bytes | TCP 数据段的最大载荷，= MTU - 20(IP) - 20(TCP) |
+| **Max Frame** | 链路层 | 1518 bytes | 整个以太网帧（含 Header 14B + FCS 4B） |
+
+### Jumbo Frame（巨型帧）
+
+部分交换机和网卡支持 **Jumbo Frame**，将 MTU 提升到 **9000 字节**（甚至更大）：
+
+| 帧类型 | MTU | 最大帧长 | 适用场景 |
+|--------|-----|----------|----------|
+| 标准以太网 | 1500 B | 1518 B | 通用网络 |
+| Jumbo Frame | 9000 B | 9018 B | 数据中心、iSCSI、NFS 存储网络 |
+
+> [!warning] Jumbo Frame 的使用陷阱
+> 1. **全链路必须一致**：路径上任何一台设备不支持 Jumbo Frame，就会导致分片或丢包
+> 2. **非标准协议**：IEEE 从未正式标准化 Jumbo Frame（>1500 的 MTU），各家厂商实现略有差异
+> 3. **实际收益**：减少帧头开销比例，CPU 中断次数降低，在大数据传输场景下吞吐量提升 10%–30%
 
 ## 关联笔记
 
-- [[hhs/NETWORK/OSI与TCP-IP模型对比]] — 以太网属于链路层
-- [[hhs/NETWORK/MAC地址与广播域]] — MAC 地址的工作范围
-- [[hhs/NETWORK/Switch与路由器]] — Switch 如何使用 MAC 表转发帧
+- [[hhs/NETWORK/01-基础概念/01-OSI与TCP-IP模型对比]] — 以太网属于链路层
+- [[hhs/NETWORK/02-链路层/03-MAC地址与广播域]] — MAC 地址的工作范围
+- [[hhs/NETWORK/02-链路层/04-Switch与路由器]] — Switch 如何使用 MAC 表转发帧
+- [[hhs/NETWORK/02-链路层/02-CSMA-CD与以太网退避]] — CSMA/CD 碰撞检测机制
+- [[hhs/NETWORK/02-链路层/05-VLAN与Trunk]] — 802.1Q VLAN 的实际部署

hhs/NETWORK/02-链路层/02-CSMA-CD与以太网退避.md

@@ -1,5 +1,5 @@
 ---
-tags: [计算机网络, CSMA-CD, 以太网退避, 冲突检测]
+tags: [计算机网络, CSMA-CD, 以太网退避, 冲突检测, 碰撞域, 全双工, 半双工]
 create time: 2026-05-17 23:00
 ---
 
@@ -40,19 +40,39 @@ flowchart TD
 | 3 | **Collision Detection** | 发送过程中持续监测是否有冲突信号 |
 | 4 | **Collision Handling** | 检测到冲突 → 发 Jam Signal → 执行退避 → 重试 |
 
+## Slot Time（时隙）
+
+在讲解退避算法之前，先认识一个核心概念——**Slot Time（时隙/争用期）**：
+
+$$\text{Slot Time} = 512 \text{ bit-time} = 51.2 \mu s \quad (\text{在 10Mbps 以太网下})$$
+
+时隙是 CSMA/CD 中所有时间计算的基本单位，它的值约等于**最大往返传播延迟（~46.4μs）+ Jam Signal 时间（~3.2μs）+ 安全余量**。退避算法中的等待时间、最小帧长、冲突检测窗口，全部以它为基准。
+
+> [!QUESTION] 为什么 Slot Time 要比理论往返延迟长一点？
+> 因为检测到冲突后还需要发送 Jam Signal 确保所有节点都感知到碰撞。如果时隙刚好等于往返延迟，发送方在时隙结束时还没完成 Jam Signal 的发送，就可能误以为"没冲突"。
+
+## Jam Signal（强化冲突信号）
+
+检测到冲突后，发送方会立刻发出一个 **32 bit 的 Jam Signal**，目的有二：
+
+1. **强化冲突**：确保网络上所有节点（包括距冲突点较远的节点）都能检测到碰撞
+2. **延长冲突持续时间**：使冲突信号维持足够长的时间，避免有节点"刚好错过"碰撞窗口
+
+Jam Signal 的传输时间约 3.2μs（10Mbps），已包含在 Slot Time 的计算中。
+
 ## 二进制指数退避算法
 
-冲突后的等待时间通过随机退避来避免再次冲突：
+冲突后的等待时间通过**随机退避**来避免再次碰撞——选到相同随机数的概率随窗口增大而降低：
 
-$$\text{等待时间} = \min(r, 2^{10}-1) \times 512 \text{ bit-time}$$
+$$\text{backoff} = r \times \text{Slot Time}，\quad r \in \{0, 1, \ldots, \min(2^k - 1, 1023)\}$$
 
-其中 $r$ 为重传次数，`512 bit-time` 是最小帧长对应的传输时间（即争用期）。
+其中 $k$ 为该帧的重传次数。每次冲突后窗口翻倍（指数增长），上限固定在 1023。
 
 ```mermaid
 flowchart TD
-    k["重传次数 k"] --> r["r = random(0 ~ 2^k - 1)"]
-    r --> capped["capped at 2^10 - 1 = 1023 (k > 10)"]
-    capped --> backoff["backoff_time = r × 512 bit-time"]
+    k["重传次数 k"] --> window["窗口大小 min(2^k - 1, 1023)"]
+    window --> r["r = random(0 ~ 窗口大小)"]
+    r --> backoff["backoff = r × 51.2μs"]
     
     style k fill:#DDA0DD,color:#000
     style backoff fill:#98FB98,color:#000
@@ -60,69 +80,140 @@ flowchart TD
 
 ### 退避表
 
-| 重传次数 k | 窗口大小 2^k - 1 | 可能等待的 slot 数范围 |
-|-----------|------------------|---------------------|
-| 1 | 1 | {0, 1} |
-| 2 | 3 | {0, 1, 2, 3} |
-| 3 | 7 | {0..7} |
-| 4 | 15 | {0..15} |
-| 5–10 | 最大值 1023 | {0..1023} |
-| >10 | 仍为 1023 | 上限固定 |
+| 重传次数 k | 窗口大小 min(2^k - 1, 1023) | r 的取值范围 | 最大等待时间 |
+|-----------|---------------------------|-------------|------------|
+| 1 | 1 | {0, 1} | 51.2μs |
+| 2 | 3 | {0..3} | 153.6μs |
+| 3 | 7 | {0..7} | 358.4μs |
+| 4 | 15 | {0..15} | 768μs |
+| 5–10 | 2^k - 1 → 1023 | {0..1023} | 52.4ms |
+| >10 | 1023（上限固定） | {0..1023} | 52.4ms |
 
-如果重传 16 次仍然失败，帧被丢弃并向上层报告错误。
+> [!tip] 为什么窗口要"封顶"在 1023？
+> 如果不封顶，k=16 时窗口可达 65535，等待时间超过 3 秒——太久了。封顶保证了最坏情况下的重传延迟有上界，同时也意味着高冲突率下不同节点的退避选择可能重复，这就是网络严重拥塞时的"公平性代价"。
+
+如果重传 **16 次**仍然失败，帧被丢弃并向上层报告错误。
 
 ### 示例
 
 假设节点 A 和 B 同时发送，发生冲突：
 
 ```
-时刻 0ms:   A 和 B 同时发送 → 冲突！
-            两者都发送 32bit Jam Signal
-时刻 0.1ms: A 选 r=3 → 等 3×512bit-time = 3×51.2μs ≈ 154μs
-            B 选 r=1 → 等 1×51.2μs ≈ 51μs
-时刻 0.05ms: B 先等完，先尝试发送 → A 还在等
-时刻 0.15ms: A 等完，发现信道已被 B 占用 → 退避重选 r
-...
+时刻 0μs:     A 和 B 同时开始发送
+时刻 23.2μs:  A 检测到冲突（假设距冲突点约 23.2μs）
+              A 和 B 均发送 Jam Signal (32bit, 约 3.2μs)
+              此时 Slot Time 计时仍在继续...
+时刻 51.2μs:  Slot Time 结束，进入退避期
+              A 选 r=3 → 等 3 × 51.2μs = 153.6μs
+              B 选 r=1 → 等 1 × 51.2μs = 51.2μs
+时刻 102.4μs: B 先等完 → 检测信道空闲 → 发送 ✅
+时刻 204.8μs: A 等完 → 检测信道忙碌 → 等待...
+              （A 的本次重传计数 k=2，下次窗口扩大为 {0..3}）
 ```
 
+> [!QUESTION] 第二次冲突时，A 和 B 还是同时选到相同 r 怎么办？
+> 第二次冲突时窗口翻倍到 {0..3}，选到相同值的概率从 1/2 降到 1/4。指数退避的核心思想就是：**冲突越频繁，等待范围越大，再次碰撞的概率越低**。当然，极端情况下仍可能连续冲突——这就是为什么 16 次后要放弃。
+
 ## 最小帧长与争用期
 
 ### 为什么最小帧是 64 字节？
 
-关键公式：**帧传输时间 ≥ 2 × 端到端传播延迟**
+核心原则：**帧传输时间 ≥ 往返传播延迟**
 
-如果帧太短，可能在冲突信号到达之前就已经发完了——发送方根本不知道发生过冲突。
+如果帧太短，发送方可能在冲突信号返回之前就已经发完了——根本不知道发生过冲突，也就无法重传。
 
 ```mermaid
 sequenceDiagram
-    participant A as 节点 A
-    participant H as 最远节点 H
-    Note over A,H: 传播延迟 = τ
+    participant A as "节点 A"
+    participant H as "最远节点 H"
+    Note over A,H: "传播延迟 τ"
     
-    A->>H: 开始发送一个超短帧 (长度 < 2τ)
-    H->>A: 冲突信号沿原路返回
-    Note over A: 此时 A 已经发完了...<br/>没检测到冲突！🔥
+    A->>H: "发送一个超短帧 (长度 < 2τ)"
+    H->>A: "冲突信号返回"
+    Note over A: "此时 A 已经发完了...<br/>没检测到冲突!"
 ```
 
-所以规定：
+所以必须满足：
 
-$$\text{最小帧长} \geq 2 \times \tau \times \text{带宽}$$
+$$\text{最小帧长} \geq 2 \times \tau_{\max} \times \text{带宽}$$
 
-对于经典 10Mbps 以太网，最长电缆段 2500m，$\tau \approx 12.5\mu s$：
+其中 $\tau_{\max}$ 是网络中最远两个节点之间的**单程传播延迟**。
 
-$$\text{最小帧长} \geq 2 \times 12.5\mu s \times 10^7 \text{ bps} = 250,000 \text{ bits?}$$
+### 从理论推导到工程标准
 
-等等，实际工程中使用了中继器和更短的网段组合，最终标准定为 **512 bit-time = 64 bytes**。
+对于经典 10Mbps 以太网（10BASE5 粗缆 + 4 个中继器，总跨度约 2500m）：
 
-## 现代以太网中的命运
+$$\tau_{\max} \approx 46.4\mu s \quad \text{(含中继器延迟)}$$
 
-| 年代 | 拓扑 | 介质 | CSMA/CD? |
-|------|------|------|---------|
-| 1980s | 总线型 | 同轴电缆 | ✅ 必需 |
-| 1990s | 星型 + Hub | 双绞线 | ✅ 存在但极少冲突 |
-| 2000s+ | 全双工 Switch | 双绞线/光纤 | ❌ 已禁用 |
+代入公式：
 
-全双工模式下，收发通道分离（两根线对），不存在碰撞的可能，CSMA/CD 自动关闭。从 Gigabit Ethernet (802.3ab) 起，交换机端口默认全双工运行。
+$$\text{最小帧长} \geq 46.4\mu s \times 10^7 \text{ bps} \approx 464 \text{ bits}$$
+
+IEEE 在此基础上统一向上取整，取了一个**干净的 2 的幂次方**——512 bits（64 bytes），这也是 Slot Time 的值。多出的 48 bits 作为安全余量，同时覆盖了 Jam Signal 的传输时间。
+
+> [!tip] 帧长与 Slot Time 的关系
+> 最小帧长 = Slot Time × 带宽 = 512 bit-time × 1 bps = **512 bits = 64 bytes**
+>
+> 这不是巧合——最小帧长的设计保证了：只要帧还在传输中（长度 ≥ Slot Time），冲突就一定能被检测到。退避算法以 Slot Time 为单位，最小帧长以 Slot Time 为下限，二者在设计上是统一的。
+
+### 碰撞域（Collision Domain）
+
+理解 CSMA/CD 就不得不理解**碰撞域**——所有共享同一冲突检测范围的节点组成一个碰撞域：
+
+```mermaid
+graph LR
+    subgraph CD1["碰撞域 1 (Hub 连接)"]
+        A["节点 A"] --- Hub["Hub 集线器"]
+        B["节点 B"] --- Hub
+        C["节点 C"] --- Hub
+    end
+    Switch["交换机"] --- Hub
+    Switch --- D["节点 D"]
+    Switch --- E["节点 E"]
+    subgraph CD2["碰撞域 2"]
+        D
+        E
+    end
+
+    style CD1 fill:#FFE4E1,stroke:#FF6B6B,stroke-width:2px
+    style CD2 fill:#E1F5FE,stroke:#4FC3F7,stroke-width:2px
+```
+
+- **Hub**：不隔离碰撞域——所有连接到同一 Hub 的设备属于**同一个**碰撞域
+- **Switch**：每个端口是一个独立碰撞域，从根本上消除了 CSMA/CD 的需求
+- **广播域**则不同，由 VLAN 划分，和 CSMA/CD 无关（详见 [[05-VLAN与Trunk]]）
+
+## 半双工 vs 全双工
+
+CSMA/CD 的"监听-发送-检测-退避"机制本质上是**半双工**的——同一时间只能收或发，不能同时进行。全双工模式通过物理上分离收发通道彻底绕开了这个问题：
+
+| 模式 | 通道 | 冲突 | CSMA/CD | 典型场景 |
+|------|------|------|---------|---------|
+| 半双工 (Hub) | 共享 | 存在 | 必需 | 早期总线/Hub 网络 |
+| 全双工 (Switch) | 收发分离 | 不存在 | 自动关闭 | 现代交换网络 |
+
+从 **Gigabit Ethernet (802.3ab)** 起，交换机端口默认全双工运行。虽然标准中仍保留了半双工 CSMA/CD 定义（用于兼容），但实际网络中已几乎不再使用。
+
+```mermaid
+graph LR
+    subgraph HalfDuplex["半双工 (Hub)"]
+        direction LR
+        H1["节点"] -- "发送" --> H2["Hub"]
+        H2 -- "接收" --> H1
+    end
+    subgraph FullDuplex["全双工 (Switch)"]
+        direction LR
+        S1["节点"] -- "发送" --> S2["Switch"]
+        S2 -- "接收" --> S1
+    end
+
+    style HalfDuplex fill:#FFF3E0,stroke:#FF9800
+    style FullDuplex fill:#E8F5E9,stroke:#4CAF50
+```
+
+> [!note] 半双工 vs 全双工的本质区别
+> - **半双工**：收发共用一条通道，同一时刻只能单向通信，需要 CSMA/CD 协调
+> - **全双工**：收发各有独立通道（物理上两对线），可同时双向通信，CSMA/CD 自动关闭
 
 > [!note] 如何检查当前网卡是否启用了 CSMA/CD？
 > ```bash
@@ -130,9 +221,11 @@ $$\text{最小帧长} \geq 2 \times 12.5\mu s \times 10^7 \text{ bps} = 250,000
 > Supports Collision Detection: yes
 > Current Collision Detection: disabled (full-duplex)
 > ```
+> 现代网卡通常显示 "disabled (full-duplex)"，说明 CSMA/CD 已关闭。
 
 ## 关联笔记
 
-- [[hhs/NETWORK/Ethernet帧结构]] — 以太网 II 帧的格式定义
-- [[hhs/NETWORK/Switch与路由器]] — Switch 如何通过全双工消除冲突
-- [[hhs/NETWORK/VLAN与Trunk]] — VLAN 隔离冲突域
+- [[01-Ethernet帧结构]] — 以太网 II 帧的格式定义，64 字节最小帧长的来源
+- [[04-Switch与路由器]] — Switch 如何通过全双工消除冲突
+- [[05-VLAN与Trunk]] — VLAN 如何隔离广播域
+- [[03-MAC地址与广播域]] — 广播域与碰撞域的区别