HTTP/3 與 QUIC：下一代網路協定完全解析
為什麼 HTTP/3 比 HTTP/2 快？

HTTP/2 有三個並行的 Stream（同一個 TCP 連線）：

  Stream 1 傳輸 CSS：[Packet 1][Packet 2][Packet 3]  → 資料完整
  Stream 2 傳輸 JS ：[Packet A][Packet B][Packet C]  → 資料完整
  Stream 3 傳輸圖片：[Packet X]   [丟包！]   [Packet Z]  → Packet Y 丟失！

TCP 的反應：
  TCP 發現 Packet Y 遺失（收到 Packet Z 但缺少 Y，亂序）
  TCP 要求重傳 Packet Y
  在 Packet Y 重傳並到達之前，TCP 緩衝區停止往上層（HTTP/2）傳送任何資料

  → Stream 1 的 CSS 已完整，但 HTTP/2 無法取用（TCP 卡住了）
  → Stream 2 的 JS 已完整，但 HTTP/2 無法取用（TCP 卡住了）
  → 整個頁面的渲染因為一張圖片的一個封包丟失而延遲！

  這就是 TCP 層的 HOL Blocking：
  所有 HTTP/2 的 Stream 共用同一條 TCP 連線，
  TCP 一旦因丟包暫停，所有 Stream 都跟著停。

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

HTTP/3（QUIC）的解決方案：每個 Stream 獨立追蹤丟包

  Stream 1 傳輸 CSS：[Packet 1][Packet 2][Packet 3]  → 立刻交給應用層
  Stream 2 傳輸 JS ：[Packet A][Packet B][Packet C]  → 立刻交給應用層
  Stream 3 傳輸圖片：[Packet X]   [丟包！]   [Packet Z]  → 只有 Stream 3 等待重傳

  → Stream 1 和 2 不受影響，CSS 和 JS 立刻渲染
  → 只有圖片（Stream 3）在等待，其他資源正常處理
  → 整體頁面體驗：只有圖片慢，不是整個頁面都卡住

TCP（Transmission Control Protocol）：
  ✓ 可靠傳輸：保證封包送達、按序交付
  ✓ 流量控制：防止傳送速度超過接收方的處理能力
  ✓ 擁塞控制：偵測網路擁塞並自動降速
  ✗ 連線建立：三次握手（1.5 RTT 的延遲開銷）
  ✗ 協定邏輯在 OS 核心層：要更新協定就要更新 OS（極慢）
  ✗ HOL Blocking：一旦丟包，所有資料都要等

UDP（User Datagram Protocol）：
  ✓ 速度快：沒有連線建立、沒有確認機制
  ✓ 協定邏輯在應用層：可以快速迭代更新
  ✗ 不保證送達：封包可能丟失
  ✗ 不保證順序：封包可能亂序到達
  ✗ 沒有流量控制和擁塞控制

QUIC = UDP + 在應用層重新實作上面 TCP 的優點 + TLS 1.3

  QUIC 的可靠傳輸：自己實作 ACK + 重傳，但以 Stream 為粒度（非連線粒度）
  QUIC 的流量控制：Stream 級別 + 連線級別，兩層控制
  QUIC 的擁塞控制：預設 Cubic（同 TCP），但可熱更新成 BBR 等演算法
  QUIC 的加密：TLS 1.3 內建，不能關閉（所有 HTTP/3 流量都是加密的）
  QUIC 的更新：協定邏輯在使用者空間，Chrome 更新就能升級協定邏輯（不需要等 OS 更新）

