第 15 章 体系结构与分层

本章是第四篇的地基：先讲"为什么分层、代价是什么"，再把一次 HTTP 请求的封装与解封装、MTU/MSS/分片、ARP、NAT、性能指标一次讲透。

学习目标

读完本章，你应当能够：

1. 推导一次 HTTP 请求从应用层到物理层的完整封装与解封装，并指出交换机、路由器、NAT 各自解封到哪一层；
2. 计算给定 MTU 下的 MSS，判断一次超长发送会走 TCP 分段还是 IP 分片，并解释片偏移为什么以 8 字节为单位；
3. 解释路径 MTU 发现（PMTUD）的黑洞问题与"DF 置位 + ICMP 被丢"的因果链，给出两种工程对策；
4. 从 ARP 缓存可被伪造出发，说明免费 ARP 与 ARP 欺骗的关系，并回答"有了 IP 为什么还要 MAC"；
5. 画出 NAPT 的端口映射表，判断四种 NAT 类型下打洞是否可行，说明 STUN/TURN/ICE 各自的职责；
6. 论证拥塞控制为什么必须端到端，并对照 ATM ABR 与 ECN 说明"标记而不决策"这一折中；
7. 用带宽时延积（BDP）解释长肥管道（LFN）为什么必须开窗口扩大因子，并做吞吐上界估算。

前置知识检查

15.1 分层的本质与代价

分层不是"把网络课本切成七块"的排版手段，而是接口约定（interface contract）+ 关注点分离（separation of concerns）。看"层与层之间交换什么"就能推出三个结论：每层只向上暴露服务原语（connect/send/recv）、只依赖下层提供的服务，而不暴露实现。

• 对等通信（peer-to-peer）是逻辑上的：第 N 层只与对端第 N 层"对话"，它写的头部只有对端第 N 层会读，中间设备无需实现第 N 层也能转发。这正是"IP 能跑在任何链路层之上、TCP 能跑在任何网络层之上"的原因——Wi-Fi 换 5G，TCP 一行不改。
• 演进可以按层独立发生：QUIC（RFC 9000）把可靠传输塞进 UDP 载荷、绕开中间设备对 TCP 的僵化假设，才得以在不改动网络的前提下部署（见第 18 章 18.4 节）。
• 接口在编译期固化：connect() 的调用者不知道对端是光纤还是卫星。这既带来多厂商互通，也带来"上层无法把需求告诉下层"的副作用。

代价是面试真正想听的部分，要答出以下四条而不是笼统的"效率低"：

• 每层都要加头部：不带选项的 IPv4 + TCP 至少 20 + 20 = 40 字节，加帧头 14 与帧尾 4，链路层共 58 字节。一个 40 字节的请求（GET 加少量首部）有效载荷占比不到一半；头部开销在"小而多"的报文上被放大，这正是 HPACK 与 TCP Fast Open 之类优化的动机。
• 跨层优化被挡住：无线误码丢包（不是拥塞）会被 TCP 当拥塞信号盲目减窗；应用知道自己在传实时视频，却无法告诉 IP"这包丢了不用重传"。工程补救都是在层间开受限旁路：TCP_NODELAY、SO_PRIORITY、DSCP、TCP_ULP，或者像 QUIC 那样直接揉成一个用户态协议。
• 信息隐藏导致重复实现：校验（以太网 FCS、IP 首部校验和、TCP 校验和）、重传（链路层 ARQ 与 TCP 重传）、分用（端口号与协议号）都在多层各做一遍。
• 中间设备越层窥探：NAT 必须改传输层端口、防火墙看 HTTP 首部、运营商做 DPI。它们是分层的名义遵守者、实际破坏者，也是 QUIC 要把传输层首部加密的动机。

15.2 三种模型与 PDU 对照

OSI 七层是参考模型，TCP/IP 四层是可运行的实现，教学五层把"网络接口层"再拆成数据链路层与物理层，便于按 PDU 与设备讲解。面试常考三者映射、每层 PDU 名称、每层典型设备与协议。

