🚀 HTTP/3 與 QUIC：下一代網路協定

⏱️ 閱讀時間： 15 分鐘 🎯 難度： ⭐⭐⭐ (中等偏難)

🏗️ HTTP/3 在網路模型中的位置

OSI 7 層模型

┌──────────────────────────────┬─────────────────────────┐
│ 7. Application Layer (應用層) │  HTTP/3                 │ ← HTTP/3 在這裡
├──────────────────────────────┼─────────────────────────┤
│ 6. Presentation Layer (表示層)│  TLS 1.3 (整合在 QUIC)   │
├──────────────────────────────┼─────────────────────────┤
│ 5. Session Layer (會話層)     │  QUIC                   │ ← QUIC 在這裡
├──────────────────────────────┼─────────────────────────┤
│ 4. Transport Layer (傳輸層)   │  UDP                    │ ← 使用 UDP！
├──────────────────────────────┼─────────────────────────┤
│ 3. Network Layer (網路層)     │  IP                     │
├──────────────────────────────┼─────────────────────────┤
│ 2. Data Link Layer (資料鏈結層)│  Ethernet               │
├──────────────────────────────┼─────────────────────────┤
│ 1. Physical Layer (實體層)    │  網路線、光纖            │
└──────────────────────────────┴─────────────────────────┘

TCP/IP 4 層模型

┌─────────────────────────────┬─────────────────────────┐
│ 4. Application Layer (應用層) │  HTTP/3                 │ ← HTTP/3 在這裡
│                             │  QUIC                   │ ← QUIC 在這裡
├─────────────────────────────┼─────────────────────────┤
│ 3. Transport Layer (傳輸層)  │  UDP                    │ ← 使用 UDP！
├─────────────────────────────┼─────────────────────────┤
│ 2. Internet Layer (網際網路層)│  IP                     │
├─────────────────────────────┼─────────────────────────┤
│ 1. Network Access (網路存取層)│  Ethernet               │
└─────────────────────────────┴─────────────────────────┘

重點：HTTP/3 的革命性改變

• HTTP/1.1 和 HTTP/2：使用 TCP
• HTTP/3：使用 UDP 上的 QUIC
• QUIC 在應用層實現了 TCP 的可靠性 + 更多優化

📊 HTTP 演進史 ⭐⭐⭐

一圖看懂三代 HTTP

HTTP/1.1 (1997)                HTTP/2 (2015)              HTTP/3 (2022)
     │                              │                          │
     ├─ TCP                         ├─ TCP                     ├─ UDP (QUIC)
     ├─ 明文傳輸                     ├─ 強制 TLS                ├─ 內建 TLS 1.3
     ├─ 一次一個請求                 ├─ 多路復用                ├─ 改進的多路復用
     ├─ Head-of-Line Blocking       ├─ 仍有 TCP HOL Blocking   ├─ 解決 HOL Blocking
     └─ 無連線復用                   └─ 二進位分幀              └─ 0-RTT 連線恢復

效能：★☆☆☆☆                    ★★★☆☆                    ★★★★★

🎯 為什麼需要 HTTP/3？

HTTP/2 的問題：TCP Head-of-Line Blocking

HTTP/2 over TCP 的問題：

瀏覽器請求 3 個檔案：
┌────────┐ ┌────────┐ ┌────────┐
│ CSS    │ │ JS     │ │ Image  │
└────────┘ └────────┘ └────────┘
     │          │          │
     └──────────┴──────────┘
             │
        多路復用到同一個 TCP 連線
             │
         ┌───▼───┐
         │  TCP  │
         └───┬───┘
             │
      如果某個 TCP 封包遺失...
             │
         ┌───▼───┐
         │ 遺失! │  ← 整個 TCP 連線卡住！
         └───────┘
             │
    所有請求都要等待重傳
    （即使其他請求的資料已經到達）

這就是 TCP Head-of-Line Blocking！

生活化比喻：

想像一個單線道隧道：

HTTP/1.1：
一次只能過一台車 🚗
效率很低

HTTP/2：
隧道可以同時傳送多個包裹 📦📦📦
但如果隧道某處塞車，所有包裹都卡住

HTTP/3：
改用多條獨立小徑 🛤️🛤️🛤️
某條小徑塞車不影響其他小徑

🔧 QUIC 協定：HTTP/3 的基石

QUIC 是什麼？

QUIC = Quick UDP Internet Connections
     = 快速 UDP 網路連線

