计算机网络 - 传输层与链路层

This post is not yet available in English. Showing the original version.

May 6, 2026 Notes 学习 / 计算机网络 zh-CN

Table of Contents

传输层（Transport Layer）

一、传输层的职责

网络层（IP）只做主机到主机的尽力转发——包送到目的主机就算完成任务，至于是哪个进程用、丢了怎么办，它一概不管。

传输层在 IP 之上架起了进程到进程的通信桥梁，额外提供了端口复用、可选的可靠传输、流量控制与拥塞控制。

graph LR
    subgraph 发送主机
        App1[进程 A] & App2[进程 B] --> TL1[传输层\nMux]
        TL1 --> NL1[网络层 IP]
    end
    subgraph 接收主机
        NL2[网络层 IP] --> TL2[传输层\nDemux]
        TL2 --> App3[进程 A] & App4[进程 B]
    end
    NL1 -->|"尽力而为 (IP)"| NL2

二、多路复用与解复用

传输层靠 端口号（Port Number，16 bit，0–65535） 区分同一台主机上的不同进程。

端口范围	类型	典型例子
0 – 1023	知名端口	HTTP=80, HTTPS=443, DNS=53, SMTP=25
1024 – 49151	注册端口	厂商自用
49152 – 65535	动态端口	系统临时分配给客户端

UDP 解复用：只看 (目的IP, 目的端口) 二元组。不同来源、只要目的相同，就送到同一个套接字。

TCP 解复用：看 (源IP, 源端口, 目的IP, 目的端口) 四元组。两个客户端连同一个服务器 80 端口，四元组不同 → 对应不同套接字 → 可以并发服务成千上万个连接。

类比：UDP 是"只认门牌号"的快递员，TCP 是"认门牌号 + 寄件人地址"的挂号信——后者保证每封信对应唯一的通信通道。

三、UDP

UDP 的哲学是最小主义：头部 8 字节，没有连接，没有确认，没有重传。

源端口
16 bit
目的端口
16 bit
长度
16 bit
校验和
16 bit
数据（payload）

校验和：把报文段（加上伪首部 srcIP/dstIP/协议号/长度）视为 16 bit 整数序列，全部相加取反码。接收方把所有字段（含校验和）加起来，全 1 则无误，否则丢弃。只能检错，不能纠错。

UDP 适用场景：DNS（一问一答，快）、视频通话（丢帧可忍，卡顿不可忍）、DHCP、游戏（应用自己管重传）。

一句话定位：UDP = IP + 端口号 + 基础校验，其余一概不管。

四、可靠数据传输原理：rdt 的演进

TCP 的可靠传输不是天上掉下来的，而是一步步加机制逼出来的。

rdt 1.0：完全可靠信道

理想假设：无比特错误，无丢包。发送方发，接收方收，什么都不用加。现实不存在，但这是起点。

rdt 2.x：有比特错误，无丢包

信道可能翻转比特。怎么办？加 ACK（确认）/ NAK（否定确认），出错了就重传。

sequenceDiagram
    participant S as 发送方
    participant S2 as 信道（可能翻转比特）
    participant R as 接收方
    S->>S2: 分组（数据 + 校验和）
    S2->>R: 分组（可能有错）
    alt 分组正确
        R->>S: ACK
        Note over S: 发下一个
    else 分组有误
        R->>S: NAK
        Note over S: 重传
    end

rdt 2.0 的致命缺陷：ACK/NAK 本身也可能出错。ACK 被翻成 NAK → 多余重传；更糟糕的是接收方无法区分这是重传还是新包。

rdt 2.1 修复：给每个分组加 序号（1 个 bit，0/1 交替），ACK 也带序号。接收方收到重复序号 → 知道是重传，丢弃并重发 ACK。

rdt 2.2 进一步简化：彻底去掉 NAK。收到坏包时，重发对上一个好包的 ACK。发送方收到重复 ACK → 等效于 NAK，重传。

rdt 3.0：有比特错误，且有丢包

信道还会丢包。分组丢了，接收方永远不会发 ACK，怎么破？

加 计时器（Timer）：发出分组就启动倒计时，超时了还没收到 ACK → 直接重传，不管包是传丢了还是 ACK 传丢了。