为什么工程讲解用五层：OSI 的表示层与会话层在实践中几乎没有独立实体，加密与编码（TLS、gzip、序列化）由库和应用完成、会话状态由应用自己维护，它们的职能被并入应用层，而 OSI 作为术语体系（“二层设备"“三层转发"“七层负载均衡”）被完整保留；TCP/IP 四层把链路与物理合成一层，粒度太粗，讲不清交换机与集线器的差异，也讲不清 MTU 是谁的约束。五层恰好与 PDU、设备、故障排查层次一一对应（第 19 章 19.5 的分层排查法就按这五层走）。

15.3 一次 HTTP 请求的完整旅程

15.3.1 分层封装（encapsulation）

以客户端 192.168.1.10:49152 访问 203.0.113.5:443 为例，省略选项，IPv4 与 TCP 首部各 20 字节，帧头 14、帧尾 4 字节。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

应用层     生成 HTTP/1.1 请求（应用数据 200 B）
传输层     + 源端口 49152 / 目的端口 443 / 序号 1001 / 标志 PSH,ACK
   TCP 段  ┌──────────────────────────────┐
           │ TCP 头 20 B  │ 应用数据 200 B │
           └──────────────┴────────────────┘
网络层     + 源 IP 192.168.1.10 / 目的 IP 203.0.113.5 / TTL 64 / 协议 6
IP 数据报  ┌─────────────┬──────────────┬────────────────────────────┐
           │ IP 头 20 B  │ TCP 头 20 B  │       应用数据 200 B       │  ≤ MTU 1500
           └─────────────┴──────────────┴────────────────────────────┘
链路层     + 目的 MAC = 默认网关的 MAC（跨网段时帧只为"下一跳"寻址）
 以太网帧  ┌──────────┬─────────────┬──────────────┬──────────────────┬──────┐
           │ 帧头 14B │ IP 头 20 B  │ TCP 头 20 B  │   应用数据 200B  │ FCS  │
           └──────────┴─────────────┴──────────────┴──────────────────┴──────┘
物理层     编码成电/光/无线信号发出；每个中继段重新生成信号

三个必被追问的细节：目的 MAC 不是服务器的 MAC（跨网段时是默认网关的，服务器 MAC 只出现在最后一跳，怎么知道网关 MAC 就引向 ARP，见 15.6）；IP 地址沿途不变（NAT 场景除外），MAC 逐跳重写，这就是"三层端到端、二层逐跳”，也是 traceroute 能工作的前提；FCS 是链路层校验，每跳验证并重算，端到端完整性由 TCP 校验和负责，两者层次不同。

15.3.2 各层头部里"真正管事"的字段

15.3.3 解封装（decapsulation）

服务端拿到的字节流与客户端发出的完全一致，但每一层做的是剥离：网卡检查 FCS 与目的 MAC，按 EtherType 上交网络层；网络层确认目的 IP 属于本机、TTL 减一（转发场景）、校验首部，按协议号上交传输层；传输层按四元组找到连接，按序号排序去重、累积确认，把数据放进该 socket 的接收缓冲区；应用层 read() 拿到字节流并解析请求行与首部。

15.4 中间设备解封到哪一层

二层交换机只解封到数据链路层：读源/目的 MAC 查表转发，不看 IP 头（三层交换机除外），也不改 IP 与 TCP 首部。三个追问点：每个端口一个冲突域（全双工下已无冲突），但所有端口同属一个广播域，所以 ARP 广播会打到整个二层网络；MAC 地址表默认约 300 秒老化（以具体实现为准），过期即泛洪，表项被伪造就是 MAC 洪泛攻击；判断"两台机器是否同网段"看的是地址与掩码按位与的结果，不是看它们是否接在同一台交换机上。

