第 17 讲：网络层数据平面、调度与流量监管

一、网络层概览

1.1 唯一的职责

把报文段从发送主机送到接收主机。

发送方：把传输层报文段封装进数据报。接收方：把报文段交付给传输层。 ⭐ 路径上的每一台路由器：检查数据报头部，转发。

⚠️ 注意：网络层协议运行在每一台主机和每一台路由器上——这是唯一一个如此普遍的层（传输层只在端系统上）。

1.2 两个平面

回顾第 2 讲的核心区分：

	数据平面（Data Plane）	控制平面（Control Plane）
做什么	把分组从输入端口移到输出端口	决定分组走哪条端到端路径
范围	单台路由器内部	全网
时间尺度	纳秒	秒到分钟
本课	Unit 4（第 17–19 讲）	Unit 5（第 20–22 讲）

1.3 控制平面的两种实现

方式 1：每路由器控制（传统）

每台路由器上运行路由算法，彼此交换信息，各自算出自己的转发表

方式 2：逻辑集中控制（SDN） ⭐

一个远程控制器计算并下发转发表到所有路由器

        ┌──────────────────────┐
        │   远程 SDN 控制器      │
        └───┬────┬────┬────────┘
            │    │    │  （下发流表）
        ┌───▼┐┌──▼─┐┌─▼──┐
        │ R1 ││ R2 ││ R3 │   ← 路由器退化为"哑"的转发设备
        └────┘└────┘└────┘

第 22 讲会详细讲。

1.4 IP 的服务模型：什么都不保证

可能的保证	IP 提供吗
保证交付	❌
有界时延交付	❌
保证最小带宽	❌
有序交付	❌
无拥塞	❌

⭐ IP 提供的叫「尽最大努力」（best-effort）。

为什么没有部署更强的服务模型？（IETF 曾定义过 IntServ、DiffServ）

可扩展性：为每条流保留资源需要路由器维护每流状态——核心路由器上有数百万条流
计费与协商：跨越多个 ISP 的服务质量保证需要商业协议，难以达成
⭐ 过度配置更便宜：与其做复杂的 QoS，不如直接多买带宽
应用自己适应了：DASH（第 8 讲）、拥塞控制（第 16 讲）证明了端系统能在 best-effort 上做出可用的服务

📌 **这是一个「简单的方案赢了」的经典案例。**互联网选择了最弱的服务模型，反而因此可扩展、可演化、可负担。

二、路由器体系结构

        ┌─────────────────────────────────────────┐
        │           路由选择处理器                  │  ← 控制平面（软件，毫秒级）
        │      （运行路由算法、管理转发表）           │
        └─────────────┬───────────────────────────┘
                      │ 下发转发表
    ┌─────────────────▼───────────────────────────┐
    │  输入端口              交换结构       输出端口  │  ← 数据平面（硬件，纳秒级）
    │ ┌──────┐            ┌────────┐    ┌──────┐ │
    │→│查表  │───────────▶│        │───▶│排队  │→│
    │ └──────┘            │        │    └──────┘ │
    │ ┌──────┐            │ Switch │    ┌──────┐ │
    │→│查表  │───────────▶│ Fabric │───▶│排队  │→│
    │ └──────┘            │        │    └──────┘ │
    │ ┌──────┐            │        │    ┌──────┐ │
    │→│查表  │───────────▶│        │───▶│排队  │→│
    │ └──────┘            └────────┘    └──────┘ │
    └─────────────────────────────────────────────┘

⭐ 关键的时间尺度对比：

路由算法：软件实现，毫秒到秒级
转发决策：⭐ 必须在【纳秒】级完成

**为什么必须纳秒级？**一条 100 Gbps 链路，最小的 64 字节以太网帧只需 5.12 纳秒就传完一个。路由器必须在这个时间内完成一次转发决策，否则就跟不上线速（line rate）。

📌 这个约束决定了路由器的一切设计：查表必须硬件化、不能有复杂逻辑、不能有软件循环。

三、输入端口：最长前缀匹配

3.1 转发表的形式

转发表不是「一个 IP 地址一行」（那会有 2³² 行），而是按前缀聚合：

