單元 15 HTTP、QUIC、承載與快取

學習目標與問題

先讀 TCP 及 TLS。你應能區分 HTTP 版本、多工與隊首阻塞，說明 QUIC stream／DATAGRAM，以及 WebSocket／gRPC 在代理中的承載角色。同時發出十個請求不代表底層有十條獨立 TCP 連線。

15.1 HTTP 語義與傳送格式

HTTP 定義 method、status、headers 和資源語義。HTTP/1.1 在 TCP 串流內使用自己的訊息格式；persistent connection 可重用連線，流水化仍有回應順序限制。HTTP/2 把訊息分成 frames 並在 streams 多工，減少應用層的一些排隊，但它仍在 TCP 有序串流上，某個遺失段可阻止後續 bytes 交付到 HTTP/2 層，影響多個 stream。

HTTP/3 把 HTTP 對映到 QUIC。QUIC 使用 UDP 承載，卻為 stream 提供可靠、有序交付。QUIC stream 內遺失資料仍需恢復才能跨缺口按序交付，但一個 stream 的缺口通常不會要求其他 stream 等待同一傳輸序號。不同 streams 仍共享連線級流控、壅塞、路徑及資源；應用依賴和 QPACK 也可能造成等待。因此不能寫成「完全沒有任何 HOL 或延遲互相影響」。

15.2 QUIC 基本機制

QUIC 整合 TLS 握手、安全封包保護、連線識別、streams、流量與壅塞控制。Connection ID 可支援位址變化下的連線識別，遷移仍需協定、實作及路徑條件，不保證行動網路切換毫無中斷。UDP 被阻擋時，應用可能退回 TCP 的 HTTP 版本，需記錄實際協商版本。

QUIC stream 可靠且有序；RFC 9221 DATAGRAM 擴充提供不可靠的訊息，遺失時不由 QUIC 重傳該 DATAGRAM，仍受壅塞和封包大小限制。「QUIC 用 UDP」不能推出所有 QUIC 資料都不可靠，也不能推出所有應用都支援 DATAGRAM。

15.3 WebSocket 與 gRPC

WebSocket 在 HTTP 握手後提供訊息／雙向通訊，在常見 RFC 6455 實作中承載於 TCP。代理可將自己的協定 bytes 包進 WebSocket，再經 TLS／TCP 傳輸。gRPC 常以 HTTP/2 傳輸 RPC 與 stream；代理工具借其 stream 作為承載仍需雙方相容的服務名稱與實作。多套多工並不必然更快，可能增加佇列、複製與 HOL。

協定層疊應寫成「應用 TLS／代理 payload／WebSocket／外層 TLS／TCP／IP」等具體圖，不可把 WebSocket、TLS、VLESS 排成同一層的可替代協定。

15.4 快取與 CDN

快取複用可省傳輸與往返；Cache-Control、Age、驗證器 ETag／If-None-Match 影響是否直接用快取、重新驗證或下載。CDN 就近提供資源，但選擇受 DNS、Anycast、負載、內容位置和政策影響，地理最近不保證最少 RTT。

例：快取回應 max-age=120，Age=90，假設其他條件不限制，freshness 約剩 30 秒；過期後若 ETag 重新驗證成功，可回 304 複用原內容。no-cache 一般要求使用前驗證，不等同禁止儲存；no-store 才是禁止儲存的指令語義。登入和敏感內容的快取需遵守適用指令。

實驗、習題與檢核

用 L14 畫 H2/TCP 和 H3/QUIC 的三 stream 遺失情境，不製造未經實作驗證的真實封包。L11 設計同路徑首次／恢復小請求與大檔案對照。

HTTP/2 多工為何仍受 TCP 交付缺口影響？
stream 與 DATAGRAM 的可靠性各是什麼？
哪些共享資源可讓不同 QUIC streams 仍互相影響？
no-cache 與 no-store 為何不能當同義詞？

檢核：能同時說出應用語義、stream 語義、封包傳輸和保護方式。QUIC/TLS 與 QPACK 另查 RFC 9001、RFC 9204。WebSocket 經 H2/H3 的擴充另查 RFC 8441/9220。來源：RFC 9110、RFC 9111（快取）、RFC 9112、RFC 9113、RFC 9114、RFC 9000、RFC 9221、RFC 6455、gRPC 核心概念。