路由器解封到网络层：检查目的 IP、查转发表选下一跳与出接口、TTL 减一、必要时分片（IPv4）或丢弃并回 ICMP（IPv6 不做中途分片），然后重写源/目的 MAC 重新封装转发。它通常不动传输层，端口号对路由器透明。

1
2
3

主机 A --[以太网帧]--> 交换机 --> 路由器 R1 --[新帧]--> 路由器 R2 --> 服务器 B
  ↑ 应用/传输/网络三层在 A 生成        ↑ 只看 IP 层：改 TTL、改 MAC、可能分片
  ↑ 端到端：IP（除 NAT）与 TCP 首部不被中间路由器修改

所以"端到端"的准确含义是：传输层与网络层的语义是端到端的，链路层是逐跳的；IP 首部在正常情况下端到端不变，NAT 与隧道是例外。

15.5 MTU、MSS 与分片：层次归属

第四篇最高频的深挖点之一。一句话结论：分段（segmentation）在传输层，分片（fragmentation）在网络层；TCP 自己分段，绝不想让 IP 分片。

15.5.1 MTU 与 MSS 的计算

MTU（maximum transmission unit）是链路层载荷上限，即"一个完整 IP 数据报能有多大"；MSS（maximum segment size）是 TCP 放进单个 IP 数据报的载荷上限，只算数据、不含任何头部。因此：

1
2
3
4
5

MSS = MTU − IP 首部 − TCP 首部
以太网无选项 IPv4：  MSS = 1500 − 20 − 20 = 1460 字节
带 12 字节时间戳选项：MSS = 1500 − 20 − 32 = 1448 字节
IPv6 + IPsec 隧道：   MSS = 1280 − 60 − 20 = 1200 字节（IPv6 最小 MTU 1280）
PPPoE（MTU 1492）：   MSS = 1492 − 20 − 20 = 1452 字节

会算之后还要会说三件事：MSS 是协商出来的，双方在 SYN / SYN+ACK 里各带 MSS 选项声明"我最多能收多大"，发送方取两者与自身路径约束的最小值——它声明的是接收能力，这一点常被答反；MSS 在连接建立时就固定，中途路径 MTU 变小只能靠 PMTUD 或黑洞检测补救（15.5.3）；MSS 与 rwnd/cwnd 量纲不同，后两者是字节数（窗口），MSS 是一次封装的粒度，慢启动里"每 RTT 翻倍"正是按 MSS 增长的（见第 17 章 17.5 节）。

15.5.2 IPv4 分片的三个字段与后果

当 IP 数据报大于出接口 MTU 且 DF = 0 时，路由器把它切开，每片都是独立 IP 数据报、各带一份复制的 IP 与传输层首部，却没有传输层重传语义：

1
2
3
4
5
6

原始 IP 数据报载荷 3000 B（IP 首部 20 B），出接口 MTU 1500
可分片载荷上限 = 1500 − 20 = 1480 B，且须为 8 的倍数（1480 / 8 = 185）
片 1: 标识=0x4A21, MF=1, 偏移=0   (字节 0    ~ 1479)  总长 1500
片 2: 标识=0x4A21, MF=1, 偏移=185 (字节 1480 ~ 2959)  总长 1500
  片 3: 标识=0x4A21, MF=0, 偏移=370 (字节 2960 ~ 2999)  总长 60
  若片 2 丢失：目的端凑不齐 0..2999 的连续载荷，把已到的片全部丢弃

这就是"丢一片导致整个报文重传"的完整因果。三条放大效应必须能说出来：开销放大（每片复制 IP/TCP 首部）、丢失放大（丢片概率按片数累积，尾部尤其脆弱）、重组代价（目的端要维护重组缓冲与超时定时器，还有分片重叠的攻击面）。

15.5.3 路径 MTU 发现与黑洞

现代协议栈默认走 PMTUD（path MTU discovery）：发送方把 DF 置 1 并发送自己认为合适的大小。若某跳 MTU 更小，该跳丢弃数据报并回送 ICMP Type 3 Code 4（“需要分片但 DF 已置位”），其中携带该跳 MTU；发送方据此把路径 MTU 估计降下来，按新尺寸重新分段，并按目标地址缓存一段时间。

