當業界還在消化 HTTP/2 Rapid Reset 的教訓時，下一場協議級戰爭已經打響。HTTP/3 over QUIC（RFC 9000，2021 標準化）正迅速普及——Cloudflare、Google、Meta 的流量中 QUIC 佔比已過半。但 QUIC 把傳輸層從 TCP 換成了 UDP，這不僅帶來性能紅利，也重新打開了一整套 DDoS 攻擊面。本文從防禦視角，拆解 QUIC 為何讓 L7 防護更難。

一、為什麼 QUIC 改變了遊戲規則

QUIC 的核心設計選擇決定了它的安全屬性：

  • 基於 UDP：繞過了中間盒（防火牆、NAT、IDS）對 TCP 的假設，也繼承了 UDP 的無連接特性（見反射放大一文）。
  • 預設加密：握手（Initial）包即加密，中間設備無法像看 TCP 那樣窺探旗標——基於明文特徵的過濾失效。
  • 用戶態實現：QUIC 多在應用層（如 nginx/quiche、envoy）實作，每個包都要做昂貴的加密運算，而非交給核心態的 TCP 協議棧。

二、加密成本不對稱：QUIC 版的 Rapid Reset？

Rapid Reset 的本質是「攻擊者付出極小、伺服器付出極大」的計算不對稱。QUIC 的手握也存在類似槓桿：

每個 QUIC Initial 包都迫使伺服器執行密鑰衍生、解密與狀態分配。攻擊者發送大量偽造/空握手，就能讓伺服器的 CPU 在「還沒建立任何有意義連接」之前就被拖垮。

這正是 RFC 9000 要求伺服器在 Retry 包中攜帶 Token 的原因——用「先證明你真實」來擋住偽造源地址的握手洪流。但 Token 機制本身也引入了新的邊緣成本，防禦方必須在邊緣正確實作。

三、QUIC 放大：小請求、大回應

NCC Group 與 Cloudflare 的研究（2022–2023）指出：QUIC 伺服器的首次回應（Retry 或 Handshake）可能大於客戶端的 Initial 包，形成 ~3–5× 的放大係數。雖然遠小於 Memcached 的 5 萬倍，但結合源地址偽造，仍可對伺服器與反射節點造成壓力。RFC 9000 雖要求 Retry 包含 Token 以抑制放大，但實作不完整的伺服器仍是風險點。

四、0-RTT 重放：被低估的武器

QUIC 的 0-RTT 允許客戶端在握手完成前就發送資料（降低延遲）。但 0-RTT 資料可被重放——攻擊者截獲一個 0-RTT 包並反覆重放，就能在不建立連接的情況下對源站/應用發起放大 + 重放 DDoS。防禦方必須對 0-RTT 做冪等/一次性校驗，並限制 0-RTT 僅用於安全方法（GET）。

五、連接遷移與 CID 濫用

QUIC 的連接遷移（用戶切換網路時用 Connection ID 續接）與無狀態重置（Stateless Reset）是便利特性，也是攻擊面：

  • CID 預測/競態：若 CID 生成可預測，攻擊者可偽造重置包切斷海量連接。
  • 遷移濫用：反覆觸發遷移迫使伺服器重建狀態，消耗資源。
  • 版本協商洪水：發送大量未知版本號的包，迫使伺服器做版本協商處理。

六、防禦方的 QUIC 生存清單

  • 在協議邊緣做 QUIC 感知防護：不能只看 TCP 特徵；需在 UDP/QUIC 層做連接級限速、握手頻率限制、Retry Token 嚴格校驗。
  • 遏制加密成本不對稱：對未攜帶有效 Token 的 Initial 包做早期丟棄；在邊緣而非源站做握手運算。
  • 限制 0-RTT：僅允許冪等方法，啟用重放防護（nonce/一次性令牌）。
  • 監控協議指標：追蹤「未完成握手 / 已完成連接」比例、Retry 頻率、0-RTT 佔比——這些是 QUIC 攻擊的早早期信號。
  • 與 Rapid Reset 同理：能識別協議幀級異常並在秒級自動緩解的架構，才是對抗 QUIC 時代攻擊的真正壁壘。

結語

QUIC/HTTP3 不是更安全，而是把安全邊界從「網路核心」移到了「協議邊緣」。它消除了明文可見性，卻放大了加密計算成本——這對依賴封包級過濾的傳統防護是結構性挑戰。Rapid Reset 給了我們第一課：攻擊者會追著每一個新協議的「成本不對稱」下手。QUIC 時代，防禦方必須在協議邊緣具備幀級識別與自動化緩解能力，否則下一個「3.98 億 RPS」可能就跑在 UDP 上。