第 18 章 HTTP 演进与 HTTPS

本章回答：为什么 HTTP/1.1 必须靠"多开连接"续命，而 HTTPS 又凭什么在 1~2 个 RTT 内谈完密钥。

学习目标

读完本章，你应当能够：

1. 推导 HTTP/1.1 队头阻塞（head-of-line blocking, HOL）的成因，说明"浏览器 6 连接"与"域名分片"是同一原因的两种表现；
2. 区分应用层 HOL 与 TCP 层 HOL，指出后者为什么是 HTTP/3 的唯一动机；
3. 画出 TLS 1.2（2-RTT）与 TLS 1.3（1-RTT、0-RTT）握手时序，逐条说出 TLS 1.3 砍掉了什么、为什么能省一个 RTT；
4. 判断 301/302/307/308、401/403、502/504 的语义差异，并指出"是否允许改变请求方法"这一判定轴；
5. 解释 SNI、HSTS、OCSP Stapling 各自解决的具体问题，而不是背缩写。

前置知识检查

18.1 HTTP 的定位与无状态性

HTTP（HyperText Transfer Protocol）是应用层的请求-响应协议，只约定报文的语义与格式，不约定连接怎么建、怎么复用、怎么保证可靠——这些全部下推给传输层。本章的版本演进都发生在这条分界线的夹缝里。

**无状态（stateless）**要说得比课本精确：服务端处理一个请求时，不依赖此前任何请求留下的、协议层自带的状态，每个请求必须自带全部上下文。好处是工程性的：

代价是应用状态必须外置。Cookie（RFC 6265）是客户端存储加自动回带（按域、路径、Max-Age、Secure、HttpOnly、SameSite 约束），本身不含语义；Session 才是真正的状态，放在服务端内存／Redis／DB，Cookie 里只放一个不可猜测的 ID。于是无状态协议上重新引入了状态，代价立刻显现：会话粘滞（sticky session）、会话存储成为新单点、跨机房同步延迟、SameSite 与 CSRF 的耦合。

18.1.1 HTTP 报文格式

报文格式必须能默画，因为它解释了后面几乎所有演进：HTTP/1.1 的每个请求都要在同一条字节流上与前后请求首尾相接，格式本身携带了边界信息。

1
2
3
4
5

GET /api/v1/users?page=2 HTTP/1.1    ← 起始行：方法 + 目标 + 版本
Host: api.example.com                ← 头部字段（header fields），0..N 行
Accept: application/json
                          ← 空行：CRLF，格式上的强制分隔符
{"id":1}                             ← 正文（body），可缺省

四个部分：起始行（start-line）+ 头部字段 + 空行（CRLF）+ 正文（body）。三个会被追问的点：

1. 空行是格式的一部分，不是排版。没有它接收方无法知道头部在哪结束；这也是头部能逐行解析、而正文只能用长度或分块定界的原因。
2. 正文定界有三条路：Content-Length 定长、Transfer-Encoding: chunked 分块（长度未知时）、由连接关闭隐式定界。第三条正是流水线无法工作的直接原因之一。
3. Host 是 HTTP/1.1 的强制头，它是"一个 IP 承载多域名"的基础；HTTPS 里同样的需求由 SNI 在 TLS 层完成（见 18.9.3）。

18.2 HTTP/1.1：持久连接、连接池与管线化

18.2.1 持久连接与连接池

HTTP/1.0 默认每请求一条 TCP 连接，一次页面几十个资源就要几十次"三次握手 + 慢启动"。成本是实打实的：同机房 RTT 约 0.1_{0.5 ms，跨大洲 RTT 约 150 ms，而 cwnd 只从 1}10 个 MSS 起跳。

HTTP/1.1 默认持久连接（persistent connection）（HTTP/1.1 中 Connection: keep-alive 其实冗余，缺省即持久；Connection: close 才是否定）。工程上真正的重点是连接池：客户端按"每源 6 条"限流；服务端把建连成本摊销到每 N 个请求；而 NAT 网关、四层负载均衡通常有 60~900 s 的空闲回收，于是 keepalive_timeout 必须小于上游的回收时间，否则会出现"连接看着是活的、一写就 RST"的半开（half-open）现象——这是线上最常见的 502 来源之一。

18.2.2 管线化为什么在实践中失败

**管线化（pipelining）**的设想很自然：既连接是持久的，客户端为什么不能一次把请求 A、B、C 全写出去，再按顺序读响应？三个原因必须分开讲：