黑洞（PMTU black hole）由此产生：大量防火墙与中间设备出于策略丢弃全部 ICMP，发送方收不到通知，于是大包静默消失、小包畅通——典型症状是"能 ping 通、能建连、一传大文件就卡死"。两类对策：黑洞检测，主机观察到"大数据段反复重传而连接无进展"时主动把 MSS 降低重试，治的是"ICMP 被丢"，代价是性能骤降；收紧本端 MSS，在隧道/VPN/负载均衡上按最小可能 MTU 手工钳制（如 --clamp-mss-to-pmtu），把风险提前消掉。

15.5.4 为什么 TCP 宁愿自己分段

理论依据是端到端原则（end-to-end argument）：把功能放进网络中间会带来状态与一致性成本，放在端点则简单且可演进；网络层只负责尽力而为的转发，复杂功能交给端点。这与 15.8 节"拥塞控制必须端到端"是同一条原则。

15.6 ARP：IP 与 MAC 之间的桥

ARP（address resolution protocol）不属于 IP：它没有 IP 首部，直接封装在以太网帧里（EtherType 0x0806），在五层模型里算网络层的辅助协议、实现上跨越二三层。有了 IP 为什么还要 MAC：IP 是逻辑的、可聚合的、端到端的编址，用于选路；MAC 是物理的、扁平的、逐跳的标识，用于在同一广播域内把帧交给下一跳的网卡。路由器无法用 IP “点对点"投递——它必须知道下一跳的硬件地址才能把帧送出去。

1
2
3
4

请求（广播）：目的 MAC = ff:ff:ff:ff:ff:ff，EtherType = 0x0806
  "谁是 192.168.1.1？请告诉 192.168.1.10（aa:..:10）"
应答（单播）：目的 MAC = aa:..:10
  "192.168.1.1 的 MAC 是 bb:..:01"

• 请求必须广播、应答必须单播：没有初始缓存就无法寻址，所以请求只能广播；应答的目的地址已由请求报文获知，所以单播——这也让欺骗者能只毒化特定目标。
• ARP 缓存与老化：Linux 邻居表条目默认有可达/过期状态（base_reachable_time 约 30 秒量级、gc_stale_time、gc_thresh1/2/3），用 ip neigh show 观察。缓存是你"记住"的映射，没有验证机制——收到任何 ARP 应答（哪怕没发过请求）都会更新缓存，这就是欺骗的入口。
• 免费 ARP（gratuitous ARP）：主机主动广播"我的 IP 对应这个 MAC”，用于检测 IP 地址冲突（收到别人的应答说明地址被占用）、通知同网段刷新缓存（高可用切换时让流量快速改道）、配合 MAC 漂移做灾备。它本质是"无需请求的应答"，也正好是 ARP 欺骗的最小工具。
• ARP 欺骗：攻击者持续广播伪造映射，使同网段主机把网关 IP 误映射到攻击者 MAC，从而中间人（MITM）。防线是 DHCP Snooping + 动态 ARP 检测（DAI）、端口安全、静态绑定；跨网段时 ARP 天然被路由器隔离。

15.7 NAT：从地址复用到打洞

15.7.1 NAPT 的工作原理

NAPT（network address and port translation，即常说的 NAT/PAT）在转发时改写源地址与源端口，并维护一张映射表：

1
2
3
4
5
6
7
8

内网                                  NAT 出口                   外网
192.168.1.10:49152 ──┐
192.168.1.11:49153 ──┼──> 203.0.113.7:60001 / 60002 / 60003 ──> 服务器
192.168.1.10:49154 ──┘
映射表（出方向建表，回方向查表）：
  192.168.1.10:49152 <- 60001 -> 198.51.100.9:443    TCP  剩余 320 s
  192.168.1.11:49153 <- 60002 -> 198.51.100.9:443    TCP  剩余 118 s
  192.168.1.10:49154 <- 60003 -> 203.0.113.200:1234  TCP  剩余 8 s