sequenceDiagram
    participant S as 发送方
    participant R as 接收方
    S->>R: 分组(seq=0)
    Note over S: 启动计时器
    Note over S,R: 分组丢失！
    Note over S: 超时！重传
    S->>R: 分组(seq=0) [重传]
    R->>S: ACK(0)
    Note over S: 停止计时器，继续

rdt 3.0 已经正确了，但它是 停止等待（Stop-and-Wait） 协议：每次只发一个，等 ACK 才发下一个。

信道利用率极低：

U_{\text{sender}} = \frac{L/R}{RTT + L/R}

极端例子：1 Gbps 链路，RTT = 30 ms，分组 1 KB。 $L/R ≈ 0.008$ ms， $U ≈ 0.027\%$ 。99.97% 的时间在空等 ACK，信道基本闲着。

流水线协议（Pipelining）

不等 ACK，连续发多个分组，用窗口（Window） 控制最多多少个分组"在途"。

U_{\text{sender}} = \frac{n \cdot L/R}{RTT + L/R}

窗口大小 $n$ ，利用率提升 $n$ 倍。两种流水线协议：

Go-Back-N（GBN）

出错时，从出错的分组开始，连带其后所有分组一起重传。

sequenceDiagram
    participant S as 发送方
    participant R as 接收方
    S->>R: Seq 0
    S->>R: Seq 1
    S->>R: Seq 2（丢失）
    S->>R: Seq 3
    R->>S: ACK 0
    R->>S: ACK 1
    Note over R: 收到 3，但期待 2，丢弃并重发 ACK 1
    R->>S: ACK 1（重复）
    Note over S: 收到重复 ACK → 重传 2, 3, 4...

接收方只需维护一个指针，不需要缓冲乱序包，实现简单；但出一个错要重传一堆，在高丢包率下很浪费。

序号空间要求： $\geq N+1$ 。

Selective Repeat（SR，选择重传）

只重传出错的那一个，接收方缓冲乱序到达的正确分组，等缺失的包补来了再一起交给上层。

序号空间要求： $\geq 2N$ 。

为什么 SR 需要 2N？ 假设 N=4，序号只有 0–4（5个），发送方窗口 [0,1,2,3]，所有 ACK 都丢了，发送方重传 [0,1,2,3]；此时接收方窗口已滑到 [4,0,1,2]。接收方收到序号 0，它搞不清这是重传的旧包还是新一轮的包 0——数据就乱了。序号空间必须是窗口的 2 倍，让两边窗口永不重叠。

	Go-Back-N	Selective Repeat
出错时重传	出错包 + 后续所有	只有出错包
接收方缓冲	不需要	需要
序号空间	$\geq N+1$	$\geq 2N$
适合场景	低丢包率、实现简单	高丢包率、带宽宝贵

五、TCP 报文段结构

TCP 的头部比 UDP 复杂得多，最小 20 字节：

  
    源端口 (16 bit)
    目的端口 (16 bit)
  
    序号 Sequence Number (32 bit)
  
    确认号 Acknowledgment Number (32 bit)
  
    首部长度
    URG
    ACK
    PSH
    RST
    SYN
    FIN
    接收窗口 rwnd (16 bit)
  
    校验和 (16 bit)
    紧急指针 (16 bit)
  
    选项（可变长）
  
    数据（payload）

关键字段：

字段	作用
序号（Seq）	该报文段数据首字节在字节流中的编号（不是分组编号！）
确认号（Ack）	期望收到的下一个字节的编号——隐含"此前全部已收到"
rwnd	接收窗口，告诉对方"我还能接多少字节"，流量控制用
SYN/FIN	建立/关闭连接的信令标志
ACK	确认号字段是否有效（连接建立后几乎总是 1）

Seq 是字节编号这一点非常重要：Seq=1000，数据 500 字节 → 下一段 Seq=1500。序号空间 $2^{32}$ 字节（4 GB），高速链路下会循环，但实际有时间戳选项防止混淆。

六、TCP 可靠传输：超时与快速重传

RTT 估计与超时时间

TCP 动态估算 RTT，避免超时时间太大（等太久）或太小（误触发重传）。

\text{EstimatedRTT} = (1 - \alpha) \cdot \text{EstimatedRTT} + \alpha \cdot \text{SampleRTT} \quad (\alpha = 0.125)