──────────────────────────────────────────────────────────
TCP + TLS 1.2（舊方式，共需 3 RTT）
──────────────────────────────────────────────────────────

  客戶端                          伺服器
    │                                │
    │ ──── SYN ──────────────────→  │  ← TCP 握手第 1 步
    │ ←─── SYN-ACK ──────────────  │  ← TCP 握手第 2 步
    │ ──── ACK ──────────────────→  │  ← TCP 握手第 3 步（1.5 RTT 完成 TCP）
    │                                │
    │ ──── ClientHello ──────────→  │  ← TLS 握手第 1 步
    │ ←─── ServerHello + Cert ───   │  ← TLS 握手第 2 步
    │ ──── Key Exchange ─────────→  │  ← TLS 握手第 3 步
    │ ←─── Finished ─────────────   │  （又 1.5 RTT 完成 TLS）
    │                                │
    │ ──── HTTP Request ─────────→  │  ← 終於可以開始傳資料
    │ ←─── HTTP Response ─────────  │
    │                                │
  總計：3 RTT 後才收到第一個 byte

──────────────────────────────────────────────────────────
TCP + TLS 1.3（改進版，共需 2 RTT）
──────────────────────────────────────────────────────────

  TLS 1.3 把握手合併到 2 步：
  客戶端 → 伺服器：ClientHello（含 Key Share）
  伺服器 → 客戶端：ServerHello + Certificate + Finished（含加密資料）
  但 TCP 握手的 1.5 RTT 依然無法消除

  總計：2.5 RTT（TCP 1.5 RTT + TLS 1.3 握手 1 RTT）

──────────────────────────────────────────────────────────
QUIC 初次連線（1-RTT）
──────────────────────────────────────────────────────────

  QUIC 把 TCP 握手和 TLS 握手合併成一個步驟！

  客戶端                          伺服器
    │                                │
    │ ── QUIC Initial + ClientHello → │  ← QUIC + TLS 握手合併，一次發送
    │ ← QUIC + ServerHello + Data ── │  ← 伺服器回應同時包含加密資料
    │                                │
    │ 之後的請求可以直接傳送           │
    │                                │
  總計：1 RTT 後開始收到有效資料

──────────────────────────────────────────────────────────
QUIC 0-RTT（再次連線，0 RTT）
──────────────────────────────────────────────────────────

  你曾經連線過這個伺服器（例如昨天訪問過這個網站）
  QUIC 把上一次的 Session Ticket 儲存在瀏覽器中

  客戶端                          伺服器
    │                                │
    │ ── 0-RTT Data（帶 Session Ticket）→ │  ← 直接傳資料，不需要握手！
    │ ←── Response ──────────────── │
    │                                │
  總計：0 RTT → 第一個請求的延遲接近於 0！

──────────────────────────────────────────────────────────
TCP 連線的識別：四元組（4-tuple）
──────────────────────────────────────────────────────────

  一條 TCP 連線由這四個元素唯一識別：
  (Source IP, Source Port, Destination IP, Destination Port)

  你在咖啡廳連 WiFi，IP = 192.168.1.100
  正在下載一個大檔案，連線識別：
  (192.168.1.100, 54321, 93.184.216.34, 443)

  你切換到手機行動網路，IP 變成 10.0.0.50
  TCP 連線識別變成：
  (10.0.0.50, 54321, 93.184.216.34, 443)  ← 完全是另一條連線！

  → TCP 根本不知道這是「同一個用戶換了網路」
  → 原本的 TCP 連線被丟棄（Timeout 或 RST）
  → 需要重新建立 TCP + TLS 握手（2~3 RTT）
  → 正在下載的資料中斷，需要重新開始或靠應用層斷點續傳

──────────────────────────────────────────────────────────
QUIC 連線的識別：Connection ID（64-bit 隨機值）
──────────────────────────────────────────────────────────

  一條 QUIC 連線由一個隨機產生的 64-bit Connection ID 識別
  這個 ID 由客戶端選擇，與 IP 和 Port 完全無關

  你在咖啡廳連 WiFi，QUIC Connection ID = 0xABCDEF1234567890
  你切換到手機行動網路，IP 改變了，但 Connection ID 不變！

  QUIC 的流程：
  1. 客戶端偵測到 IP 改變（Source IP 從 WiFi 地址變成行動網路地址）
  2. 客戶端繼續使用相同的 Connection ID 發送資料
  3. 伺服器收到來自新 IP 的封包，但 Connection ID 相同
  4. 伺服器認可這是連線遷移，更新對應的 IP 記錄
  5. 連線繼續，幾乎沒有中斷！

  → 用戶體驗：短暫的傳輸停頓（幾十毫秒），然後自動恢復
  → 不需要重新握手，不需要重新傳資料