关键机制：区分映射靠（内网 IP, 内网端口, 目标 IP, 目标端口, 协议）五元组，所以同一内网端口到不同目标可以映射成不同外网端口；回程包必须命中已有表项才能进入，“没有表项就丢弃"正是内部主机不可被外部主动连接的根本原因；TCP 表项超时通常几分钟到数小时（受 tcp_established/tcp_time_wait 等参数影响），UDP 更短（常见数十秒到几分钟），长连接因此要靠应用层保活给映射续命。

15.7.2 NAT 的代价

• 破坏端到端：外部无法主动连入；IP 不再是稳定的端到端标识（“我的 IP"要从外部视角才知道）。网关被迫越层修改传输层端口、重算校验和，对 TCP/UDP 之外的协议只能靠 ALG 甚至放弃。
• 状态与可靠性：NAT 成为有状态单点，重启即清空所有映射；表项容量是硬上限，也是常见故障源。
• 协议破坏：FTP 主动模式、SIP/H.323 把 IP:port 写在应用载荷里，NAT 改不了，必须 ALG 打补丁——这就是这类老协议今天不好用的原因。

15.7.3 四种 NAT 类型与打洞可行性

按 RFC 4787 的术语分类（面试常按锥型/对称型这一套说法）：

打洞成功时，A 先向 198.51.100.9:60002 发包（NAT-A 记录"允许该目的”，包在 NAT-B 被丢），B 再向 203.0.113.7:60001 发包（NAT-B 记录"允许该目的"，包穿过已放行的 NAT-A 到达 A），此后双向都命中过滤规则；关键在于双方已通过信令知道对方映射。打洞失败时若 A 是对称型，它向 B 发包时外网端口变成 60003，而 B 只知道 60001，双方永远无法命中，只能回落 TURN 中继。

15.7.4 为什么 P2P 与 WebRTC 需要 STUN/TURN/ICE

因此完整链路是"先试直连（STUN + 打洞），失败回落中继（TURN），全过程由 ICE 编排"，这也解释了为什么对称型 NAT 占比高的企业网络里，P2P 应用的服务器带宽成本会明显上升。

15.8 拥塞控制为什么必须端到端

15.8.1 路由器做不到的三件事

把拥塞控制下沉到路由器（在网络层做速率决策）在 IP 世界行不通，原因不是"没实现"，而是三条结构性障碍：

• 路由器看不到"流"的完整状态。它只有单包视图：这个包属于哪条连接、这条连接是刚起步还是已跑了 10 GB、可用带宽多少，路由器都不知道。要判断"该给这条流降多少速"，就得为每条流维护队列与速率状态，在超额订阅的核心网上意味着状态爆炸（同时数百万条流），加密后更不可识别。
• 路由器无法通知发送方。ICMP 源抑制（source quench）已被废弃，原因正是"通知"在分布式系统里不可靠：ICMP 会被限速或丢弃，发送方拿到过期信息反而误伤；多播式拥塞通知还会引起同步震荡。
• 公平与稳定无法在中间层收敛。路由器没有"应用价值"信息来裁决谁该让路；而端点各自按丢包/时延反馈调整速率，构成一个无需中心裁决者就能收敛的分布式控制系统——这是 Jacobson 拥塞控制的根本贡献（见第 17 章 17.5 节）。

15.8.2 ATM ABR 与 ECN 的两个折中

ECN 是这套折中的精髓：路由器的信息优势（它知道队列有多长）被利用，但决策权仍在端点（只有端点知道流的历史与可用窗口）。路由器做的是观察与标记，不是判断与指挥——与端到端原则完全一致：只有端点才知道的事留在端点，只有网络才知道的事以最小信息量（1 bit）反馈回去。数据中心里的 DCTCP 正是把这 1 bit 用到极致以压低排队时延。