目的地址前缀                    输出链路
11001000 00010111 00010*** ***   →  0
11001000 00010111 00011000 ***   →  1
11001000 00010111 00011*** ***   →  2
其他                             →  3

3.2 最长前缀匹配规则 ⭐

当多个表项都匹配时，使用前缀最长的那一条。

例题：目的地址 11001000 00010111 00011000 10101010

表项 1: 11001000 00010111 00010*** ***   → 前 21 位是 ...00010，不匹配（第 21 位是 1）
表项 2: 11001000 00010111 00011000 ***   → 前 24 位完全匹配 ✅ 长度 24
表项 3: 11001000 00010111 00011*** ***   → 前 21 位匹配 ✅ 长度 21

⭐ 表项 2 更长 → 输出到链路 1

为什么用最长前缀匹配而不是精确匹配？

地址聚合：一条 192.0.2.0/24 覆盖 256 个地址，表项数量减少几个数量级
支持例外：可以先有一条粗粒度的默认路由，再用更长的前缀覆盖特例
⭐ 它是 CIDR 得以工作的基础（第 18 讲）

3.3 TCAM：用硬件在一个时钟周期内查表

普通内存按地址查内容；内容可寻址存储器（CAM） 按内容查地址。

TCAM（Ternary CAM） 的每一位可以是 0、1 或 X（don’t care）——恰好对应前缀里的 *。

⭐ TCAM 并行比较所有表项，一个时钟周期返回最长匹配结果

优点：O(1) 查找，与表项数量无关
缺点：极其昂贵、功耗高、容量有限（典型 100 万条表项）

📌 这个容量限制是一件大事：全球 BGP 路由表在 2014 年突破 512K 条时，大量老旧路由器的 TCAM 溢出，造成了真实的全球性网络故障（业内称为 512K Day）。第 21 讲会回到这个话题。

四、交换结构

把分组从输入端口搬到输出端口。三代技术：

4.1 经内存交换（第一代）

输入端口 → [CPU 读入内存] → [CPU 写到输出端口]

由 CPU 在软件中完成，每个分组要过两次系统总线
⭐ 交换速率受限于内存带宽的一半
传统 PC 路由器就是这样

4.2 经总线交换

输入 ═══════╦═══════╦═══════╦══ 共享总线
            ▼       ▼       ▼
          输出1   输出2   输出3

无需 CPU 介入，输入端口给分组打上标签直接发到总线
⚠️ 一次只能有一个分组通过 → 总线带宽就是交换速率上限
适合企业级路由器（几十 Gbps）

4.3 经互连网络交换（Crossbar）⭐

        out1  out2  out3
         │     │     │
 in1 ────┼─────┼─────┼──
         ╳     │     │
 in2 ────┼─────╳─────┼──
         │     │     │
 in3 ────┼─────┼─────╳──

⭐ 多个分组可以【同时】通过，只要它们的输出端口不同

N×N 的 crossbar 理论上可以同时转发 N 个分组
现代高端路由器都用它，并且常做成多级（Clos 网络），在数据中心里也是同样的结构（第 24 讲）

五、排队：队头阻塞

5.1 输出端口排队

到达速率 > 输出链路速率  →  排队  →  可能丢包

这就是第 2、3 讲说的排队时延与丢包的物理位置。

5.2 输入端口排队与队头阻塞（HOL Blocking）⭐

当交换结构的速率慢于输入端口速率之和时，输入端口也需要排队。

这时会出现一个反直觉的问题：

输入端口 1 队列：  [→出口 A][→出口 B]
输入端口 2 队列：  [→出口 A]

⭐ 若端口 1 队头的分组要去 A，而端口 2 的分组也要去 A
   → 只有一个能走
   → 端口 1 队头被阻塞
   → ⚠️ 排在它后面的、要去【空闲的出口 B】的分组，也走不了！

队头阻塞（Head-of-Line Blocking）：队首分组因输出端口冲突而等待，导致队列中原本可以被转发的后续分组也被迫等待。

📌 **你在第 6 讲见过这个词。**HTTP/1.1 的应用层队头阻塞、TCP 的传输层队头阻塞、这里的交换结构队头阻塞——同一个结构性问题在三个完全不同的层面重复出现。