# 方法一：curl（需要 curl 7.66+ 且編譯時包含 QUIC 支援）
curl -I --http3 https://www.google.com
# 成功時 HTTP 版本欄位會顯示 HTTP/3

# 查看 curl 是否有 QUIC 支援
curl --version | grep -i quic
# 應看到類似：Features: ... HTTP3 ...

# 方法二：Chrome DevTools（最常用的方式）
# 1. 打開 Chrome，前往目標網站
# 2. 按 F12 → Network tab
# 3. 找到 Protocol 欄位（若沒有，右鍵欄位標題 → 勾選 Protocol）
# 4. 看到 "h3" 就是 HTTP/3，"h2" 是 HTTP/2

# 方法三：使用 curl 查看 Alt-Svc 回應 Header
curl -sI https://www.cloudflare.com | grep -i alt-svc
# 回應範例：
# alt-svc: h3=":443"; ma=86400
# 這表示伺服器支援 HTTP/3，且下次連線可以直接用（ma=86400 是快取時間）

# 方法四：線上工具
# https://http3check.net → 輸入你的網域，直接測試
# https://www.http3check.net

# 方法五：Chrome 的 net-internals
# chrome://net-internals/#quic → 查看當前所有 QUIC 連線狀態

# 前置需求：
# Nginx 1.25.0+ 已內建 QUIC 支援（不需要額外 patch）
# 或使用 nginx-quic 分支（1.25.0 之前）

# /etc/nginx/nginx.conf
events {
  worker_connections 1024;
}

http {
  server {
    # 同時監聽 TCP（HTTP/1.1 和 HTTP/2）和 QUIC（HTTP/3）
    listen 443 ssl;             # TCP + TLS（HTTP/1.1 和 HTTP/2 的 fallback）
    listen 443 quic reuseport;  # UDP + QUIC（HTTP/3）
    # reuseport 讓多個 worker process 共享同一個 UDP Port，提高吞吐量

    server_name example.com;

    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # HTTP/3 強制要求 TLS 1.3（QUIC 內建 TLS 1.3，無法降級）
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # 關鍵 Header：告訴瀏覽器「這台伺服器支援 HTTP/3」
    # 瀏覽器下一次訪問會優先嘗試 HTTP/3
    # ma=86400 表示這個資訊快取 86400 秒（1天）
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # 啟用 HTTP/2（同一個伺服器提供 HTTP/2 fallback）
    http2 on;

    location / {
      proxy_pass http://backend;

      # 傳遞真實 IP（QUIC 連線遷移時 IP 可能改變，記錄 Connection ID 更準確）
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Real-IP $remote_addr;
    }
  }

  # HTTP → HTTPS 強制跳轉
  server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
  }
}

對於已使用 Cloudflare 作為 CDN 的網站，啟用 HTTP/3 只需要：

  1. 登入 Cloudflare Dashboard（dash.cloudflare.com）
  2. 選擇你的 Domain
  3. 前往 Speed → Optimization → Protocol Optimization
  4. 找到「HTTP/3 (with QUIC)」→ 開啟

就這樣！所有流量自動升級，不需要在伺服器端做任何改動。

Cloudflare 會在它的邊緣節點（Edge）處理 HTTP/3，
然後用 HTTP/1.1 或 HTTP/2 和你的 Origin Server 通訊。
（稱為「HTTP/3 Termination at Edge」）

這是最推薦的方式，因為：
  ✓ 不需要維護自己的 QUIC 實作
  ✓ Cloudflare 的 QUIC 實作持續更新和優化
  ✓ 自動處理瀏覽器 fallback（不支援 HTTP/3 的客戶端自動降級）
  ✓ 沒有額外費用（免費方案也包含）