15.9 性能指标：带宽、时延与 BDP

15.9.1 四种时延与算例

总时延 = 处理时延 + 排队时延 + 发送时延 + 传播时延，其中前两项常被忽略，后两项是考点主体：

• 发送时延 = 报文长度 / 链路带宽。1 KB 报文在 1 Gbps 上约 8192 / 10⁹ ≈ 8.2 μs，在 100 Mbps 上约 82 μs。它只与带宽和长度有关，与距离无关。
• 传播时延 = 距离 / 传播速度。光纤中约 2 × 10⁸ m/s（约真空光速的 2/3），同城 100 km 约 0.5 ms，跨大洲 15000 km 约 75 ms（单向）。它与带宽完全无关——“加带宽降不了 ping"就是这条。
• 处理时延：查表转发，量级微秒。
• 排队时延：链路空闲时接近 0；设链路利用率 ρ，按 M/M/1 近似，平均排队时延 Tq = (ρ/(1 − ρ)) × Ts（Ts 为发送时延）。ρ = 0.5 时 Tq = Ts，ρ = 0.9 时 Tq = 9 Ts，ρ = 0.99 时 Tq = 99 Ts——利用率逼近 1 时排队时延非线性爆炸，这就是"容量规划留余量"和"尾延迟先炸"的定量依据。

1
2
3
4
5

算例：10 Gbps 链路上 1 KB 报文，ρ = 0.9
  Ts = 8192 / 10¹⁰ = 0.82 μs
  Tq ≈ (0.9 / 0.1) × 0.82 ≈ 7.4 μs   -> 排队占总时延约 90%
  ρ 再升到 0.99，Tq 立刻变成 ≈ 81 μs
  ⟹ 只看平均时延会漏掉长尾；同一 ρ 下到达间隔的抖动会被放大成 P99 时延

15.9.2 RTT 与它的构成

RTT（round-trip time）是一个比特往返一次的墙钟时间，包含两个方向的传播时延 + 沿途每跳的发送/处理/排队时延 + 端点协议处理。两个必答点：RTT 不是常量（排队时延随负载波动，所以 RTO 必须平滑估计，见第 17 章 17.2 节）；RTT 与 MTU/MSS 无关，但与 BDP 一起决定吞吐上限。

15.9.3 带宽时延积（BDP）

BDP = 带宽 × RTT，单位是比特（常换算成字节），物理含义是链路上同时"在途"的比特数，即这条"管道"的容量。同城 1 Gbps × 10 ms = 10 Mbit = 1.25 MB 在途；跨大洲 100 Mbps × 150 ms = 15 Mbit = 1.875 MB 在途。要把链路跑满，未确认数据量必须 ≥ BDP，因为 吞吐 ≈ 窗口 / RTT ⟹ 窗口 ≥ 吞吐 × RTT = BDP；而 TCP 窗口字段只有 16 bit，未开扩大因子时窗口 ≤ 65535 B，于是 吞吐上界 = 65535 B / 0.15 s ≈ 3.5 Mbps——与 1 Gbps 的链路相差近 300 倍，这就是 LFN 必须开 window scaling 的原因（完整算例见自测题 Q5）。

长肥管道（long fat network, LFN）指"带宽高 + RTT 大"的网络：BDP 大，于是对窗口、拥塞控制收敛速度、丢包恢复时间都提出更高要求（一次丢包后恢复到满窗口所需时间与 RTT 成正比）。工程三件套是窗口扩大因子（RFC 7323 的 window scaling，最大 2¹⁴ 倍）、选择性确认 SACK、更大的初始窗口。

15.9.4 吞吐、利用率与它们的关系