由 Google 在 2013 年開發
2021 年成為 IETF RFC 9000 標準

QUIC 的核心設計：

傳統：HTTP/2 over TCP over TLS
┌─────────────┐
│   HTTP/2    │
├─────────────┤
│     TLS     │  ← 需要 TLS 握手
├─────────────┤
│     TCP     │  ← 需要 TCP 握手
├─────────────┤
│     IP      │
└─────────────┘

新設計：HTTP/3 over QUIC
┌─────────────┐
│   HTTP/3    │
├─────────────┤
│    QUIC     │  ← TLS 1.3 內建在 QUIC！
├─────────────┤  ← 基於 UDP
│     UDP     │
├─────────────┤
│     IP      │
└─────────────┘

🚀 QUIC 的關鍵特性

1. 使用 UDP 作為傳輸層 ⭐⭐⭐

為什麼用 UDP 而不是 TCP？

UDP 的優勢：

1. 無連線狀態
   → 不需要 3-way handshake
   → 連線建立更快

2. 靈活性
   → QUIC 在用戶空間實現
   → 不需要修改作業系統核心
   → 更新協定更容易

3. 避免 TCP 的歷史包袱
   → TCP 在核心實現，難以更新
   → QUIC 可以快速迭代改進

2. 0-RTT 連線恢復 ⭐⭐⭐

傳統 TCP + TLS 連線建立：

客戶端                              伺服器
  │                                   │
  ├─ SYN ──────────────────────────>│  (TCP handshake)
  │<────────────────────── SYN-ACK ──┤
  ├─ ACK ──────────────────────────>│
  │                                   │
  ├─ ClientHello ───────────────────>│  (TLS handshake)
  │<──────────────────── ServerHello ─┤
  │<────────────────── Certificate ───┤
  │<─────────────── ServerHelloDone ──┤
  ├─ ClientKeyExchange ─────────────>│
  ├─ ChangeCipherSpec ──────────────>│
  │<────────────── ChangeCipherSpec ──┤
  │                                   │
  ├─ HTTP Request ──────────────────>│  (終於可以發請求！)
  │<──────────────────── HTTP Response ┤

總共：2-RTT (TCP) + 2-RTT (TLS) = 4-RTT

QUIC 0-RTT：

客戶端                              伺服器
  │                                   │
首次連線：
  ├─ ClientHello (QUIC + TLS) ──────>│
  │<─ ServerHello + Data ────────────┤
  │                                   │
  ├─ Request + Data ───────────────>│
  │<─ Response ──────────────────────┤

總共：1-RTT

───────────────────────────────────────

再次連線（使用之前的金鑰）：
  ├─ Request + Data (用舊金鑰加密) ─>│
  │<─ Response ──────────────────────┤

總共：0-RTT！

效能提升：

TCP + TLS 1.2：4-RTT
TCP + TLS 1.3：2-RTT
QUIC (首次)：  1-RTT
QUIC (恢復)：  0-RTT  ← 最快！

3. 連線遷移 (Connection Migration)

TCP 的問題：

TCP 連線由四元組標識：
(來源 IP, 來源 Port, 目標 IP, 目標 Port)

場景：手機從 Wi-Fi 切換到 4G
├─ IP 位址改變
└─ TCP 連線中斷，需要重新建立 ❌

QUIC 的解決方案：

QUIC 使用 Connection ID：
一個 64-bit 的隨機數

場景：手機從 Wi-Fi 切換到 4G
├─ IP 位址改變
├─ Connection ID 不變
└─ 連線無縫切換 ✅

客戶端                              伺服器
  │                                   │
  ├─ 使用 Wi-Fi (IP: 192.168.1.10) ─>│
  │  Connection ID: 0x1234567890abcdef│
  │                                   │
  │ [切換到 4G]                        │
  │                                   │
  ├─ 使用 4G (IP: 203.0.113.42) ────>│
  │  Connection ID: 0x1234567890abcdef│ ← 相同的 ID！
  │<─ 確認收到 ─────────────────────┤
  │                                   │
  └─ 連線繼續，無需重建 ✅            │

應用場景：

• 移動設備在不同網路間切換
• 筆記本從有線切換到無線
• 保持視訊通話不中斷

4. 獨立串流 (Independent Streams)

HTTP/2 over TCP 的問題：

HTTP/2 多個請求在同一個 TCP 連線：

