HTTP/3：QUIC 传输

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

2733 字

8 分钟

HTTP/3：QUIC 传输

2023-05-01

web

HTTP

/

网络

/

协议

在前面的实验中，我们见证了 HTTP 协议从 0.9 到 1.0、再到 1.1 和 2.0 的演进历程。每一次升级都在解决上一版本的痛点：HTTP/1.0 引入了请求头和状态码，HTTP/1.1 实现了持久连接和管道化，HTTP/2 则通过多路复用大幅提升了性能。

然而，HTTP/2 虽然在应用层实现了多路复用，但它仍然运行在 TCP 之上。TCP 作为传输层协议，有一个根本性的问题——队头阻塞（Head-of-Line Blocking）。当一个 TCP 数据包丢失时，即使后续数据包已经到达，TCP 也必须等待重传后才能继续交付数据。这对于现代网页（包含数十个资源请求）来说是灾难性的。

更糟糕的是，TCP 连接建立的延迟在现代 Web 中越来越难以忍受：

1
TCP 三次握手：1.5 RTT（客户端发送 SYN → 服务器回复 SYN-ACK → 客户端发送 ACK）
2
TLS 握手：    1-2 RTT（取决于 TLS 版本和会话复用）
3
─────────────────────────────────────────────────────────────
4
总计：        2.5-3.5 RTT 才能发送第一个 HTTP 请求

这意味着在高延迟网络（如移动网络）中，用户可能需要等待数百毫秒甚至数秒才能真正开始加载页面内容。

2012 年，Google 开始实验一个名为 SPDY 的协议，后来演变为 HTTP/2。同时，Google 也在研发一个全新的传输协议——QUIC（Quick UDP Internet Connections）。QUIC 的目标很明确：把 TCP 的可靠传输和 TLS 的安全性整合到 UDP 之上，彻底解决 TCP 的队头阻塞问题，同时大幅降低连接建立延迟。

2022 年，HTTP/3 作为 RFC 9114 正式发布，成为 HTTP 协议家族的最新成员。它的核心变化是：不再使用 TCP，而是运行在 QUIC 协议之上。

一、QUIC 协议详解#

1.1 QUIC vs TCP：架构对比#

1
┌─────────────────────────────────────────────────────────────┐
2
│                      传统 HTTP/1.1/2 架构                     │
3
├─────────────────────────────────────────────────────────────┤
4
│  HTTP 层 (请求/响应)                                         │
5
│  ──────────────────────────────────────────────────────────│
6
│  TLS 层 (加密)                                               │
7
│  ──────────────────────────────────────────────────────────│
8
│  TCP 层 (可靠传输、拥塞控制、流量控制)                         │
9
│  ──────────────────────────────────────────────────────────│
10
│  IP 层 (网络路由)                                            │
11
└─────────────────────────────────────────────────────────────┘
12

13
┌─────────────────────────────────────────────────────────────┐
14
│                      HTTP/3 架构                              │
15
├─────────────────────────────────────────────────────────────┤
16
│  HTTP/3 层 (请求/响应，类似 HTTP/2 帧)                        │
17
│  ──────────────────────────────────────────────────────────│
18
│  QUIC 层 (可靠传输 + 内置 TLS 1.3 + 多路复用 + 拥塞控制)       │
19
│  ──────────────────────────────────────────────────────────│
20
│  UDP 层 (无连接传输)                                         │
21
│  ──────────────────────────────────────────────────────────│
22
│  IP 层 (网络路由)                                            │
23
└─────────────────────────────────────────────────────────────┘

关键区别：

QUIC 内置加密：TLS 1.3 直接集成到 QUIC 握手中，所有 QUIC 数据包（包括握手包）都是加密的。这解决了 TCP + TLS 的「明文握手」问题。

QUIC 在 UDP 之上实现可靠性：QUIC 自己实现了丢包重传、拥塞控制、流量控制等机制。这意味着 QUIC 可以在不修改操作系统内核的情况下快速迭代。