1. 响应必须严格按请求顺序返回（RFC 7230 要求）。服务端不能先回 B 再回 A，因为响应里没有请求 ID；于是 A 慢（比如一次重查询），B、C 早就处理完了也只能等——这就是应用层队头阻塞。
2. 中间设备兼容性：早期代理对"一个连接里连续到达多个请求"处理不一致，有的直接关连接，有的串行化，有的缓存出错。协议允许不等于部署环境支持。
3. 出错后无法确定应答归属：一旦服务端提前关连接或某个响应出错，客户端无法判断剩余字节属于哪个请求，只能整条连接作废重发。这是"缺少请求标识符"的直接后果，也解释了 HTTP/2 为什么必须引入 Stream ID。

1
2
3
4
5

HTTP/1.1 管线化的失败（应用层 HOL），时间 →
客户端 ──┬─ req A ─┬─ req B ─┬─ req C ───────────────────────►
服务端   │ 处理A（慢，200 ms） │ 处理B（快，5 ms）→ 完成但只能等待
         └─ resp A ─────────────────────► resp B ─► resp C
            └─── 这 200 ms 里 B、C 的响应被"堵"在 A 后面 ───┘

18.3 队头阻塞：应用层 vs 传输层

“队头阻塞"被过度使用，面试最容易被抓的是不区分层次。

HTTP/1.1 的 HOL 在应用层：同一连接上请求-响应严格串行，它甚至不需要管线化就已经存在——不开管线化时客户端必须等上一个响应读完才发下一个，串行度 100%。绕过的办法是开更多连接：浏览器对每个源（origin）默认限制 6 条并发连接（HTTP/1.1 时代的事实标准），并发度从 1 变成 6。这是绕过而非解决：第 7 个请求仍要排队。

**域名分片（domain sharding）**正是顺着这个限制做的工程妥协：把 static.example.com 拆成 s1..s2.example.com，因为限流单位是"源”，2 个域名就能拿到 2 × 6 = 12 条连接。代价同样具体：

18.4 HTTP/2：二进制分帧与多路复用

HTTP/2（RFC 7540）没有改语义（方法、状态码、头部字段含义全部沿用 HTTP/1.1），只改了两件事：报文怎么编码、报文怎么在连接上复用。

18.4.1 二进制分帧层

HTTP/2 把报文切成帧（frame），每帧带 9 字节固定头；Length 24 位决定单帧载荷上限，默认 SETTINGS_MAX_FRAME_SIZE 是 16 384（2¹⁴）字节；Stream Identifier 31 位是复用的全部秘密——接收方靠它把交错的帧归位到各自的响应上，这正是 HTTP/1.1 缺的那个"请求标识符"。

1
2

HTTP/2 帧头（9 字节）: | Length(24) | Type(8) | Flags(8) |R| StreamID(31) |
Payload 长度 0 .. 2²⁴−1 字节；Type 决定这是 HEADERS / DATA / SETTINGS / ...

二进制而非文本的收益有两块：解析不必再处理文本边界与大小写变体；帧可以在同一连接上交错（interleave），因为边界判定不再依赖"行"和"顺序"。

18.4.2 流、消息与帧的三层关系

必考的结构题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