串流 1: CSS  [■■■■■]
串流 2: JS   [■■■■■]
串流 3: IMG  [■■■■■]
           ↓
      合併到 TCP
           ↓
    [■■■X■■■■■■■■■]
        ↑
     遺失一個封包
        ↓
   所有串流都卡住！ ❌
   （即使遺失的是 CSS，JS 和 IMG 也要等）

QUIC 的解決方案：

每個串流獨立處理：

串流 1: CSS  [■■■■■]  ← 獨立的可靠性保證
串流 2: JS   [■■X■■]  ← 封包遺失
串流 3: IMG  [■■■■■]  ← 獨立的可靠性保證
           ↓
    只有串流 2 需要重傳
    串流 1 和 3 繼續傳輸 ✅

技術細節：

QUIC Stream Frame：
┌──────────────┬──────────────┬──────────────┐
│ Stream ID    │ Offset       │ Data         │
├──────────────┼──────────────┼──────────────┤
│ 識別哪個串流   │ 資料在串流中   │ 實際資料      │
│              │ 的位置        │              │
└──────────────┴──────────────┴──────────────┘

每個串流：
- 有獨立的序號
- 獨立的流量控制
- 獨立的重傳機制

5. 內建加密 (TLS 1.3)

對比：

HTTP/2：
┌─────────────┐
│   HTTP/2    │  ← 可選 TLS（實務上強制）
├─────────────┤
│     TLS     │  ← 需要額外握手
├─────────────┤
│     TCP     │
└─────────────┘

HTTP/3：
┌─────────────┐
│   HTTP/3    │
├─────────────┤
│    QUIC     │  ← TLS 1.3 內建！
│  (含 TLS)   │  ← 無法禁用
└─────────────┘

優勢：

• 所有 QUIC 連線都是加密的
• 減少握手次數（QUIC + TLS 合併）
• 使用最新的 TLS 1.3

🆚 HTTP/2 vs HTTP/3 對比

完整對比表

效能對比 (實際測試)

場景：載入包含 100 個資源的網頁

無封包遺失：
HTTP/1.1: ████████████████ 8.2s
HTTP/2:   ████████ 4.1s
HTTP/3:   ██████ 3.5s

1% 封包遺失率：
HTTP/1.1: ████████████████████████ 12.5s
HTTP/2:   ████████████████ 8.9s      ← TCP HOL Blocking
HTTP/3:   ████████ 4.2s              ← 影響小得多！

移動網路（高延遲 + 封包遺失）：
HTTP/1.1: ██████████████████████████████ 15.8s
HTTP/2:   ████████████████████ 10.3s
HTTP/3:   ██████████ 5.1s              ← 最佳！

💻 HTTP/3 實戰

檢查網站是否支援 HTTP/3

使用瀏覽器：

1. 打開 Chrome DevTools (F12)
2. 切換到 Network 標籤
3. 右鍵表頭 → 勾選 "Protocol"
4. 重新載入頁面
5. 查看 Protocol 欄位：
   - h3 或 h3-29 = HTTP/3 ✅
   - h2 = HTTP/2
   - http/1.1 = HTTP/1.1

使用 curl：

# 需要 curl 7.66.0+ 且編譯時啟用 HTTP/3
curl --http3 -I https://www.google.com

# 查看詳細資訊
curl --http3 -v https://www.cloudflare.com

使用 Python（aioquic）：

import asyncio
from aioquic.asyncio import connect
from aioquic.h3.connection import H3Connection
from aioquic.quic.configuration import QuicConfiguration

async def http3_request(url):
    """發送 HTTP/3 請求"""

    # 解析 URL
    from urllib.parse import urlparse
    parsed = urlparse(url)
    host = parsed.hostname
    port = parsed.port or 443
    path = parsed.path or '/'

    # QUIC 設定
    config = QuicConfiguration(
        is_client=True,
        alpn_protocols=["h3"],  # HTTP/3
    )

    # 建立連線
    async with connect(
        host,
        port,
        configuration=config,
    ) as protocol:
        # 建立 HTTP/3 連線
        h3_conn = H3Connection(protocol._quic)

        # 發送請求
        stream_id = h3_conn.get_next_available_stream_id()
        h3_conn.send_headers(
            stream_id=stream_id,
            headers=[
                (b":method", b"GET"),
                (b":scheme", b"https"),
                (b":authority", host.encode()),
                (b":path", path.encode()),
            ],
        )
        h3_conn.send_data(stream_id=stream_id, data=b"", end_stream=True)

        # 接收回應
        # （實際使用需要處理事件循環）
        print(f"HTTP/3 request sent to {url}")