QUIC 原生支持多路复用：QUIC 的「流」（Stream）概念直接支持多个独立的数据流，丢失一个流的数据包不会影响其他流。

1.2 连接建立：QUIC 如何实现 0-RTT#

TCP + TLS 1.2 的连接建立需要 2-3 个 RTT。QUIC 通过内置 TLS 1.3，可以实现惊人的 0-RTT 连接恢复：

1
首次连接（1-RTT）：
2
┌────────┐                              ┌────────┐
3
│ Client │                              │ Server │
4
└───┬────┘                              └───┬────┘
5
    │  Initial (ClientHello)                 │
6
    │  ──────────────────────────────────────>│
7
    │                                        │
8
    │  Handshake (ServerHello, Cert, ...)   │
9
    │  <─────────────────────────────────────│
10
    │                                        │
11
    │  Handshake (Finished)                  │
12
    │  ──────────────────────────────────────>│
13
    │                                        │
14
    │  (连接建立完成，服务器可以立即发送数据)    │
15

16
后续连接（0-RTT）：
17
┌────────┐                              ┌────────┐
18
│ Client │                              │ Server │
19
└───┬────┘                              └───┬────┘
20
    │  0-RTT 数据包 + ClientHello          │
21
    │  ──────────────────────────────────────>│
22
    │  (客户端立即发送 HTTP 请求！)            │
23
    │                                        │
24
    │  服务器处理请求并发送响应                │
25
    │  <─────────────────────────────────────│
26
    │                                        │

0-RTT 的原理是：客户端在首次连接成功后，服务器会返回一个「会话票据」（Session Ticket）。客户端保存这个票据，下次连接时可以立即发送加密数据，无需等待握手完成。

注意事项：0-RTT 数据有「重放攻击」风险，不适合非幂等请求（如支付、状态变更）。QUIC 协议本身不防止 0-RTT 重放，应用层需要自行处理。

1.3 解决队头阻塞：QUIC 的多流机制#

TCP 的队头阻塞问题可以用下图说明：

1
TCP 层面的队头阻塞：
2

3
时间 →
4
┌────────────────────────────────────────────────────────────────┐
5
│ Stream 1: [数据包1] [数据包2] [数据包3 丢失!] [数据包4] [数据包5] │
6
│                                        ↓                       │
7
│                              等待重传...                        │
8
│                                        ↓                       │
9
│ Stream 2: [数据包A] [数据包B] ← 到达了但被 TCP 缓存，无法交付   │
10
│ Stream 3: [数据包X] [数据包Y] ← 同样被阻塞                      │
11
└────────────────────────────────────────────────────────────────┘
12
                              所有流都等待！
13

14
QUIC 的独立流机制：
15

16
时间 →
17
┌────────────────────────────────────────────────────────────────┐
18
│ Stream 1: [数据包1] [数据包2] [数据包3 丢失!] [数据包4] [数据包5] │
19
│                                        ↓                       │
20
│                              只影响 Stream 1                    │
21
│                                                                │
22
│ Stream 2: [数据包A] [数据包B] [数据包C] ← 正常交付！             │
23
│ Stream 3: [数据包X] [数据包Y] [数据包Z] ← 正常交付！             │
24
└────────────────────────────────────────────────────────────────┘
25
                    每个流独立处理，互不影响

QUIC 的每个流都有独立的序列号空间，丢失一个流的数据包不会影响其他流的数据交付。这对于现代网页加载多个资源（HTML、CSS、JS、图片等）来说意义重大。

1.4 连接迁移：网络切换不中断#

TCP 连接由四元组标识：（源 IP、源端口、目的 IP、目的端口）。当用户从 WiFi 切换到移动网络时，IP 地址改变，TCP 连接就会断开。

QUIC 使用 Connection ID 来标识连接，而不是依赖四元组：