一条 HTTP/2 连接（TCP）= 多个流；Stream 1 (ID=1, 客户端发起) ← 流：请求-响应的
逻辑通道，双向、有状态；Message（请求）= HEADERS + DATA 帧 ← 消息：一次完整
请求或响应；Message（响应）= HEADERS + 2×DATA 帧(END_STREAM)
├── Stream 3 (ID=3) └── Message: HEADERS / HEADERS + DATA 帧
└── Stream 5 (ID=5) └── Message: HEADERS + DATA 帧(END_STREAM)
线上字节流交错到达，接收方按 Stream ID 重组：[H1][H3][H1][D3][H5][D1]...
```规则：**流是逻辑通道**（并发数由 `SETTINGS_MAX_CONCURRENT_STREAMS` 约束，实践常为 100+）；**消息是完整语义单元**；**帧是最小传输单位**。客户端发起的流 ID 为奇数，服务端发起（推送）的为偶数，ID 单调递增且不能重用，耗尽后需 `GOAWAY` 或新建连接。

### 18.4.3 头部压缩 HPACK

HTTP/1.1 的头部是纯文本且大量重复（Cookie、`User-Agent` 每请求带一遍）。HTTP/2 用 **HPACK**（RFC 7541）压缩，三个机制协同：

| 机制 | 做法 | 省字节的原理 |
|---|---|---|
| 静态表（static table） | 61 条预定义的字段名+常见值（`:method: GET`、`:status: 200`） | 常见头部压成 1 个索引字节，`:method: GET` 从约 14 字节降到 1 字节 |
| 动态表（dynamic table） | 连接级 FIFO 表，本次出现的字段名/值可被后续索引引用 | 第二个请求的 `user-agent` 变成 1 个索引，**跨请求去重**是大头 |
| 哈夫曼编码（Huffman coding） | 对未命中表的字面量按 RFC 7541 静态哈夫曼表编码 | 字面量再省约 30% |

动态表是**连接级、有状态的**，两个约束随之而来：压缩上下文不能跨连接复用；表容量需由 `SETTINGS_HEADER_TABLE_SIZE` 与 `dynamic table size update` 协商同步。也正因为有状态，HPACK 需要用表大小上限与重置机制限制解码侧信道的影响面。

### 18.4.4 服务端推送、优先级与它们的结局

**服务端推送（server push）**允许服务端用偶数 ID 的流主动推资源（典型是 `index.html` 的 CSS/JS），省掉"解析 HTML 再发请求"的一次往返。它在实践中基本失败了：服务端很难知道客户端缓存里已有什么，容易推重复白耗带宽；推送与 `Cache-Control` 交互复杂；且与浏览器自身的预加载与优先级逻辑冲突。**结果是 HTTP/3（RFC 9114）不再有 `PUSH_PROMISE`**，改用 `103 Early Hints` 让服务端"提示"客户端去请求。

**流优先级与依赖树**允许客户端给流指定权重（1~256）与依赖关系，构成一棵依赖树；这套复杂树模型难以被正确实现，后来被 RFC 9218 的**可扩展优先级方案**取代，简化为 `urgency`（0~7）与 `incremental` 两个参数。

> [!NOTE]
> HTTP/2 是"语义不变、传输层重写"的一次升级，且明确要求客户端**不要**再为绕开并发限制而开多条连接，否则多路复用与 HPACK 的收益互相抵消。记住这条"不许多开连接"，18.5 节才讲得通。

## 18.5 HTTP/2 仍存在 TCP 层队头阻塞

这是 HTTP/2 最容易被考到的缺点，也是 HTTP/3 存在的唯一原因：**多路复用解决了应用层串行，却把并发放进了同一条 TCP 连接，而 TCP 的交付语义是"字节流按序交付"。**

```text
TCP 层 HOL：一个包丢了，全部流一起等
Stream 1   ██████████████████  ← 帧早已到达
Stream 3   ██████████████████  ← 帧早已到达
Stream 5   ██████░░░░░░░░░░░░  ← 第 3 个包丢了
                     ↑
TCP 接收缓冲区：[ ..... gap ..... ][后续字节全部就绪，但应用层读不到]
                     ↓ 内核不把 gap 之后的字节交给应用层（按序交付），HPACK 解码器也无法推进

关键在于这个等待是 RTT 量级的：同机房 RTT 约 0.1~0.5 ms 尚可忍，跨大洲 RTT 约 150 ms 时一次丢包就让所有流各停 150 ms 以上。丢包率越高、RTT 越大，HTTP/2 相对 HTTP/1.1 越吃亏——HTTP/1.1 时代一次丢包只影响其中一条连接上的一个请求，另外 5 条照常前进。

18.6 HTTP/3 与 QUIC

QUIC（RFC 9000）是跑在 UDP 之上的用户态传输协议，HTTP/3（RFC 9114）就是把 HTTP 语义映射到 QUIC 上。三个问题必须答清。

18.6.1 为什么基于 UDP

不是因为 UDP 更好，而是因为中间设备僵化（ossification）：大量 NAT、防火墙、负载均衡只认 TCP/UDP 的既有行为，新传输协议若占用新的 IP 协议号（如 SCTP）会被直接丢弃；封装成 UDP 载荷则能以很高概率穿过这些设备。既然用 UDP，TCP 提供过的一切都得在用户态重建，而重建带来两个副产品：可快速迭代（不必等内核升级与操作系统普及，随浏览器/服务更新即可上线新特性），以及连接内的流独立可控。

18.6.2 QUIC 的流与拥塞控制