理论结果：随机流量下，纯输入排队的最大吞吐量只有约 58.6%（Karol et al., 1987）。

解法：虚拟输出队列（VOQ）

每个输入端口为【每一个输出端口】各维护一个独立队列
→ 队头不再互相阻塞
→ 配合调度算法（如 iSLIP），吞吐量可达 100%

⭐ 注意解法的形式：把一个共享队列拆成 N 个独立队列。这与 HTTP/2 的多路复用流、QUIC 的独立流是同一个思想。

5.3 缓冲区该配多大

经典法则（RFC 3439）：

B = RTT × C
   （RTT 取典型值 250 ms，C 是链路容量）

对一条 10 Gbps 链路，这意味着 2.5 Gbit ≈ 312 MB 的缓冲区。

Stanford 的修正（Appenzeller et al., 2004）：当链路上有 N 条独立的 TCP 流时，它们的锯齿不同步，因此：

⭐ B = RTT × C / √N

N = 10000 时，缓冲区只需 1/100，即约 3 MB。

⚠️ 而 bufferbloat（第 16 讲）告诉我们：缓冲区太大反而有害。

🎯 缓冲区大小是一个真正的权衡：太小 → 无法吸收突发，丢包率高，链路利用率下降太大 → 排队时延巨大，基于丢包的 TCP 无法及时收到信号 正确答案不是某个数字，而是配合 AQM（CoDel）动态管理驻留时间。

六、分组调度

输出队列里有多个分组，先发哪个？

6.1 FIFO（先进先出）

[分组1][分组2][分组3] → 按到达顺序发送

最简单，互联网默认
无法区分服务

6.2 优先级排队（Priority Queuing）

高优先级队列: [VoIP][VoIP]     → ⭐ 优先发送
低优先级队列: [下载][下载][下载] → 高优先级队列空了才发

⚠️ 饥饿风险：高优先级流量持续存在时，低优先级永远得不到服务

6.3 轮转（Round Robin）

类 1: [A1][A2]
类 2: [B1]
类 3: [C1][C2][C3]

发送顺序：A1 B1 C1 A2 C2 C3 ...

公平，无饥饿
⚠️ 不考虑分组大小：发大包的类实际占用更多带宽

6.4 加权公平排队（WFQ）⭐

每个类 i 分配权重 w_i
类 i 获得的带宽份额 = w_i / Σw_j

⭐ 按【比特数】而非分组数计量 → 消除了分组大小的影响

这是最重要的调度算法，是 QoS、DiffServ 和现代 AQM（FQ-CoDel）的基础。

6.5 调度与网络中立性

⚠️ 分组调度不只是技术问题。

网络中立性（Net Neutrality）：网络运营商是否应当被允许对不同来源、不同类型的流量区别对待？

调度器在技术上完全有能力：

给自家视频服务优先级，给竞争对手降速
对未付费的内容提供商限速
按应用类型（P2P、视频）差别处理

这是一个政策问题而非技术问题：技术手段早已具备，争论的是是否应当使用它们。美国的相关监管规则在 2015 年确立、2017 年撤销、此后持续反复；欧盟与许多国家有各自不同的框架。

📌 一个工程师应当理解的点：**「技术上做得到」和「应当去做」是两个独立的判断。**这门课教你前者；后者需要你在职业生涯中自己形成判断。

七、流量监管与整形：令牌桶

7.1 三个容易混淆的概念

上一节的调度回答的是「多条流竞争同一条输出链路时，谁先走」。但还有一个独立的问题：一条流自己是不是发得太多了。

概念	英文	回答的问题	超出约定时怎么办
调度	scheduling	谁先走	——
⭐ 监管	policing	这条流超速了吗	⭐ 丢弃或降级标记，不缓存
⭐ 整形	shaping	同上	⭐ 先缓存，延后发出

⭐ 监管与整形的区别只有一个字：缓存。监管不缓存，所以不增加时延但会丢包；整形缓存，所以不丢包但增加时延，且需要缓冲区。运营商在入口对客户流量做监管（你超了是你的事），发送端在出口对自己的流量做整形（免得到了对面被丢）。

7.2 令牌桶