\text{DevRTT} = (1 - \beta) \cdot \text{DevRTT} + \beta \cdot |\text{SampleRTT} - \text{EstimatedRTT}| \quad (\beta = 0.25)

\text{TimeoutInterval} = \text{EstimatedRTT} + 4 \cdot \text{DevRTT}

加上 4 倍标准差作为安全边际——网络波动大时超时时间自动拉长，网络稳定时自动收紧。

快速重传（Fast Retransmit）

超时等待通常要几百毫秒，太慢了。优化：收到 3 个重复 ACK → 立即重传，不等超时。

sequenceDiagram
    participant S as 发送方
    participant R as 接收方
    S->>R: Seg 1
    S->>R: Seg 2（丢失）
    S->>R: Seg 3
    S->>R: Seg 4
    R->>S: ACK 1
    R->>S: ACK 1（重复，收到 Seg 3 但缺 Seg 2）
    R->>S: ACK 1（重复，收到 Seg 4 但缺 Seg 2）
    Note over S: 3 个重复 ACK → 立即重传 Seg 2，不等超时！
    S->>R: Seg 2（重传）
    R->>S: ACK 4（一口气确认到 Seg 4）

3 个重复 ACK 说明后续包已经到达了，只是这一个丢了——大概率是偶发拥塞丢包而非链路故障，及早重传代价小、收益大。

七、TCP 流量控制

目的：防止发送方发得太快，把接收方缓冲区塞满（应用程序来不及消化）。

接收方在每个 ACK 里告知发送方 rwnd（缓冲区剩余空间），发送方始终保证：

\text{LastByteSent} - \text{LastByteAcked} \leq \text{rwnd}

rwnd = 0 的特殊情况：发送方停止发送，但每隔一段时间发送 1 字节的探测段，等接收方缓冲区腾出来后通知自己。（否则双方都在等对方，陷入死锁。）

流量控制 = 点对点的速率匹配，防接收方被"淹死"。和拥塞控制的区别：流量控制关心的是接收端缓冲区，拥塞控制关心的是网络中路由器的缓冲区。

八、TCP 连接管理：握手与挥手

三次握手建立连接

sequenceDiagram
    participant C as 客户端
    participant S as 服务器
    Note over C: CLOSED
    Note over S: LISTEN
    C->>S: SYN（seq=x，随机初始序号）
    Note over C: SYN_SENT
    Note over S: SYN_RCVD
    S->>C: SYN-ACK（seq=y，ack=x+1）
    C->>S: ACK（ack=y+1）
    Note over C,S: ESTABLISHED

为什么必须三次，不能两次？

两次握手只能让服务器确认"客户端能发"，但无法确认"客户端能收"。更重要的是：假设一个延迟很久的旧 SYN 在网络里兜了一圈突然到达服务器，服务器以为是新连接请求，分配资源，开始等数据——但客户端早就不认这个连接了，服务器资源被白白占用。三次握手让双方都确认对方"能收能发"，同时同步各自的初始序号。

四次挥手断开连接

TCP 是全双工的，两个方向需要独立关闭（可以半关闭：我不发了，但还能收）。

sequenceDiagram
    participant C as 客户端
    participant S as 服务器
    C->>S: FIN
    Note over C: FIN_WAIT_1
    S->>C: ACK
    Note over C: FIN_WAIT_2
    Note over S: CLOSE_WAIT（服务器还可以继续发数据）
    S->>C: FIN
    Note over S: LAST_ACK
    C->>S: ACK
    Note over C: TIME_WAIT（等待 2×MSL）
    Note over S: CLOSED
    Note over C: CLOSED（2×MSL 后）

TIME_WAIT 为什么等 2×MSL？

MSL（Maximum Segment Lifetime，报文段最长存活时间，通常 30s–2min）。等待原因有二：

最后一个 ACK 可能丢失 → 服务器超时重发 FIN → 客户端重发 ACK，2×MSL 给了这个来回足够的时间。
让旧连接的所有"网络幽灵包"彻底消散，不干扰使用相同四元组的新连接。

九、TCP 拥塞控制