QUIC 内部有独立的流级流控与连接级流控，流的字节偏移独立。但要说准一个点：同一流内部仍然有序交付，所以 QUIC 消除的是"跨流 HOL"，不是"流内 HOL"。头部压缩在 HTTP/3 中换成 QPACK（RFC 9204），专门为"跨流乱序到达"重新设计——这正是 HPACK 那种"一个头部帧丢了就卡住所有流"的机制不能在 QUIC 上直接复用的原因。

18.6.3 0-RTT、重放风险与连接迁移

• 1-RTT 建连：首次连接时 QUIC 的传输握手（含 TLS 1.3 密钥协商）在一个往返内完成；而 TCP + TLS 1.2 通常要 3 个往返（1 建连 + 2 握手）。

• 0-RTT 与会话复用：客户端用上次会话的票据（session ticket）直接加密并发送应用数据，做到"第一个包就带业务数据"。代价是 0-RTT 数据没有前向保密且可被重放——攻击者抓到这段密文就能重复发送。因此 0-RTT 只适用于幂等且无副作用的请求（如 GET 静态资源），绝不能用于支付、提交订单；服务端还必须自行做重放防护（一次性票据、时间窗、请求去重）。

• 连接迁移（connection migration）：Connection ID 取代四元组作为连接身份，所以手机从 Wi-Fi 切到 4G、或 NAT 重新映射端口时连接不中断，也不必重新握手。

• 弱网优势的量化直觉：设 RTT = 150 ms、丢包率 2%。HTTP/2 下每次丢包让所有并发流各等一个 RTT 量级；HTTP/3 下只有丢包的那个流等。这就是"弱网下 HTTP/3 的 P99 明显好于 HTTP/2"的来源——不是带宽更高，而是尾延迟抖动更小。

18.7 HTTPS 与 TLS 的位置：四种密码学原语的分工

TLS（Transport Layer Security）位于传输层之上、应用层之下，给应用层留下一个"看起来像可靠字节流、但已加密并校验过完整性"的接口，因此 HTTP 本身完全不必改就能被保护——这也是 HTTPS 只是 “HTTP over TLS” 的原因。四种原语解决四个不同问题，最容易混：

为什么非对称只用来协商密钥、数据用对称传：非对称是模幂／椭圆曲线点乘这类大数运算，比 AES 慢 2~3 个数量级，一次响应几百 KB 用 RSA 逐块加密不可行。所以握手阶段用非对称（或基于 DH 的密钥交换）只协商出一个小秘密，之后全部用对称密钥。

18.8 TLS 1.2 与 TLS 1.3 握手对比

18.8.1 完整握手时序

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

TLS 1.2 = 2 RTT                       TLS 1.3 = 1 RTT
──────────────────────────────        ─────────────────────────────────
C ─ ClientHello ───────────► S        C ─ ClientHello ──────────────► S
   client_random(32B), cipher_suites,    client_random, cipher_suites,
   extensions                            key_share(猜定的 ECDHE 公钥)
C ◄ ServerHello/Certificate/ ──►      C ◄ ServerHello ─────────────── S
   ServerKeyExchange ──────── S           server_random, key_share
   (server_random 32B、选定套件、          ── 双方已能算出握手密钥 ──
    ECDHE 参数 + 私钥签名)            C ◄ {EncryptedExtensions}, {Certificate},
C ◄ ServerHelloDone ─────── S             {CertificateVerify}, {Finished} ── S
 ══ 第 1 RTT：拿到随机数、             C ─ {Finished} + {HTTP 请求} ──► S
    套件、证书、DH 参数 ══              C ◄ {HTTP 响应} ─────────────── S
C ─ ClientKeyExchange ────► S            ══ 1 RTT 后即可发数据 ══
C ─ ChangeCipherSpec, Finished ► S
C ◄ ChangeCipherSpec, Finished S
 ══ 第 2 RTT 后才发数据 ══

为什么 TLS 1.3 能少一个 RTT：TLS 1.2 的客户端必须先看到服务端的 ServerHello 才知道用哪个组，DH 公钥只能放到第 2 个往返；TLS 1.3 让客户端在 ClientHello 里先猜一个组并带上 key_share（通常是 X25519），服务端若接受该组立刻就能算出共享秘密，于是第 1 个往返里服务端就能把证书与 Finished 一起加密发回。猜错时服务端回 HelloRetryRequest，退回 2-RTT——这是 TLS 1.3 唯一的额外往返。

TLS 1.3 砍掉了什么：

TLS 1.3 还把证书本身也加密（放在 EncryptedExtensions 之后），顺带修掉了"证书明文暴露访问域名"的隐私问题。

18.8.2 会话复用与 0-RTT