# 使用
asyncio.run(http3_request("https://www.google.com"))

伺服器端啟用 HTTP/3

Nginx（從 1.25.0 開始支援）：

server {
    listen 443 ssl;              # HTTP/2
    listen 443 quic reuseport;   # HTTP/3

    http2 on;                    # 啟用 HTTP/2
    http3 on;                    # 啟用 HTTP/3

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    # 添加 Alt-Svc header 告知客戶端支援 HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';

    location / {
        root /var/www/html;
    }
}

Caddy（原生支援）：

example.com {
    # Caddy 自動啟用 HTTP/3！
    root * /var/www/html
    file_server
}

Node.js (使用 quiche)：

const { createQuicSocket } = require('net');
const { constants } = require('crypto');

// HTTP/3 伺服器
const socket = createQuicSocket({
    endpoint: {
        port: 443,
        address: '0.0.0.0'
    }
});

socket.listen({
    key: '...',
    cert: '...',
    alpn: 'h3'  // HTTP/3
});

socket.on('session', (session) => {
    session.on('stream', (stream) => {
        stream.on('data', (chunk) => {
            // 處理 HTTP/3 請求
        });

        // 發送 HTTP/3 回應
        stream.write('...');
        stream.end();
    });
});

🌐 Alt-Svc：HTTP/3 的發現機制

問題： 客戶端如何知道伺服器支援 HTTP/3？

解決方案： Alt-Svc (Alternative Services) Header

HTTP/2 Request:
GET / HTTP/2
Host: example.com

HTTP/2 Response:
HTTP/2 200 OK
Alt-Svc: h3=":443"; ma=86400
         │   │      │
         │   │      └─ max-age: 24 小時
         │   └──────── Port 443
         └──────────── 支援 HTTP/3

Content-Type: text/html
...

流程：

客戶端                              伺服器
  │                                   │
  ├─ HTTP/2 Request ───────────────>│
  │<─ HTTP/2 Response ───────────────┤
  │  Alt-Svc: h3=":443"               │
  │                                   │
  │ [客戶端記住：這個伺服器支援 HTTP/3] │
  │                                   │
  ├─ HTTP/3 Request (下次) ─────────>│
  │  (使用 QUIC over UDP)             │
  │<─ HTTP/3 Response ────────────────┤

🎓 常見面試題

Q1：HTTP/3 為什麼使用 UDP 而不是 TCP？

答案：

主要原因：

1. TCP 的 Head-of-Line Blocking 問題

HTTP/2 多路復用在 TCP 上：
串流 1: [■■■■■]
串流 2: [■■X■■]  ← 封包遺失
串流 3: [■■■■■]
         ↓
    所有串流都卡住！

原因：TCP 保證嚴格順序
→ 封包 5 遺失，封包 6-10 都要等

QUIC 在 UDP 上：
串流獨立處理
→ 只有串流 2 重傳
→ 串流 1 和 3 繼續傳輸 ✅

2. TCP 難以升級

問題：
- TCP 在作業系統核心實現
- 修改 TCP 需要更新核心
- 中間設備（路由器、防火牆）可能不支援新版 TCP
- 升級週期長達數年甚至數十年

QUIC 的優勢：
- 在用戶空間（應用層）實現
- 透過軟體更新即可升級
- 不受中間設備限制（對它們來說就是普通 UDP）
- 可以快速迭代改進

3. 連線建立更快

TCP + TLS 1.3：2-RTT
├─ TCP handshake: 1-RTT
└─ TLS handshake: 1-RTT

QUIC：1-RTT (首次) / 0-RTT (恢復)
└─ QUIC + TLS 合併握手

4. 連線遷移

TCP：依賴 (IP, Port) 四元組
→ IP 改變 = 連線中斷

QUIC：使用 Connection ID
→ IP 改變 = 連線保持 ✅

記憶技巧：

UDP = 空白畫布
TCP = 已經畫好的圖（難修改）

QUIC 在 UDP 這張空白畫布上：
✅ 自己實現可靠性
✅ 自己實現擁塞控制
✅ 自己實現流量控制
✅ 加上 TCP 沒有的新功能（連線遷移、獨立串流）

Q2：HTTP/3 解決了什麼問題？

答案：

1. Head-of-Line Blocking（隊頭阻塞）⭐⭐⭐

問題：HTTP/2 的 TCP HOL Blocking

