具代表性的面試主題

後端面試:如何用 HTTP/2 Extended CONNECT 承載 WebSocket?

後端困難
Offer.cc 編輯團隊發佈 更新

題幹

閘道已統一使用 HTTP/2,但即時服務仍依賴 HTTP/1.1 Upgrade。你會如何遷移到 Extended CONNECT,並處理代理能力、串流關閉、回退與觀測?

題幹與適用場景

閘道和客戶端支援 HTTP/2,即時服務希望在同一連線複用 WebSocket 串流。請設計 RFC 8441 遷移方案,說明握手、能力協商、代理相容、串流與連線關閉、回退及驗收。核心考察 HTTP/2 擴充連線語義,歸為 backend

面試官考察點

  1. 說清 Extended CONNECT 與 HTTP/1.1 Upgrade 差異。
  2. 正確使用 :protocolSETTINGS_ENABLE_CONNECT_PROTOCOL
  3. 區分 HTTP/2 stream 關閉和底層連線關閉。
  4. 設計不支援擴充的代理與客戶端回退。
  5. 用握手、流錯誤和連線複用指標驗收。

回答前需要釐清的問題

  • 客戶端、邊緣代理、閘道與 origin 是否支援 RFC 8441?
  • 是否允許同一 HTTP/2 連線混合普通請求和 WebSocket 串流?
  • 負載平衡器會重建 HTTP/2 還是端到端透傳?
  • 舊客戶端能否繼續 HTTP/1.1 Upgrade?
  • 目標是瀏覽器 WebSocket、原生 SDK 還是內部 RPC?

30 秒回答框架

「我先確認每一跳是否支援 SETTINGS_ENABLE_CONNECT_PROTOCOL。支援時發送帶 :protocol = websocket 的 Extended CONNECT,成功後在該 stream 承載 WebSocket;不支援就回退 HTTP/1.1 Upgrade。stream 級取消不能關閉整條連線。灰度記錄握手、回退、RST_STREAM、GOAWAY、連線複用與延遲。」

分步驟深入解答

第一步:協商能力

端點透過 HTTP/2 SETTINGS 表明 Extended CONNECT 支援。只有收到能力訊號後才發送 :protocol;中間代理不透傳時應走回退。

第二步:處理握手與資料流

成功後建立 HTTP/2 stream 並承載 WebSocket frame 語義,不使用 HTTP/1.1 Upgrade、Connection、Sec-WebSocket-Key 或 101 路徑。服務端仍驗證 origin、權限與子協議。

第三步:區分生命週期

RST_STREAM 只影響一個 WebSocket。GOAWAY 影響新 stream,既有 stream 需完成、遷移或重連;重連要避免重複提交。

第四步:設計代理回退

建立客戶端、CDN、LB、閘道能力矩陣。不支援時用 HTTP/1.1 Upgrade 或明確失敗,並保留認證、origin、子協議與心跳語義。

第五步:控制流量與背壓

同時管理 HTTP/2 window 與應用佇列,設定每連線和每 stream 上限,避免慢流阻塞同連線普通請求。

第六步:灰度與安全

先在內部客戶端與單一區域啟用,量測握手、首訊息、重連、RST_STREAM、GOAWAY 和代理錯誤。TLS、origin、認證與訊息大小限制維持不變。

第七步:回滾與驗收

保留按客戶端或區域關閉 HTTP/2 WebSocket 的開關。測試 SETTINGS 缺失、拒絕 protocol、stream 取消、GOAWAY、網路切換與重連,比較訊息順序、p95、連線數和回退比例。

高品質示範回答

「我會先建立逐跳能力矩陣,確認支援 SETTINGS_ENABLE_CONNECT_PROTOCOL。支援時發送 Extended CONNECT 與 :protocol = websocket,成功後在 HTTP/2 stream 承載 WebSocket;不支援回退 HTTP/1.1 Upgrade。RST_STREAM 只影響單一 WebSocket,GOAWAY 影響新 stream。灰度觀察握手、回退、重連、首訊息 p95、連線複用和代理錯誤,並保留原有認證與 origin 校驗。」

常見錯誤

  • 把 Extended CONNECT 當普通標頭 → 代理可能錯誤轉發 → 驗證 SETTINGS 與偽標頭。
  • 繼續發 HTTP/1.1 Upgrade 標頭 → HTTP/2 語義不接受 → 按 RFC 8441 握手。
  • RST_STREAM 關閉整條連線 → 影響其他請求 → 區分 stream 與 connection。
  • 忽略 GOAWAY → 重連混亂 → 定義完成與恢復。
  • 只測直連 → CDN/LB 差異造成失敗 → 逐跳測試。

追問及應對

追問一:為何不用 HTTP/3 WebSocket?

HTTP/3 有 RFC 9220 方案;既有 HTTP/2 鏈路可先採 RFC 8441,取決於支援和遷移成本。

追問二:SETTINGS 沒開能試發嗎?

不應試發,應等待能力訊號並回退或報告不支援。

追問三:GOAWAY 後如何避免重複?

使用序號或冪等鍵記錄確認偏移,重連從明確位置恢復。

追問四:如何定位代理不相容?

逐跳記錄 SETTINGS、CONNECT 回應和錯誤碼,按代理與客戶端版本拆分。

公開來源

同類題目