1
2
3
4

一次全新 HTTPS 请求，发 HTTP 数据前花掉多少往返？RTT 口径：同机房 0.1~0.5 ms、跨大洲约 150 ms
  DNS 解析（无缓存） 1~2 RTT → TCP 三次握手 1 RTT → TLS 1.2 握手 2 RTT → 合计约 4~5 RTT
  改用 TLS 1.3：1 + 1 = 3~4 RTT（省 1 RTT）；用 0-RTT（仅幂等请求）再省 1 RTT
跨大洲每省 1 RTT ≈ 省 150 ms，这才是 TLS 1.3 与 0-RTT 的真正价值（HTTP 分层排查见第 19 章 19.2 节）。

0-RTT 的适用边界：只允许幂等、无副作用、可重放的请求（服务端应拒绝非 GET/HEAD 的 0-RTT，或只用于静态资源，并做一次性票据校验）。把"0-RTT 快"和"0-RTT 可被重放"一起说，才完整。

18.9 证书与验证链

18.9.1 证书里有什么

X.509 证书的关键字段：使用者（Subject，含 CN 与 SAN）、颁发者（Issuer）、有效期、公钥、签名算法、签名值及若干扩展。两个必考点：SAN（Subject Alternative Name）已取代 CN，现代实现只认 SAN，多域名靠 SAN 列表或通配符 *.example.com（只匹配一级子域）；另外证书本身不加密通信，它只绑定"公钥 ↔ 域名/组织”，并用 CA 签名让任何人可验证这一绑定，真正的加密在握手后由对称密钥完成。

18.9.2 CA 层级与链式验证

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

根证书（Root CA，自签名，预装于操作系统/浏览器信任库，私钥离线）
  └── 中间 CA（Intermediate CA，由根 CA 签名；日常签发者，泄露可吊销而不伤根）
        └── 叶子证书（Leaf，服务端部署）
              Subject: CN=api.example.com  SAN=[api.example.com, *.example.com]

客户端本地验证（不需要联网）：
  1. 用【中间 CA 公钥】验证【叶子证书】签名 → 叶子未被篡改
  2. 用【根 CA 公钥】验证【中间 CA 证书】签名 → 中间 CA 可信
  3. 根 CA 证书在本地信任库 → 信任锚，链条闭合
  4. 逐层检查有效期、SAN 是否匹配目标域名、用途扩展（Key Usage / EKU）
  5. 检查吊销状态（CRL / OCSP / Stapling）

服务端必须发送完整链（叶子 + 中间 CA），但不发根证书（根在客户端本地已有）；“链不完整（missing intermediate）“是线上最常见的 TLS 报错之一，浏览器可能靠 AIA 扩展自动补链，但移动 SDK、Java 客户端、curl 等往往不会，于是直接失败。

18.9.3 SNI、吊销与 HSTS

SNI（Server Name Indication）是 ClientHello 中的扩展，明文携带客户端想访问的域名，解决一个 IP 上部署多个 HTTPS 域名的问题：没有 SNI，服务端在握手时必须先决定出示哪张证书，而此时它还不知道客户端要访问哪个域名（HTTP 的 Host 还没发过来，且整个 HTTP 层都在加密之后）。SNI 的隐私缺陷也很实际：它是明文，暴露你要访问的域名；ECH（Encrypted Client Hello）就是在补这个洞。

HSTS（HTTP Strict Transport Security）用 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 告诉浏览器"此后一段时间内对我只用 HTTPS”。它解决降级攻击：用户输入 example.com 或点某个 http:// 链接时首次请求是明文的，中间人可劫持并阻止跳转（SSL Strip）；HSTS 让浏览器在本地就把该域名的 http:// 改写成 https://，不发明文请求。preload 进一步把域名硬编码进浏览器，补上"第一次访问还没收到 HSTS 头"的窗口。

中间人攻击（MITM）与自签证书：MITM 的本质是"攻击者用自己的证书冒充服务端”。若客户端信任库里有攻击者的根证书（企业内网代理、被装过根证书的设备），验证就会通过——TLS 无法防御"客户端自己信任了错误根”。自签证书靠同一机制失效：验证链找不到本地信任锚，于是浏览器报警；用 curl -k 跳过校验"解决"，在生产环境等于放弃身份鉴别。

18.10 常见状态码的语义与陷阱

状态码分 5 类（1xx 信息、2xx 成功、3xx 重定向、4xx 客户端错、5xx 服务端错），本科都讲过；这里只写面试会追问语义差异的部分。