場景：載入網頁，請求 CSS、JS、圖片
┌─────┬─────┬─────┐
│ CSS │ JS  │ IMG │
└─────┴─────┴─────┘
      ↓
  合併到一個 TCP 連線
      ↓
  [■■■X■■■■■■]
      ↑
   遺失 1%
      ↓
全部請求延遲增加 300%！

解決方案：QUIC 獨立串流
┌─────┐ ┌─────┐ ┌─────┐
│ CSS │ │ JS  │ │ IMG │
└─────┘ └──X──┘ └─────┘
   ✅      ↓       ✅
        只重傳 JS
    CSS 和 IMG 正常傳輸

2. 連線建立延遲

HTTP/2：2-3 RTT
┌───────────────────────────────┐
│ TCP handshake    (1-RTT)      │
│ TLS handshake    (1-2 RTT)    │
│ HTTP request     (1-RTT)      │
└───────────────────────────────┘
總計：3-4 RTT

HTTP/3：0-1 RTT
┌───────────────────────────────┐
│ QUIC + TLS (首次)  (1-RTT)    │
│ QUIC + TLS (恢復)  (0-RTT) ✅ │
└───────────────────────────────┘

效能提升：
首次連線快 50%
恢復連線快 75%

3. 移動網路的連線中斷

場景：手機從 Wi-Fi 切換到 4G

HTTP/2 over TCP：
Wi-Fi (IP: 192.168.1.10)
       ↓
    [下載中...]
       ↓
切換到 4G (IP: 203.0.113.42)
       ↓
    TCP 連線中斷 ❌
       ↓
    重新建立連線 (3-RTT)
       ↓
    重新開始下載

HTTP/3 over QUIC：
Wi-Fi (Connection ID: 0x1234...)
       ↓
    [下載中...]
       ↓
切換到 4G (Connection ID: 0x1234...)
       ↓
    連線保持 ✅
       ↓
    繼續下載

4. 協定僵化

問題：TCP 難以升級
- 新的 TCP 選項可能被中間設備丟棄
- 升級需要數年時間

解決：QUIC 在用戶空間
- 對中間設備透明（看起來就是 UDP）
- 瀏覽器/伺服器更新即可
- 快速迭代

Q3：HTTP/3 的缺點是什麼？

答案：

1. UDP 封包可能被封鎖

問題：
某些企業防火牆或 ISP 封鎖 UDP 443
（擔心安全問題或 VPN 繞過）

解決方案：
HTTP/3 實現必須能降級到 HTTP/2
┌────────────────────────────┐
│ 1. 嘗試 HTTP/3 (QUIC/UDP)  │
│ 2. 如果失敗，降級到 HTTP/2  │
│ 3. 如果失敗，降級到 HTTP/1.1│
└────────────────────────────┘

2. CPU 使用率較高

原因：
TCP 在核心實現 → 硬體加速
QUIC 在用戶空間 → 純軟體實現

影響：
- 加密/解密在應用層
- 封包處理在應用層
- CPU 使用率增加 20-50%

緩解：
- 硬體加速逐漸支援
- QUIC 實現持續優化
- 對大多數應用影響有限

3. 中間設備支援不足

問題：
- 某些 NAT 設備對 UDP 支援不佳
- UDP 連線追蹤超時較短
- QoS 可能優先處理 TCP

現狀：
- 主要 CDN 已支援（Cloudflare、Fastly）
- Google、Facebook 大量部署
- 支援度持續改善

4. 除錯較困難

TCP：
- Wireshark 完整支援
- 豐富的除錯工具
- 成熟的分析方法

QUIC：
- 加密難以檢查
- 工具支援較少
- 需要新的除錯技能

解決：
- Chrome DevTools 支援 HTTP/3
- QUIC 專用分析工具逐漸成熟

Q4：什麼時候應該使用 HTTP/3？

答案：

✅ 適合使用 HTTP/3 的場景：

1. 移動應用

原因：
- 網路切換頻繁（Wi-Fi ↔ 4G/5G）
- 連線遷移非常有用
- 封包遺失率較高

收益：
- 連線保持率提升 90%
- 載入時間減少 30-50%

2. 高延遲網路

原因：
- 0-RTT 恢復連線
- 減少握手往返

適用：
- 跨國連線
- 衛星網路
- 偏遠地區

收益：
- 首次載入快 30%
- 重複訪問快 50%

3. 多資源網頁

原因：
- 獨立串流避免 HOL Blocking
- 多個請求並行