刻画「允许多快」不能只给一个速率——因为真实流量总是有突发的，一个严格的速率上限会把正常的突发也砍掉。令牌桶用两个参数同时表达「长期速率」和「允许多大突发」。

令牌桶 (r, b)：

  r = 令牌生成速率（如 字节/秒 或 bps）
  b = 桶容量（最多能攒下多少令牌）

  · 令牌以恒定速率 r 注入桶中；桶满则新令牌溢出丢弃
  · 发送一个 p 字节的分组，需要从桶中取走 p 个令牌
  · 令牌不足时：监管 → 丢弃或降级；整形 → 等到令牌够了再发

⭐ 令牌桶最重要的性质（这是所有计算题的出发点）：

任意长度为 t 的时间区间内，通过监管器的流量上限：

        流量(t) ≤ r · t + b

  · b   是「攒下来的突发额度」——最多一次性放行 b
  · r·t 是这段时间新产生的令牌
  · 长期看（t 很大时）平均速率被限制在 r

桶容量 b 的物理含义：一条长时间安静的流，可以把令牌攒满，然后瞬间发出 b 这么多数据。所以 b 就是被允许的最大突发量。b 越大越宽容，b = 1 个分组时几乎不允许任何突发。

7.3 漏桶：另一种形状

**漏桶（leaky bucket）**常和令牌桶一起考，但行为相反：

	漏桶	令牌桶
桶里装的是	⭐ 数据	⭐ 令牌（许可）
输出速率	严格恒定 `r`	允许突发，长期均值 `r`
桶满时	丢弃新到的数据	丢弃新到的令牌（数据不受影响）
效果	完全消除突发	⭐ 保留最多 `b` 的突发

⭐ 一句话记忆：漏桶存数据，令牌桶存许可。 漏桶把流量彻底抹平，令牌桶在长期速率之外留了一个突发额度——现实中令牌桶用得多得多，因为把突发全部抹平既不必要也损害应用性能。

7.4 令牌桶 + WFQ = 可证明的时延上限

令牌桶单独用只能限速。但它和上一节的 WFQ 调度组合起来，能给出一个数学上可证明的排队时延上限——这是 QoS 保证的理论基础：

若一条流：
  · 被令牌桶 (r, b) 监管
  · 经过 WFQ 调度器，被保证的最小速率为 R（要求 R ≥ r）

则该流在这个调度器上的最大排队时延：

        d_max = b / R

⭐ 直觉：最坏情况是这条流攒满了令牌，一次性涌入 b 这么多数据。这批数据以保证速率 R 排出去，最后一个比特要等 b/R。因为令牌桶保证了再也不会有比这更糟的突发，所以这个界是紧的。

📌 这个结论的意义：它把「网络能不能给出确定的时延保证」变成了一个可以计算的工程问题——只要入口做监管、内部做 WFQ，时延上限就是可承诺的。IntServ 的整个设计就建立在这上面。

7.5 IntServ 与 DiffServ：两次尝试

既然理论上可行，为什么今天的互联网仍然基本是尽力而为？

IntServ（综合服务，1994）——逐流预留。应用先用 RSVP 信令沿路径向每台路由器申请资源，路由器做接纳控制（能满足就答应，不能就拒绝），并为每条流维护状态。

⭐ 它失败在可扩展性：骨干路由器上同时存在数百万条流，逐流维护状态、逐流调度在核心网根本做不到。而且它要求路径上每一台路由器都支持 RSVP——只要有一台不支持，保证就断了。

DiffServ（区分服务，1998）——放弃逐流，改为分类。

边缘路由器（复杂、流数量少）：
    分类 → 监管（令牌桶）→ 在 IP 头的 DS 字段写入 DSCP 标记（6 位）

核心路由器（简单、速度快）：
    只看 DSCP，按对应的 PHB（逐跳行为）转发，不知道任何「流」的存在

⭐ 这是「复杂性放在边缘、核心保持简单」这条原则的又一次体现——和第 2 讲分组交换、第 4 讲端到端原则是同一个思路。

两类主要 PHB：

EF（加速转发）：低时延、低丢包、低抖动。实现上通常是严格优先级队列 + 严格限速（防止它饿死别人）。用于 VoIP。
AF（确保转发）：4 个类别 × 3 级丢弃优先级，拥塞时先丢标记为高丢弃优先级的分组。