流量控制防的是接收端被打爆；拥塞控制防的是网络里的路由器被打爆。TCP 靠丢包事件间接感知拥塞，实际发送速率受两个窗口同时约束：

\text{发送窗口} = \min(\text{cwnd},\ \text{rwnd})

AIMD：一图看懂

慢启动 — 每 ACK +1，指数爆发，直到碰上 ssthresh

拥塞避免 — 每 RTT +1 MSS，线性试探带宽上限

快速恢复 — 3×dupACK 触发，折半后直接继续拥塞避免

超时 — 严重拥塞

ssthresh = cwnd/2，cwnd → 1，回到慢启动

3 个重复 ACK — 轻度拥塞

ssthresh = cwnd/2，cwnd → ssthresh，快速恢复

加性增（线性爬）→ 遇到丢包 → 乘性减（折半）→ 再爬。TCP 就这样不断试探网络的极限，既充分利用带宽，又不把路由器打爆。

TCP 吞吐量估算

\text{平均吞吐量} \approx \frac{1.22 \times \text{MSS}}{RTT \cdot \sqrt{L}}

其中 $L$ 是丢包率。RTT 越小、丢包率越低，吞吐量越高——这也是 CDN 的本质价值：低 RTT 直接在 TCP 层放大了有效传输速率。

TCP CUBIC 与 BBR

算法	思路	使用场景
Reno	经典 AIMD，丢包感知拥塞	教科书基础
CUBIC	增长函数是三次曲线，高带宽延迟积下更高效	Linux 默认，跨洋长肥管道
BBR	直接测量瓶颈带宽和传播时延，不依赖丢包	Google 数据中心、YouTube

BBR 是一次思路上的跃进：Reno/CUBIC 以"丢包"作为拥塞的代理——但丢包出现时，路由器缓冲区早已满了，拥塞其实早发生了。BBR 直接估计带宽和延迟，在队列积压之前就主动调节，兼顾低延迟和高吞吐。

链路层（Link Layer）

十、链路层概述

链路层负责在相邻节点之间（同一段链路上的两个节点，可能是主机-路由器、路由器-路由器、主机-交换机）可靠地传输帧。

链路层提供的服务（具体协议可能不全提供）：

服务	说明
成帧（Framing）	把网络层数据报封装成帧，加头尾
链路接入（Link Access）	协调多个节点共享一条链路（MAC 协议）
可靠传输	针对高误码率链路（如 WiFi）提供，有线链路一般不做（交给 TCP）
错误检测与纠正	发现并（可选地）纠正传输中产生的比特错误

链路层实现在网卡（NIC，Network Interface Card） 上，一部分是硬件（成帧、错误检测、MAC），一部分是软件驱动（上层接口）。

十一、错误检测与纠正

奇偶校验（Parity Bit）

单比特奇偶：附加 1 bit，使得整个数据块中 1 的个数为偶数（偶校验）。能检测奇数个比特翻转，不能纠错。

二维奇偶：把数据排成矩阵，对每行每列各加一个奇偶位。不仅能检测单比特错误，还能定位并纠正它（行列交叉点即出错位置）。

CRC（循环冗余校验）

链路层最常用的错误检测方案，能检测所有长度 $\leq r$ 的突发错误（r 是 CRC 阶数，典型值 32）。

思想：把数据 $D$ （ $d$ bit）看成一个多项式，除以事先约定的生成多项式（Generator） $G$ （ $r+1$ bit），余数 $R$ （ $r$ bit）就是校验码，附在 $D$ 后面发送。

\underbrace{D \cdot 2^r}_{\text{左移 r 位}} \oplus R = \underbrace{nG}_{\text{能被 G 整除}}

接收方用同一个 $G$ 去除收到的帧，余数为 0 → 无误；非 0 → 出错。

直觉：CRC 就像一个哈希，但设计得让任何 $\leq r$ bit 的连续翻转都必然改变这个哈希值，所以极难漏检。以太网、WiFi 都用 CRC-32（32 bit 校验码）。

十二、多路访问控制（MAC）协议

当多个节点共享同一条广播链路时（如以太网、WiFi），需要协议来协调"谁在什么时候发"，否则多人同时发就会碰撞。

信道划分协议（Channel Partitioning）

把信道静态分给每个节点，互不干扰，但空闲时浪费资源——和电路交换的问题一样。