適用：
- 新聞網站
- 社交媒體
- 電商網站

收益：
- 頁面載入時間減少 20-40%

4. 視訊串流

原因：
- 丟包不影響其他幀
- 低延遲

適用：
- YouTube
- Netflix
- 直播平台

收益：
- 緩衝減少 60%
- 畫質提升

❌ 不建議使用的場景：

1. 內網應用

原因：
- 低延遲、低丟包
- HTTP/2 已經足夠好
- HTTP/3 CPU 開銷不划算

2. 檔案下載

原因：
- 單一串流
- HTTP/2 效能相當

例外：
- 斷點續傳需要連線遷移時考慮

3. 受限網路環境

原因：
- UDP 可能被封鎖
- 不如保證降級機制完善

Q5：如何檢測和啟用 HTTP/3？

答案：

客戶端檢測：

1. 瀏覽器 DevTools

Chrome/Edge：
1. F12 打開 DevTools
2. Network 標籤
3. 右鍵表頭 → Protocol
4. 查看：h3 = HTTP/3

Firefox：
1. F12 打開 DevTools
2. Network 標籤
3. 點擊請求 → Headers
4. 查看 HTTP Version

2. curl 命令

# 檢查支援（需要 curl 7.66+）
curl --http3 -I https://cloudflare.com

# 詳細資訊
curl --http3 -v https://google.com 2>&1 | grep "HTTP/3"

# 輸出範例
< HTTP/3 200

3. JavaScript 檢測

// 檢查瀏覽器支援
async function checkHTTP3Support(url) {
    try {
        const response = await fetch(url);
        const protocol = response.headers.get('Alt-Svc');

        if (protocol && protocol.includes('h3')) {
            console.log('✅ 伺服器支援 HTTP/3');
            return true;
        }
    } catch (error) {
        console.error('檢查失敗:', error);
    }
    return false;
}

// 使用
checkHTTP3Support('https://www.google.com');

伺服器啟用：

1. Nginx (1.25.0+)

server {
    listen 443 ssl http2;           # HTTP/2
    listen 443 quic reuseport;      # HTTP/3

    http2 on;
    http3 on;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    # 告知客戶端支援 HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # QUIC 特定設定
    ssl_early_data on;  # 啟用 0-RTT
}

2. Caddy (自動支援)

example.com {
    # Caddy 自動啟用 HTTP/3！
    encode gzip
    file_server
}

3. Apache (mod_http2)

# 需要 Apache 2.4.17+ 和 nghttp2
LoadModule http2_module modules/mod_http2.so

<VirtualHost *:443>
    Protocols h2 http/1.1
    # HTTP/3 支援正在開發中
</VirtualHost>

4. 驗證設定

# 使用線上工具
https://http3check.net

# 使用 curl
curl --http3 -I https://your-domain.com

# 預期輸出
HTTP/3 200
alt-svc: h3=":443"; ma=86400

📝 總結

HTTP/3 和 QUIC 的核心要點：

革命性改變：

• 傳輸層：從 TCP 改為 UDP
• QUIC：在 UDP 上實現可靠傳輸 + 新功能
• 內建加密：強制使用 TLS 1.3

關鍵優勢：

• ✅ 解決 HOL Blocking：獨立串流
• ✅ 更快連線：0-RTT 恢復
• ✅ 連線遷移：IP 改變不中斷
• ✅ 更低延遲：1-RTT 握手
• ✅ 易於升級：用戶空間實現

效能提升：

理想網路：    +15% 速度
高延遲網路：  +50% 速度
移動網路：    +200% 可靠性

部署狀況：

• Google、Facebook、Cloudflare 大規模使用
• 75%+ 瀏覽器支援
• 主流 CDN 支援

記憶口訣：

HTTP/3 = HTTP/2 + QUIC
QUIC = Quick UDP Internet Connections

核心改變：
TCP → UDP（更靈活）
分開握手 → 合併握手（更快）
全域阻塞 → 獨立串流（更高效）

🔗 延伸閱讀

• 上一篇：02-5. HTTP Headers 詳解
• 下一篇：03-1. HTTPS 加密原理
• RFC 9000 (QUIC)：https://datatracker.ietf.org/doc/html/rfc9000
• RFC 9114 (HTTP/3)：https://datatracker.ietf.org/doc/html/rfc9114
• HTTP/3 檢測：https://http3check.net
• Cloudflare HTTP/3：https://blog.cloudflare.com/http3-the-past-present-and-future/