⚠️ 注意 PHB 只规定「单跳的行为」，不是端到端保证。端到端的服务质量要靠运营商在自己网络内把每一跳都配置好来组合出来——⭐ 这也是为什么 DSCP 标记在跨越 AS 边界时通常被直接清零：你无法要求别人的网络尊重你打的标记。

为什么最终还是尽力而为占主导：

⭐ 超额供给（over-provisioning）更便宜——带宽的降价速度长期快于部署和运维 QoS 机制的成本。「把链路加粗」几乎总是比「精细调度」更划算。
跨 AS 的 QoS 需要商业协调与计费机制，而 BGP（第 21 讲）根本不传递任何 QoS 承诺。
⭐ 应用层自己适应了——DASH 调码率、RTCP 反馈调编码、CDN 把内容搬到用户身边，需求在应用层被消化掉了。
网络中立性的监管争议使差别对待流量在政策上敏感（第 6 节末已提到）。

📌 但 DiffServ 并没有死：它在单一管理域内大量使用——企业内网、运营商网内的 VoLTE 语音承载、数据中心内部。⭐ 规律是：QoS 在你能控制全程的地方有效，在需要跨越信任边界的地方失效。

八、例题（Worked Example）

题目：某路由器的转发表如下：

前缀                    输出接口
1.  200.15.0.0/16        A
2.  200.15.16.0/20       B
3.  200.15.16.0/24       C
4.  0.0.0.0/0            D（默认路由）

判断以下目的地址的输出接口：

(a) 200.15.16.5 (b) 200.15.20.9 (c) 200.15.200.1 (d) 172.16.0.1

解答：

先把前缀转成二进制第三字节来比较：

200.15.16.0/20  → 前 20 位：200.15.0001****
200.15.16.0/24  → 前 24 位：200.15.00010000

(a) 200.15.16.5（第三字节 16 = 00010000）

/16 匹配 ✅  长度 16
/20 匹配 ✅  长度 20（第三字节高 4 位 0001 ✓）
/24 匹配 ✅  长度 24（第三字节完全等于 16 ✓）
默认 匹配 ✅  长度 0

⭐ 最长 = /24  →  接口 C

(b) 200.15.20.9（第三字节 20 = 00010100）

/16 匹配 ✅
/20 匹配 ✅（高 4 位 0001 ✓）
/24 ❌（20 ≠ 16）

⭐ 最长 = /20  →  接口 B

(c) 200.15.200.1（第三字节 200 = 11001000）

/16 匹配 ✅
/20 ❌（高 4 位 1100 ≠ 0001）
/24 ❌

⭐ 最长 = /16  →  接口 A

(d) 172.16.0.1

只有默认路由匹配  →  接口 D

📌 这道题的模式在期中期末都会出现。做题步骤固定：① 把地址和每条前缀的相关字节转成二进制；② 逐条检查前缀位是否全部相同；③ 在所有匹配项中选掩码最长的。

九、随堂自测

数据平面和控制平面在时间尺度上相差多少个数量级？为什么转发必须是纳秒级？
IP 提供哪些服务保证？为什么更强的服务模型（IntServ）没有被部署？
为什么用最长前缀匹配而不是精确匹配？
TCAM 的优点和缺点分别是什么？512K Day 是怎么回事？
三种交换结构各自的吞吐量瓶颈是什么？
什么是队头阻塞？在本课程中它出现过几次？VOQ 如何解决它？
缓冲区配 RTT×C 还是 RTT×C/√N？为什么这两个公式都不是最终答案？
WFQ 相比轮转的关键改进是什么？
⭐ 监管和整形的区别是什么？只有一个字。
令牌桶 (r, b) 中，b 的物理含义是什么？写出任意区间 t 内的流量上限公式。
漏桶和令牌桶，桶里装的分别是什么？
⭐ 为什么 IntServ 失败而 DiffServ 至今仍在用？各自把复杂性放在了哪里？

十、本讲要点回顾