方式	原理	适用
TDMA	时间分槽，每节点固定时隙	蜂窝网
FDMA	频率分段，每节点固定频段	有线电视、老式移动网
CDMA	每节点用不同扩频码，并行传输	3G

随机接入协议（Random Access）

节点想发就发，碰撞了就处理。核心思想是统计复用——利用流量突发性，让信道空闲时任何人都能用。

CSMA/CD（有线以太网）

CSMA（Carrier Sense Multiple Access）：发前先听信道，空闲才发。但由于传播延迟，两个节点可能同时以为信道空闲而开始发送，导致碰撞。

CD（Collision Detection）：发送的同时继续监听。检测到碰撞立即停止，发送 Jam 信号（48 bit）告知所有人，然后**指数退避（Binary Exponential Backoff）**等待随机时间再重试。

flowchart TD
    A[有数据要发] --> B{信道空闲?}
    B -- 否 --> C[等待，持续监听]
    C --> B
    B -- 是 --> D[开始发送帧]
    D --> E{检测到碰撞?}
    E -- 否 --> F[发送完成]
    E -- 是 --> G[立即停止\n发送 Jam 信号]
    G --> H["指数退避\n第 n 次碰撞：随机等待 0~2n-1 个时隙"]
    H --> I{重试次数 <= 16?}
    I -- 是 --> B
    I -- 否 --> J[放弃，报告上层]

最小帧长：为了让发送方在帧还没发完时就能检测到碰撞（最远两点来回传播时延内），以太网规定最小帧长 64 字节。帧太短，可能发完了才知道有碰撞——已经来不及了。

CSMA/CA（无线 WiFi）

无线无法做碰撞检测（自己发的信号会淹没别人的，"听"不到碰撞），改为碰撞避免（Collision Avoidance）。

flowchart TD
    A[有数据要发] --> B{信道空闲\n持续 DIFS 时间?}
    B -- 否 --> C[等待信道变空闲\n再等随机退避时间]
    C --> B
    B -- 是 --> D[发送帧]
    D --> E{收到 ACK?}
    E -- 是 --> F[发送成功]
    E -- 否 --> G[指数退避，重试]
    G --> B

WiFi 还引入了 RTS/CTS（Request-to-Send / Clear-to-Send） 机制来解决隐藏终端问题：

sequenceDiagram
    participant A as 节点 A
    participant AP as 接入点 AP
    participant B as 节点 B（A 看不见）
    A->>AP: RTS（我要发数据给你）
    AP->>A: CTS（广播，所有人都听到）
    Note over B: 听到 CTS，知道信道被占用，保持沉默
    A->>AP: 数据帧
    AP->>A: ACK

轮询协议（Taking-Turns）

轮询（Polling）：主节点依次邀请每个从节点发送，无碰撞，但主节点是瓶颈，引入轮询延迟。

令牌环（Token Ring）：令牌在环形链路上循环传递，持有令牌才能发送。有序但令牌丢失会导致整环瘫痪。

十三、链路层寻址与 ARP

MAC 地址

网络层用 IP 地址（逻辑地址，可变），链路层用 MAC 地址（物理地址，48 bit，烧在网卡里）。

MAC 地址格式：AA:BB:CC:DD:EE:FF（十六进制，冒号分隔）。前 24 bit 是厂商 OUI，后 24 bit 是厂商自分配。FF:FF:FF:FF:FF:FF 是广播地址。

类比：IP 地址像邮政地址（根据居住地变化），MAC 地址像身份证号（出厂确定，不随地点变化）。路由器转发靠 IP 地址，帧在单段链路上传输靠 MAC 地址。

ARP（Address Resolution Protocol）

主机知道目标 IP，但要发帧必须知道目标 MAC。ARP 负责把 IP 映射到 MAC。

sequenceDiagram
    participant A as 主机 A
    participant LAN as 局域网广播域
    participant B as 主机 B
    participant C as 主机 C
    Note over A: 知道 IP-B，不知道 MAC-B
    A->>LAN: ARP 广播: 谁的 IP 是 192.168.1.2？
    Note over C: 不是我，忽略
    B->>A: ARP 单播回复: 是我，MAC=AA:BB:CC:DD:EE:FF
    Note over A: 缓存 IP→MAC 到 ARP 表（TTL 约 20 分钟）