• **吞吐（throughput）**是单位时间实际传输的有效数据量，受三者共同钳制：吞吐 ≈ min(瓶颈带宽, 窗口 / RTT, 应用层供给速率)。第三项常被忽略——服务端 CPU 打满、上游慢、TLS 握手频繁时，链路再宽也用不上。
• 利用率 = 吞吐 / 瓶颈链路带宽，只对瓶颈链路有意义。多跳路径各段带宽不同，算单段利用率会得出"链路很闲但用户很慢"的错误结论。
• 利用率与时延是矛盾的：由 15.9.1 的公式可见，提高利用率必然抬高排队时延。所以吞吐型业务追求高 ρ，延迟敏感业务宁可留余量——这也是缓冲区膨胀（bufferbloat）下 AQM 存在的意义。

本章小结

自测题

Q1（计算与推导）链路 MTU 1500 字节，TCP 首部含 12 字节时间戳选项，IPv4 无选项。① 求 MSS；② 应用一次写入 4000 字节，会走分段还是分片，切成几段、各段载荷多大；③ 若某中间路由器出接口 MTU 为 1400 且发送方把 DF 置 1，会发生什么？

Q2（推导）3000 字节载荷的 IP 数据报经过 MTU 1500 的链路，DF = 0。写出各片的标识、MF、片偏移与总长度，并说明若中间丢失一片会发生什么。

1
2
3

片 1: MF=1, 偏移=0,   载荷 1480 B, 总长 1500
片 2: MF=1, 偏移=185, 载荷 1480 B, 总长 1500   （1480 / 8 = 185）
片 3: MF=0, 偏移=370, 载荷 40 B,   总长 60     （2960 / 8 = 370）

Q3（判断与辨析）“路由器最了解网络拥塞状况，应该由路由器决定每条 TCP 流的发送速率，这比让端点自己猜更准确。“判断对错，给出三条反驳理由，并说明 ECN 如何折中。

Q4（设计与分析）A 与 B 的 NAT 都是端口受限锥型，A 的公网映射是 203.0.113.7:60001，B 是 198.51.100.9:60002。① 说明打洞为什么能成功，写出关键两步；② 若 A 侧换成对称型会怎样，需要引入什么组件；③ STUN 与 TURN 的职责分别是什么？

Q5（计算）客户端在跨大洲链路上传输，瓶颈带宽 200 Mbps，单向传播时延 75 ms，未启用窗口扩大因子（窗口上限 65535 字节）。① 求 RTT 与 BDP（用字节表示）；② 求理论上能达到的最大吞吐；③ 若链路升级到 1 Gbps，吞吐会变好吗，为什么；④ 要让 1 Gbps 跑满，窗口至少要多大？

面试高频问题与陷阱

延伸阅读

• Kurose & Ross《计算机网络：自顶向下方法》第 1 章（协议层次与服务模型）、第 4 章（网络层数据平面：IPv4 分片、NAT）、第 5 章（控制平面）；
• Tanenbaum & Wetherall《计算机网络》第 1 章 1.4 节（OSI 与 TCP/IP 模型的对比与批评），用于回答"分层的坏处"；
• RFC 791（IPv4：标识、标志、片偏移）、RFC 1191（IPv4 路径 MTU 发现）、RFC 8201（IPv6 路径 MTU 发现）、RFC 8899（DPLPMTUD，面向不可靠 ICMP 的通用化方案）；
• RFC 826（ARP）、RFC 5227（IPv4 地址冲突检测与免费 ARP 的规范行为）、RFC 4861（IPv6 邻居发现）；
• RFC 3022（传统 IP 网络地址转换）、RFC 4787（NAT 对 UDP 的行为要求与锥型/对称型术语）、RFC 5389/8489（STUN）、RFC 8656（TURN）、RFC 8445（ICE）；
• RFC 3168（ECN）、RFC 2914 与 RFC 8085（拥塞控制原则）、RFC 5681（TCP 拥塞控制）、RFC 7323（窗口扩大因子与时间戳选项）；
• ATM Forum TM 4.0 规范中的 ABR 服务定义与 RM 信元/ER 字段，用于对照"在网络层做拥塞控制的失败尝试"。