1
TCP 连接切换：
2

3
手机 (WiFi: 192.168.1.100:54321)          服务器 (203.0.113.1:443)
4
         │                                      │
5
         │  TCP 连接建立                          │
6
         │  ←───────────────────────────────────→│
7
         │                                      │
8
         │  用户切换到移动网络                     │
9
         │  IP 变为 10.0.0.50                    │
10
         │                                      │
11
         │   连接断开！需要重新建立连接           │
12
         │                                      │
13

14
QUIC 连接迁移：
15

16
手机 (WiFi: 192.168.1.100:54321)          服务器 (203.0.113.1:443)
17
         │                                      │
18
         │  QUIC 连接 (Connection ID: 0xABC123) │
19
         │  ←───────────────────────────────────→│
20
         │                                      │
21
         │  用户切换到移动网络                     │
22
         │  IP 变为 10.0.0.50，端口变为 54322    │
23
         │                                      │
24
         │  客户端发送带 Connection ID 的包       │
25
         │  ──────────────────────────────────────>│
26
         │                                      │
27
         │  服务器识别 Connection ID，继续连接    │
28
         │  <─────────────────────────────────────│
29
         │                                      │
30
         │   连接保持，下载继续！                │

这对于移动用户来说是巨大的体验提升。当你在地铁里从 WiFi 切换到移动网络时，正在进行的下载、视频通话不会中断。

二、HTTP/3 的具体变化#

2.1 从 HTTP/2 到 HTTP/3：帧格式变化#

HTTP/3 仍然使用「帧」（Frame）的概念，但帧格式有所调整以适应 QUIC：

1
HTTP/2 帧格式（在 TCP 流上）：
2
┌───────────────────────────────────────────────────────────┐
3
│ Length (24 bits) │ Type (8 bits) │ Flags (8 bits) │ R │ Stream ID (31 bits) │
4
├───────────────────────────────────────────────────────────┤
5
│                    Frame Payload                          │
6
└───────────────────────────────────────────────────────────┘
7

8
HTTP/3 帧格式（在 QUIC 流上）：
9
┌───────────────────────────────────────────────────────────┐
10
│ Type (varint) │ Length (varint) │ Frame Payload           │
11
└───────────────────────────────────────────────────────────┘

主要变化：

帧头更简洁：HTTP/3 使用可变长度整数（varint），不再需要 24 位固定长度字段。移除了 Flags 和保留位，因为 QUIC 流本身已经处理了这些功能。

Stream ID 由 QUIC 管理：HTTP/2 的 Stream ID 在帧头中，HTTP/3 的流标识由 QUIC 层管理，不再出现在帧头中。

帧类型调整：

2.2 QPACK：HTTP/3 的头部压缩#

HTTP/2 使用 HPACK 进行头部压缩，依赖传输层的顺序性。由于 QUIC 的多流是独立的，HTTP/3 引入了 QPACK（QPACK Header Compression for HTTP）：

1
HPACK (HTTP/2) 的问题：
2
- 依赖动态表的顺序更新
3
- 如果 Stream 3 的 HEADERS 帧丢失，后续流无法解码
4

5
QPACK (HTTP/3) 的解决方案：
6
┌─────────────────────────────────────────────────────────────┐
7
│                     QPACK 结构                               │
8
├─────────────────────────────────────────────────────────────┤
9
│  Encoder Stream（单向流）                                    │
10
│  - 发送动态表更新指令                                         │
11
│  - 独立于请求流                                               │
12
├─────────────────────────────────────────────────────────────┤
13
│  Decoder Stream（单向流）                                    │
14
│  - 确认已处理的动态表条目                                      │
15
│  - 允许 Encoder 安全地重用条目                                │
16
├─────────────────────────────────────────────────────────────┤
17
│  Request/Response Streams                                    │
18
│  - 只包含压缩后的头部索引                                     │
19
│  - 不受 Encoder/Decoder 流丢包影响                           │
20
└─────────────────────────────────────────────────────────────┘