网络层运行在每一台主机和每一台路由器上，只做一件事：主机到主机的交付。
数据平面（纳秒、硬件） vs 控制平面（秒、软件）。
IP 是 best-effort，什么都不保证——这个"弱"恰恰是它可扩展的原因。
转发用最长前缀匹配，靠 TCAM 在一个时钟周期内完成。
三代交换结构：内存（受内存带宽限制）→ 总线（受总线带宽限制）→ crossbar（可并行）。
⭐ 输入排队会产生队头阻塞，纯输入排队吞吐量上限约 58.6%，VOQ 是解药。
缓冲区大小是吸收突发与 bufferbloat 之间的权衡。
调度：FIFO（默认）、优先级（有饥饿）、轮转（不看包长）、WFQ（按比特加权）。
调度能力使网络中立性成为一个真实的政策议题。

⭐ 调度管「谁先走」，监管管「你超速了吗」；监管与整形只差一个字：缓存（监管丢包不加时延，整形加时延不丢包）。
令牌桶 (r, b)：任意区间 t 内流量 ≤ r·t + b；⭐ b 就是被允许的最大突发量。
⭐ 漏桶存数据（输出恒定），令牌桶存许可（允许突发）。
令牌桶 (r,b) + 保证速率 R 的 WFQ → 最大排队时延 b/R——QoS 保证的理论基础。
⭐ IntServ 逐流预留，死于状态爆炸；DiffServ 边缘分类打标、核心只看 DSCP，是「复杂性放边缘」的又一次体现。
互联网仍以尽力而为为主：超额供给更便宜、跨 AS 无法协调、应用层已自行适应。⭐ QoS 在能控制全程的地方才有效。

十一、自测答案

1. 相差约 6 个数量级（纳秒 vs 毫秒）。转发必须纳秒级，是因为要跟上链路的线速：100 Gbps 链路上一个最小的 64 字节以太网帧只占 5.12 ns，若转发决策慢于此，分组就会堆积，路由器无法在满负载下工作。这个约束迫使转发路径必须完全硬件化。

2. IP 不保证交付、不保证时延上界、不保证带宽、不保证有序、不保证无拥塞——即 best-effort。更强模型未被部署的原因：① 可扩展性——每流资源预留要求核心路由器维护数百万条流状态；② 跨 ISP 的计费与协商难以达成商业一致；③ 过度配置带宽通常比部署复杂 QoS 更便宜；④ 端系统（自适应码率、拥塞控制）已经证明能在 best-effort 之上构建出可用的服务。

3. ① 地址聚合：一条 /24 前缀覆盖 256 个地址，一条 /8 覆盖 1600 万个，使转发表规模从理论上的 2³² 降到几十万量级；② 支持例外：可以用一条粗前缀作为通用规则，再用更长的前缀为特定子网指定不同出口，无需枚举；③ 它是 CIDR 无类别编址得以工作的基础机制。

4. 优点：O(1) 查找，一个时钟周期内并行比较所有表项并返回最长匹配，与表项数量无关。缺点：昂贵、功耗高、容量有限。512K Day（2014 年 8 月）：全球 BGP 路由表条目数突破 512K，而许多在用路由器的 TCAM 默认只为 IPv4 路由分配了 512K 条目，溢出后路由被丢弃或转入软件转发，造成大范围的性能崩溃与连通性故障。

5. 经内存：受内存带宽限制，且每个分组要跨系统总线两次，实际交换速率约为内存带宽的一半。经总线：受总线带宽限制，一次只能有一个分组通过。Crossbar：理论上可同时转发 N 个分组（只要输出端口不冲突），瓶颈转移到调度算法和输出端口冲突上。

6. 队头阻塞指队首元素因某种冲突而无法前进时，队列中后面本可以被处理的元素也被迫等待。本课程中它出现了三次：HTTP/1.1 的应用层响应必须按序返回（第 6 讲）、TCP 字节流中一个丢包阻塞所有已到达的后续数据（第 6 讲）、以及本讲输入端口队列中队首分组因输出端口冲突阻塞后续分组。VOQ 的解法是把一个共享队列拆成 N 个（每个输出端口一个）独立队列，队头不再互相牵连——与 HTTP/2 多路复用流、QUIC 独立流是同一个思想。