跨子网发帧：发往不在同一子网的 IP，先发给默认网关（路由器）。帧的目的 MAC 填路由器接口的 MAC，但 IP 数据报里的目的 IP 仍是最终目标。每经过一个路由器，帧的 MAC 地址重写，IP 地址不变。

graph LR
    A["主机 A\nIP-A, MAC-A"] -->|"目的MAC=MAC-路由器\n目的IP=IP-B"| R["路由器\nMAC-left, MAC-right"]
    R -->|"目的MAC=MAC-B\n目的IP=IP-B"| B["主机 B\nIP-B, MAC-B"]

十四、以太网

以太网是有线局域网的统治性标准，从 10 Mbps 到今天的 400 Gbps，帧格式基本没变过。

以太网帧结构

前导码
7 B
SFD
1 B
目的 MAC
6 B
源 MAC
6 B
类型
2 B
数据
46–1500 B
CRC
4 B

字段	大小	说明
前导码 + SFD	8 B	7 字节 `10101010...` 用于同步时钟，最后 1 字节 `10101011` 表示帧开始
目的/源 MAC	各 6 B	帧在这一段链路上的接收方和发送方
类型（Type）	2 B	上层协议：0x0800=IPv4，0x86DD=IPv6，0x0806=ARP
数据	46–1500 B	最大 1500 B（MTU）；最小 46 B（凑够 64 B 最小帧长）
CRC	4 B	CRC-32 校验码，出错直接丢帧（不通知发送方）

以太网是无连接、不可靠的链路层协议——不握手，不确认，CRC 错了就静默丢弃。可靠传输的任务交给上层 TCP。

十五、交换机与自学习

交换机 vs 路由器

	交换机（Switch）	路由器（Router）
工作层	链路层（第 2 层）	网络层（第 3 层）
寻址依据	MAC 地址	IP 地址
转发表	交换表（自学习）	路由表（路由协议）
隔离广播域	❌（同一广播域）	✅
典型场景	局域网内部连接	不同网络之间转发

自学习（Self-Learning）

交换机不需要人工配置，完全靠自学习建立交换表。

sequenceDiagram
    participant A as 主机 A（端口 1）
    participant SW as 交换机
    participant B as 主机 B（端口 3）
    participant C as 主机 C（端口 4）
    A->>SW: 帧（src=MAC-A, dst=MAC-B）
    Note over SW: 学习：MAC-A → 端口 1\n查表：不知道 MAC-B 在哪
    SW->>B: 泛洪（Flooding）到端口 2, 3, 4
    SW->>C: 泛洪（Flooding）
    B->>SW: 帧（src=MAC-B, dst=MAC-A）
    Note over SW: 学习：MAC-B → 端口 3\n查表：MAC-A → 端口 1，精准转发
    SW->>A: 单播转发到端口 1

自学习规则：

收到帧时，把 源 MAC + 到达端口 记入交换表（带 TTL，一般几分钟）
查表找目的 MAC：找到了 → 精准转发到对应端口；找不到 → 泛洪（Flood） 到所有其他端口

交换机还会自动过滤（Filter）：如果目的 MAC 和源 MAC 在同一端口，说明同侧，帧不用转发，直接丢弃。

VLAN（Virtual LAN）

一台物理交换机可以划分为多个逻辑 LAN，不同 VLAN 的广播互相隔离，跨 VLAN 通信需要经过路由器。

graph TD
    subgraph SW["物理交换机"]
        subgraph V10["VLAN 10 - 研发部"]
            P1[端口1] & P2[端口2] & P3[端口3]
        end
        subgraph V20["VLAN 20 - 财务部"]
            P4[端口4] & P5[端口5]
        end
        Trunk["Trunk 端口\n连路由器"]
    end
    B10["广播 VLAN10"] --> P1 & P2 & P3
    B20["广播 VLAN20"] --> P4 & P5
    V10 -.- |"跨VLAN需过路由器"| V20

十六、无线局域网：802.11（WiFi）

基本架构

graph TD
    subgraph 基础设施模式
        AP["接入点 AP\n（AP = 带 MAC 地址的桥接器）"]
        STA1["站点 STA1\n（你的笔记本）"] --- AP
        STA2["站点 STA2\n（手机）"] --- AP
        AP --- Router["路由器/互联网"]
    end