QPACK 通过引入专门的编码器流和解码器流，实现了与 HPACK 相似的压缩效率，同时支持乱序处理。

2.3 流量控制与优先级#

HTTP/2 在应用层实现了流量控制和优先级，HTTP/3 则将这部分责任下放给 QUIC：

1
HTTP/2 的流量控制：
2
- 通过 WINDOW_UPDATE 帧管理
3
- 连接级别和流级别两个层次
4
- 应用层实现，与 TCP 流量控制可能冲突
5

6
HTTP/3 的流量控制：
7
- QUIC 层原生支持
8
- 连接级别（所有流总和）和流级别
9
- 自动流量控制帧（无需应用层处理）
10
- 与 QUIC 的拥塞控制协同工作

优先级方面，HTTP/2 的优先级机制相当复杂，实际实现效果参差不齐。HTTP/3 简化了这一设计，鼓励使用更简单的优先级模型。

2.4 不支持服务器推送#

HTTP/2 引入了服务器推送（Server Push），允许服务器主动向客户端发送资源。但实际使用中发现：

浏览器实现复杂
推送缓存难以管理
客户端可能已经有缓存
与现代预加载策略冲突

因此，HTTP/3 移除了服务器推送功能。取而代之的是更灵活的预加载机制（如 <link rel="preload">）和 103 Early Hints 状态码。

三、实验一：观察 HTTP/3 连接#

由于 QUIC 运行在 UDP 上，我们无法像之前的实验那样用 nc 或 telnet 直接连接。但可以通过现代工具观察 HTTP/3 的行为。

3.1 使用 curl 测试 HTTP/3#

1
# 确保 curl 支持 HTTP/3
2
curl --version | grep -i http3
3

4
# 如果支持，直接请求
5
curl --http3-only https://cloudflare-quic.com
6

7
# 观察连接信息
8
curl --http3-only -v https://cloudflare-quic.com 2>&1 | head -30

输出示例：