其他 CDN 的支援：
  AWS CloudFront：支援 HTTP/3（2022 年開始）
  Fastly        ：支援 HTTP/3
  Vercel        ：自動支援 HTTP/3（無需配置）
  Netlify       ：自動支援 HTTP/3（無需配置）

// Next.js 部署到 Vercel 時，HTTP/3 自動啟用，不需要任何配置

// 你可以用以下方式在 API Route 中記錄協定資訊
// app/api/debug/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function GET(request: NextRequest) {
  return NextResponse.json({
    // Vercel 會在請求 Header 中注入 HTTP 版本資訊
    protocol: request.headers.get('x-forwarded-proto'),
    // 真實連線資訊
    via: request.headers.get('via'),
    // Cloudflare 用戶可以看這個
    cfRay: request.headers.get('cf-ray'),
    // 連線使用的 TLS 版本
    cfTlsVersion: request.headers.get('cf-tls-version'),
  });
}

// 在前端取得協定資訊（瀏覽器端）
// 注意：瀏覽器沒有直接 API 取得 HTTP 版本
// 需要用 Chrome DevTools 的 Network tab 觀察 Protocol 欄位
// 或使用 Performance API 觀察 nextHopProtocol

const entries = performance.getEntriesByType('navigation') as PerformanceNavigationTiming[];
if (entries.length > 0) {
  console.log('Protocol:', entries[0].nextHopProtocol);
  // 'h3' = HTTP/3, 'h2' = HTTP/2, 'http/1.1' = HTTP/1.1
}

──────────────────────────────────────────────────────────
問題 1：UDP 被企業防火牆封鎖
──────────────────────────────────────────────────────────

  很多企業網路、VPN、政府機構的防火牆預設封鎖 UDP 443 Port
  QUIC 跑在 UDP 上，所以在這些環境中 HTTP/3 完全無法使用

  不用擔心：瀏覽器會自動 Fallback
  瀏覽器嘗試 HTTP/3 失敗後，會自動降級到 HTTP/2（TCP）
  對使用者透明，只是少了 HTTP/3 的效能優勢

  影響範圍：部分企業用戶（估計 5~10%）

──────────────────────────────────────────────────────────
問題 2：Server 端支援需要特殊版本或配置
──────────────────────────────────────────────────────────

  Nginx：需要 1.25.0+（有 QUIC 內建支援）或 nginx-quic 分支
  Apache：透過 mod_quic，支援程度不如 Nginx 成熟
  老舊的 Load Balancer / WAF 可能不支援 QUIC

  自建伺服器的挑戰：
  ✗ 並非所有主機商都提供支援 QUIC 的 Nginx 版本
  ✗ QUIC 的 UDP 需要特殊的 kernel 調優（socket buffer size）

──────────────────────────────────────────────────────────
問題 3：低延遲環境效益不明顯
──────────────────────────────────────────────────────────

  HTTP/3 的優勢主要來自：
  1. 減少握手 RTT（0-RTT）→ 初始延遲越高，效益越大
  2. 解決 HOL Blocking → 丟包率越高，效益越大
  3. 連線遷移 → 行動網路場景效益大

  反過來說，在以下場景效益不明顯：
  ✗ 同機房的微服務通訊（延遲 < 1ms，丟包率接近 0）
  ✗ 已有優化的有線網路辦公環境
  ✗ 短小的 API 請求（資料量小，效能瓶頸不在傳輸上）

──────────────────────────────────────────────────────────
問題 4：CPU 消耗略高
──────────────────────────────────────────────────────────

  QUIC 的加密、封包分割、ACK 處理都在應用層（User Space）
  TCP 的這些操作由 OS 核心處理，可以用 GSO / GRO 等硬體加速

  結果：QUIC 的 CPU 消耗比 TCP 高約 10~20%
  對於 CPU 已是瓶頸的伺服器，啟用 HTTP/3 可能反而帶來負面影響