7. RTT×C 是单条 TCP 流为了在丢包后维持链路满载所需的缓冲；RTT×C/√N 适用于链路上有 N 条互不同步的 TCP 流的情形，此时它们的锯齿相互抵消，所需缓冲大幅减少。两个公式都不是最终答案，因为它们都只优化吞吐量而完全不考虑时延——按它们配置的大缓冲区正是 bufferbloat 的成因。正确的做法是配合 AQM（如 CoDel） 动态控制分组在队列中的驻留时间，而不是静态地设定一个队列长度。

8. 轮转按分组轮流服务，因此发送大分组的类会占据更多实际带宽（同样是"一个分组"，1500 字节和 64 字节的带宽消耗差 23 倍）。WFQ 按比特数计量并按权重分配，保证每个类获得 w_i / Σw_j 的带宽份额，与分组大小无关，因此提供了真正可预测的带宽保证。

9. ⭐ 区别只有缓存二字。监管（policing）不缓存：超出约定的分组当场丢弃或降级标记，因此不引入额外时延，但会丢包。整形（shaping）缓存：超出的分组先进缓冲区，等有令牌了再发出，因此不丢包，但引入排队时延且需要缓冲区。运营商在入口对客户流量做监管，发送端在出口对自己的流量做整形。

10. b 是桶容量，物理含义是⭐ 被允许的最大突发量——一条长时间安静的流可以把令牌攒满，然后瞬间发出 b 这么多数据。

任意长度为 t 的区间内：  流量(t) ≤ r · t + b

b 越大越宽容突发；b 等于一个分组长度时几乎不允许任何突发。长期（t 很大）平均速率被限制在 r。

11. ⭐ 漏桶装的是数据——桶就是缓冲区，输出以严格恒定的速率漏出，突发被完全抹平，桶满则丢弃新到的数据。⭐ 令牌桶装的是令牌（发送许可）——桶满时丢弃的是令牌而不是数据，攒下的令牌允许后续最多 b 的突发通过。

12. IntServ 为每条流预留资源，路由器要为每条流维护状态并做逐流调度。骨干路由器上同时有数百万条流，⭐ 状态与调度开销爆炸；而且要求路径上每一台路由器都支持 RSVP，只要有一台不支持保证就断了。复杂性被放在了核心。

DiffServ 放弃逐流：边缘路由器（流数量少、可以慢）做分类、监管与打 DSCP 标记；核心路由器只看 6 位 DSCP 按 PHB 转发，⭐ 完全不知道「流」的存在。复杂性被放在了边缘，核心保持简单快速——和分组交换、端到端原则是同一条思路。

📌 补充：DiffServ 今天主要用在单一管理域内（企业网、运营商的 VoLTE 承载、数据中心）。跨 AS 时 DSCP 通常被清零，因为⭐ 你无法要求别人的网络尊重你打的标记。

一、网络层概览#

1.1 唯一的职责#

1.2 两个平面#

1.3 控制平面的两种实现#

1.4 IP 的服务模型：什么都不保证#

二、路由器体系结构#

三、输入端口：最长前缀匹配#

3.1 转发表的形式#

3.2 最长前缀匹配规则 ⭐#

3.3 TCAM：用硬件在一个时钟周期内查表#

四、交换结构#

4.1 经内存交换（第一代）#

4.2 经总线交换#

4.3 经互连网络交换（Crossbar）⭐#

五、排队：队头阻塞#

5.1 输出端口排队#

5.2 输入端口排队与队头阻塞（HOL Blocking）⭐#

5.3 缓冲区该配多大#

六、分组调度#

6.1 FIFO（先进先出）#

6.2 优先级排队（Priority Queuing）#

6.3 轮转（Round Robin）#

6.4 加权公平排队（WFQ）⭐#

6.5 调度与网络中立性#

七、流量监管与整形：令牌桶#

7.1 三个容易混淆的概念#

7.2 令牌桶#

7.3 漏桶：另一种形状#

7.4 令牌桶 + WFQ = 可证明的时延上限#

7.5 IntServ 与 DiffServ：两次尝试#

八、例题（Worked Example）#

九、随堂自测#

十、本讲要点回顾#

十一、自测答案#