1
*   Trying [2606:4700:4700::1111]:443...
2
* Connected to cloudflare-quic.com (2606:4700:4700::1111) port 443
3
* ALPN: curl offers h3
4
* using QUIC version h3
5
* Connected to cloudflare-quic.com port 443
6
* SSL certificate verify ok.
7
* using HTTP/3
8
> GET / HTTP/3
9
> Host: cloudflare-quic.com
10
> User-Agent: curl/8.x.x
11
> Accept: */*
12
>
13
< HTTP/3 200
14
< content-type: text/html
15
< date: Fri, 20 Mar 2026 10:00:00 GMT

注意 using HTTP/3 和 HTTP/3 200 的标识。

3.2 比较连接时间#

1
# HTTP/1.1 连接时间
2
curl -w "Connect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
3
     -o /dev/null -s https://cloudflare-quic.com
4

5
# HTTP/2 连接时间
6
curl --http2 -w "Connect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
7
     -o /dev/null -s https://cloudflare-quic.com
8

9
# HTTP/3 连接时间（首次连接）
10
curl --http3-only -w "Connect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
11
     -o /dev/null -s https://cloudflare-quic.com

典型结果：HTTP/3 的首次连接时间略长（因为 QUIC 握手），但后续连接（0-RTT）会快很多。

3.3 使用 Chrome DevTools 观察#

打开 Chrome DevTools → Network 标签 → 右键列标题 → 勾选「Protocol」：

1
访问支持 HTTP/3 的网站（如 google.com、cloudflare.com），
2
Protocol 列会显示 "h3" 或 "h3-29"。
3

4
点击具体请求 → 查看详情：
5
- Connection ID: QUIC 连接标识
6
- Stream ID: 当前请求的流标识
7
- RTT: 往返时间
8
- Encrypted: 是否加密

五、实验二：用 Python 发起 HTTP/3 请求#

Python 标准库目前不支持 HTTP/3，但可以使用第三方库：

1
pip install aioquic http3

简单的 HTTP/3 客户端示例：

1
#!/usr/bin/env python3
2
# http3_client.py -- HTTP/3 client demo
3
import asyncio
4
from aioquic.asyncio.client import connect
5
from aioquic.h3.connection import H3Connection
6
from aioquic.h3.events import HeadersReceived, DataReceived
7

8
async def http3_get(url: str):
9
    """
10
    发起 HTTP/3 GET 请求
11
    注意：这是一个简化的演示，实际使用建议用 httpx 等成熟库
12
    """
13
    from urllib.parse import urlparse
14

15
    parsed = urlparse(url)
16
    host = parsed.hostname
17
    port = parsed.port or 443
18
    path = parsed.path or "/"
19

20
    async with connect(host, port) as protocol:
21
        connection = H3Connection(protocol._quic)
22

23
        # 创建请求流
24
        stream_id = connection._quic.get_next_available_stream_id()
25

26
        # 发送 HEADERS 帧
27
        headers = [
28
            (b":method", b"GET"),
29
            (b":scheme", b"https"),
30
            (b":authority", host.encode()),
31
            (b":path", path.encode()),
32
            (b"user-agent", b"http3-demo/1.0"),
33
        ]
34
        connection.send_headers(stream_id, headers)
35
        connection.send_data(stream_id, b"", end_stream=True)
36

37
        # 接收响应
38
        response_headers = {}
39
        response_body = b""
40

41
        while True:
42
            event = await connection.wait_for_event(stream_id)
43
            if isinstance(event, HeadersReceived):
44
                for name, value in event.headers:
45
                    response_headers[name.decode()] = value.decode()
46
            elif isinstance(event, DataReceived):
47
                response_body += event.data
48
                if event.stream_ended:
49
                    break
50

51
        return response_headers, response_body
52

53
if __name__ == "__main__":
54
    # 演示用：实际需要 aioquic 完整环境
55
    print("HTTP/3 客户端演示")
56
    print("建议使用 httpx 或 curl 进行实际 HTTP/3 请求")

实际生产环境推荐使用 httpx：

1
#!/usr/bin/env python3
2
# httpx_http3.py -- 使用 httpx 发起 HTTP/3 请求
3
import httpx
4

5
# httpx 支持 HTTP/3（需要安装 httpx[http2]）
6
async def fetch_with_http3():
7
    async with httpx.AsyncClient(http2=True, http3=True) as client:
8
        response = await client.get("https://cloudflare-quic.com")
9
        print(f"Protocol: {response.extensions.get('http_version')}")
10
        print(f"Status: {response.status_code}")
11
        print(f"Body length: {len(response.content)}")
12

13
# 同步方式
14
def fetch_sync():
15
    with httpx.Client(http3=True) as client:
16
        response = client.get("https://cloudflare-quic.com")
17
        print(f"Status: {response.status_code}")
18

19
if __name__ == "__main__":
20
    import asyncio
21
    asyncio.run(fetch_with_http3())

六、实验三：观察 QUIC 数据包#

使用 Wireshark 或 tcpdump 可以观察到 QUIC 运行在 UDP 之上：

1
# 使用 tcpdump 捕获 QUIC 流量（UDP 443 端口）
2
sudo tcpdump -i any -n udp port 443 -w quic_capture.pcap
3

4
# 在另一个终端发起 HTTP/3 请求
5
curl --http3-only https://cloudflare-quic.com
6

7
# 用 Wireshark 分析捕获文件
8
wireshark quic_capture.pcap

在 Wireshark 中你会看到：

1
No.  Time      Source          Dest           Protocol  Info
2
1    0.000     192.168.1.100   104.16.133.229 UDP       54321 → 443 Len=1250 (QUIC Initial)
3
2    0.025     104.16.133.229  192.168.1.100  UDP       443 → 54321 Len=1250 (QUIC Initial)
4
3    0.026     104.16.133.229  192.168.1.100  UDP       443 → 54321 Len=1250 (QUIC Handshake)
5
4    0.051     192.168.1.100   104.16.133.229 UDP       54321 → 443 Len=100 (QUIC Handshake)
6
5    0.075     104.16.133.229  192.168.1.100  UDP       443 → 54321 Len=1250 (QUIC 1-RTT Protected)

注意：

所有 QUIC 数据包都是加密的，无法看到明文内容
Initial 包虽然加密，但使用公开密钥，可以被识别为 QUIC Initial
1-RTT Protected 包使用会话密钥加密，完全不可解密（除非有会话密钥）

七、浏览器与服务器支持现状#

7.1 浏览器支持#

| 浏览器 | HTTP/3 支持 | 默认启用 | 说明 | | Chrome 87+ | 是 | 是 | 稳定支持 | | Firefox 88+ | 是 | 是 | 稳定支持 | | Safari 16+ | 是 | 是 | macOS Ventura、iOS 16+ | | Edge 87+ | 是 | 是 | 基于 Chromium | | Opera 73+ | 是 | 是 | 基于 Chromium |

浏览器发现 HTTP/3 支持的方式：

Alt-Svc 头：服务器返回 Alt-Svc: h3=":443"; ma=2592000，告诉客户端支持 HTTP/3
HTTP/3 专用端口：客户端下次连接时尝试 HTTP/3

7.2 服务器支持#

主流 Web 服务器和 CDN 的支持情况：

1
┌───────────────────────────────────────────────────────────────┐
2
│                    HTTP/3 服务器支持                           │
3
├────────────┬─────────────────────────────────────────────────┤
4
│ Nginx      │ 1.25+ 主线版本支持，需编译时启用 --with-http_v3_module │
5
│ Apache     │ 2.4.58+ 支持 mod_http3                           │
6
│ Caddy      │ v2.6+ 默认启用 HTTP/3                             │
7
│ Traefik    │ v2.5+ 支持 HTTP/3                                 │
8
│ Cloudflare │ 全面支持 HTTP/3                                   │
9
│ AWS ALB    │ 支持 HTTP/3                                       │
10
│ GCP LB     │ 支持 HTTP/3                                       │
11
│ Fastly     │ 支持 HTTP/3                                       │
12
└────────────┴─────────────────────────────────────────────────┘

Nginx 配置示例：

1
server {
2
    listen 443 quic reuseport;
3
    listen 443 ssl;
4
    server_name example.com;
5

6
    ssl_certificate /path/to/cert.pem;
7
    ssl_certificate_key /path/to/key.pem;
8

9
    # 启用 HTTP/3
10
    http3 on;
11
    http3_hq on;  # 也支持 HTTP/0.9 over QUIC
12

13
    # Alt-Svc 头，告诉浏览器支持 HTTP/3
14
    add_header Alt-Svc 'h3=":443"; ma=86400';
15

16
    location / {
17
        root /var/www/html;
18
    }
19
}

Caddy 配置（更简单）：

1
# Caddy 默认启用 HTTP/3，无需额外配置
2
example.com {
3
    root * /var/www/html
4
    file_server
5
}

八、HTTP 版本对比总览#

1
┌─────────────────────────────────────────────────────────────────────────────┐
2
│                         HTTP 协议演进对比                                     │
3
├─────────────┬───────────────┬───────────────┬───────────────┬───────────────┤
4
│    特性      │   HTTP/1.0    │   HTTP/1.1    │    HTTP/2     │    HTTP/3     │
5
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
6
│ 传输层协议   │ TCP           │ TCP           │ TCP           │ QUIC (UDP)    │
7
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
8
│ 连接复用     │  每次新建    │  Keep-Alive  │  多路复用    │  多路复用    │
9
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
10
│ 队头阻塞     │ 严重（连接级） │ 严重（连接级） │ 存在（TCP级） │  已解决      │
11
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
12
│ 头部压缩     │  无          │  无          │  HPACK      │  QPACK      │
13
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
14
│ 加密        │ 可选          │ 可选          │ 可选          │ 强制（TLS 1.3）│
15
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
16
│ 连接建立延迟 │ 1-3 RTT       │ 1-3 RTT       │ 1-3 RTT       │ 0-1 RTT       │
17
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
18
│ 服务器推送   │  不支持      │  不支持      │  支持        │  移除        │
19
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
20
│ 连接迁移     │  不支持      │  不支持      │  不支持      │  支持        │
21
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
22
│ 请求方法     │ GET/POST/HEAD │ 全部方法      │ 全部方法      │ 全部方法      │
23
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
24
│ 二进制协议   │  文本        │  文本        │  二进制帧    │  二进制帧    │
25
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
26
│ 发布年份     │ 1996          │ 1997/1999     │ 2015          │ 2022          │
27
├─────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
28
│ RFC 编号    │ RFC 1945      │ RFC 2616/7230 │ RFC 7540/9113 │ RFC 9114      │
29
└─────────────┴───────────────┴───────────────┴───────────────┴───────────────┘

九、何时选择 HTTP/3#

HTTP/3 并非万能药，适用场景：

推荐使用 HTTP/3：

移动网络环境（WiFi 与蜂窝网络频繁切换）
高延迟网络（跨国访问、卫星网络）
大量并发请求的页面（SPA、资源丰富的网站）
实时通信应用（视频会议、在线游戏）

HTTP/2 仍然够用：

服务器不支持 QUIC
客户端环境受限
网络稳定、延迟低的场景
不需要连接迁移的场景

注意 QUIC 的开销：

UDP 在某些网络环境下可能被限速或屏蔽
QUIC 的加密有 CPU 开销
首次连接的 1-RTT 握手（但后续 0-RTT 会更快）

十、观察总结#

通过这次实验，你应该能够：

理解 QUIC 的设计目标：把 TCP 的可靠传输和 TLS 的安全性整合到 UDP 之上，彻底解决 TCP 的队头阻塞问题，同时大幅降低连接建立延迟。

掌握 HTTP/3 的核心变化：不再使用 TCP、帧格式简化、QPACK 头部压缩、移除服务器推送、流量控制下放到 QUIC 层。

理解 0-RTT 的原理与风险：首次连接后保存会话票据，后续连接可以立即发送数据；但需要注意重放攻击风险，不适合非幂等请求。

理解连接迁移的意义：QUIC 使用 Connection ID 标识连接，网络切换时连接不断，提升移动用户体验。

能用工具观察 HTTP/3 行为：使用 curl --http3-only 测试 HTTP/3 连接，使用 Chrome DevTools 观察协议，使用 Wireshark 分析 QUIC 数据包。

了解 HTTP/3 的适用场景：高延迟网络、移动网络切换、大量并发请求等场景受益最大。

HTTP/3 代表了 Web 协议的未来方向。随着 QUIC 和 HTTP/3 的普及，用户将体验到更快的页面加载速度和更稳定的网络连接。理解 HTTP/3，是理解现代 Web 性能优化的。

参考#

RFC 1945 — Hypertext Transfer Protocol — HTTP/1.0
RFC 2616 — Hypertext Transfer Protocol — HTTP/1.1
RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2)
RFC 9114

支持与分享

如果这篇文章对你有帮助，欢迎支持作者或分享给更多人

赞助

HTTP/3：QUIC 传输

https://blog.souloss.com/posts/web/http-3/

作者

Souloss

发布于

2023-05-01

许可协议

CC BY-NC-SA 4.0

部分信息可能已经过时

为什么 Go 语言没有泛型

MySQL 查询执行流程：从 SQL 到结果集