802.11 帧结构特殊性

WiFi 帧有 4 个 MAC 地址（而以太网只有 2 个），用于区分不同场景：

地址 1：接收方 MAC
地址 2：发送方 MAC
地址 3：路由器（网关）MAC
地址 4：仅在 ad-hoc 模式下使用

为什么需要 3 个地址？因为 AP 本身只是一个"无线转有线"的桥接器，不修改 IP，但帧里需要同时知道"谁在空中发给我（地址2）"、"我要在空中发给谁（地址1）"、以及"这帧最终要去的路由器（地址3）"。

速率自适应（Rate Adaptation）

WiFi 信号质量随距离、障碍物变化。802.11 会根据信噪比自动切换调制方式：

graph LR
    A["信号强\n（近距离）\nQAM-256\n最高速率"] --> B["信号中等\nQAM-64"] --> C["信号弱\n（远距离）\nBPSK\n最低速率但最稳"]

你离 WiFi 路由器越远，速率不是线性下降，而是阶梯式跳到下一个调制方案——这就是为什么有时候信号"还有两格"但网速突然就慢了很多。

关键术语速查

传输层

英文	中文	一句话解释
Port Number	端口号	标识同一主机上不同进程的 16 bit 整数
Multiplexing / Demultiplexing	多路复用 / 解复用	多进程共享网络 / 数据分发到正确进程
UDP	用户数据报协议	无连接、不可靠、低延迟的传输协议
TCP	传输控制协议	面向连接、可靠、有序字节流传输协议
Stop-and-Wait	停止等待	发一个等 ACK 才发下一个，效率极低
Go-Back-N	回退 N	出错时重传出错包及其后所有包
Selective Repeat	选择重传	只重传出错的那一个包，需要接收方缓冲乱序
Sequence Number	序号	TCP 字节流中每个字节的编号
ACK / Fast Retransmit	确认 / 快速重传	3 个重复 ACK 触发立即重传，不等超时
Flow Control	流量控制	用 rwnd 防止接收方缓冲区被打爆
Congestion Control	拥塞控制	用 cwnd 防止网络路由器缓冲区被打爆
cwnd / ssthresh	拥塞窗口 / 慢启动阈值	发送方对网络容量的估计
AIMD	加性增乘性减	TCP 拥塞控制核心策略，形成锯齿形窗口变化
Three-Way Handshake	三次握手	SYN → SYN-ACK → ACK，建立 TCP 连接
TIME_WAIT	时间等待	关闭后等待 2×MSL，让残余包消散
BBR	瓶颈带宽往返时延	Google 的新一代拥塞控制，直接估计带宽而非依赖丢包

链路层

英文	中文	一句话解释
NIC	网卡	链路层的实现硬件
CRC	循环冗余校验	链路层主流错误检测，能检测突发比特错误
MAC Protocol	介质访问控制协议	协调多节点共享同一链路
CSMA/CD	载波监听多路访问/碰撞检测	有线以太网的 MAC 协议
CSMA/CA	载波监听多路访问/碰撞避免	WiFi 的 MAC 协议（无线不能检测碰撞）
Exponential Backoff	指数退避	碰撞后随机等待，重试次数越多等待范围越大
MAC Address	MAC 地址	48 bit 硬件地址，帧在单段链路上寻址用
ARP	地址解析协议	把 IP 地址解析为 MAC 地址
Ethernet Frame	以太网帧	最小 64 B，最大 1518 B，含 CRC-32
MTU	最大传输单元	以太网帧数据部分最大 1500 字节
Switch	交换机	链路层设备，靠 MAC 地址转发帧，自学习
Flooding	泛洪	交换机不知道目的 MAC 时，向所有端口广播
VLAN	虚拟局域网	一台物理交换机分割成多个逻辑隔离的 LAN
Hidden Terminal	隐藏终端	两个节点互相看不见，都以为信道空闲，导致碰撞
RTS/CTS	请求发送/允许发送	WiFi 解决隐藏终端的握手机制
Rate Adaptation	速率自适应	WiFi 根据信号质量自动切换调制速率

Loading comments...