18.10.1 重定向：永久/临时 × 是否允许改方法

记忆骨架：301/302 是老规范留下的模糊地带，307/308 是把 302/301 的语义说清楚的版本，判定轴只有一个——是否允许把 POST 改成 GET；303 则反过来，明确要求改成 GET。

18.10.2 认证与授权、网关错误的归属

• 401 Unauthorized（名字起错了，语义是 Unauthenticated）：你没有证明你是谁，响应必须带 WWW-Authenticate 头告诉客户端如何认证。
• 403 Forbidden（语义是 Unauthorized）：我们知道你是谁，但你无权访问；再认证一次也没用。一句话区分：401 是"去登录"，403 是"登录了也没用"。
• 502 Bad Gateway：网关从上游拿到了无效响应（连上了但响应不合法、上游拒绝、连接被 RST），典型如后端进程崩溃、协议错乱、keepalive 半开连接。
• 504 Gateway Timeout：网关没等到上游响应就超时，典型如后端慢查询、下游级联超时。一句话区分：502 是"上游的回答不对"，504 是"上游根本没回答"，排查方向分别是后端进程/协议 与 超时链路/下游耗时。

18.10.3 200/204/206 与 Connection: close

206 的前提：客户端发 Range: bytes=0-1023，服务端回 206 + Content-Range: bytes 0-1023/5000；若服务端不支持范围请求，应回 200 + 全量正文而不是 206，否则客户端会拼出错误文件。

Connection: close 在请求/响应结束后关闭连接：连接池复用失效，每请求重付一次握手与慢启动；更关键的是正文定界方式改变——close 语义下的响应可以不带 Content-Length，由"连接关闭"暗示正文结束。这也解释了为什么它与连接复用不能共存、为什么流水线在 close 下彻底不可行。

1xx 的现代用法：100 Continue（先发头、服务端同意后再发大 body）与 101 Switching Protocols（WebSocket 升级）；103 Early Hints 在最终响应前提示客户端预加载资源，也是 HTTP/3 里替代服务端推送的主要手段。

本章小结

自测题

Q1（推导）一个页面需要加载 30 个同源静态资源。说明 HTTP/1.1 下最多能并发几个，域名分片为什么能提高这个数字、代价是什么。

Q2（辨析）请分别说明 HTTP/1.1 与 HTTP/2 的队头阻塞在哪一层、由什么造成，以及 HTTP/2 为什么不能靠"多开连接"缓解。

Q3（画图与解释）画出 TLS 1.2 与 TLS 1.3 完整握手的主要消息，标出各自往返数，并解释 TLS 1.3 为什么能少一个 RTT。

Q4（计算）链路跨大洲，RTT 约 150 ms；DNS 已缓存；服务端支持 TLS 1.3。计算从 TCP 建连到收到 HTTP 响应首字节的最少往返数（忽略丢包与慢启动），并说明改用 0-RTT 能省多少。

Q5（辨析）四个场景分别选哪个状态码并说明理由：① POST /orders 提交后跳转订单详情页；② 迁到新域名，以后都访问新域名，且该接口只接受 POST；③ 用户带合法 token 但无权访问该资源；④ 网关等待后端 3 s 无响应，自身超时阈值 2 s。

面试高频问题与陷阱

延伸阅读

• RFC 7230 / 7231 / 7232 / 7233 / 7234 / 7235：HTTP/1.1 报文语法、语义、条件请求、范围请求、缓存与认证（301/302/307/308、206、401 的权威定义）。
• RFC 7540（HTTP/2）与 RFC 7541（HPACK）：二进制分帧、流与优先级、头部压缩。
• RFC 9114（HTTP/3）、RFC 9000（QUIC）、RFC 9002（QUIC 丢包检测与拥塞控制）、RFC 9204（QPACK）。
• RFC 8446（TLS 1.3）、RFC 5246（TLS 1.2）、RFC 6066（SNI）、RFC 6797（HSTS）、RFC 6960（OCSP）。
• RFC 6265（Cookie）、RFC 9218（HTTP 可扩展优先级）、RFC 8297（103 Early Hints）；《HTTP/2 in ACTION》与《Bulletproof SSL and TLS》分别是帧与流、证书链与吊销机制的实务参考。
• 第 16 章 16.1_{16.5 节（TCP 建连与关闭）、第 17 章 17.4}17.6 节（重传与拥塞控制）、第 19 章 19.2 节（DNS 递归与迭代、curl -w 分层排查）。