題幹與適用場景
行動客戶端在 Wi-Fi 與行動網路間切換時，如何保持 QUIC 連線並避免 0-RTT 重放造成重複寫入？你會如何設計路徑驗證、負載平衡、監控和 TCP 回退？
這道題適合後端、網路、邊緣和平台職位。QUIC 使用 Connection ID 將連線與 UDP 四元組分離，因此地址變化可以觸發遷移；RFC 9001 明確 0-RTT 缺少完整的重放保護。重點是把協議約束轉成服務端狀態、冪等介面和部署策略。
面試官考察點
- 是否區分連線 ID、路徑、地址驗證和連線遷移時機。
- 是否知道握手確認前不能主動遷移，並能解釋 PATHCHALLENGE/PATHRESPONSE。
- 是否把 0-RTT 僅用於可安全重放的請求，而不是直接允許任意寫操作。
- 是否考慮負載平衡器、連線 ID 路由、金鑰輪換和狀態共享。
- 是否為 UDP 被阻斷、NAT 重綁定、丟包和遷移失敗設計回退。
- 是否用指標證明遷移成功，而非只看握手成功率。
30 秒回答框架
「我會讓 Connection ID 標識連線，收到新來源地址後先做路徑驗證，再切換傳送路徑；握手確認前不主動遷移。0-RTT 請求按重放風險分類，只允許冪等讀取或帶去重令牌的寫入，服務端保存 anti-replay 視窗與業務冪等鍵。邊緣層按 Connection ID 路由並支援金鑰輪換，監控遷移、驗證、重綁定和回退指標；UDP 不可用時協商 HTTP/2 或 HTTP/1.1。」
分步驟深入解答
第一步：分離連線與路徑
TCP 通常由地址和埠號四元組識別連線；QUIC 使用 Connection ID 識別連線，來源地址變化不必然建立新連線。服務端收到來自新路徑的資料時，不能立即把它當作可信路徑；應用資料傳送前要完成路徑驗證，並處理 NAT 重綁定與臨時網路切換。
第二步：設計路徑驗證狀態機
舊路徑繼續承載資料時，端點向候選路徑傳送 PATHCHALLENGE，並等待 PATHRESPONSE。為每條候選路徑記錄令牌、傳送時間、驗證狀態和失敗次數；驗證逾時不應立刻銷毀連線。遷移前後都要遵守擁塞控制和放大限制，避免向未驗證地址放大流量。
第三步：處理 Connection ID 與負載平衡
邊緣負載平衡器需要從 Connection ID 得到穩定的後端路由，或使用可驗證的路由令牌把連線轉發到持有狀態的節點。服務端應按協議發放、撤銷和輪換 Connection ID，避免暴露拓撲或讓舊 ID 無限有效。連線狀態、令牌和金鑰的共享邊界要明確，不能依賴單機記憶體卻允許任意遷移。
第四步：劃定 0-RTT 的業務邊界
0-RTT 資料可能被攻擊者重放，伺服器不能把它當作只執行一次的證明。預設只接受冪等 GET 或可安全重試的請求；若必須支援寫操作，使用客戶端生成的冪等鍵、請求時間窗、帳戶與資源約束，並在服務端原子去重。支付、扣庫存、發放權益等副作用應等待 1-RTT 確認。
第五步：觀察遷移和失敗路徑
記錄 Connection ID、舊新路徑摘要、驗證耗時、遷移成功率、NAT 重綁定、丟包、擁塞視窗、0-RTT 接受與拒絕、重複請求命中和回退原因。日誌不記錄完整地址或敏感令牌；使用雜湊或分桶維度。告警應區分客戶端網路變化、服務端驗證失敗、負載平衡路由錯誤和 UDP 被阻斷。
第六步：建立回退與灰度策略
HTTP/3 客戶端應能在 QUIC 建連失敗、UDP 被阻斷或路徑驗證持續失敗時嘗試 TCP 版本。灰度先按地區、客戶端版本和邊緣節點啟用，比較遷移成功率、p99 延遲、CPU、丟包和業務重複率。回退不應讓同一請求在 HTTP/3 和 HTTP/2 兩條路徑各執行一次，應用層仍需冪等。
取捨、邊界與資訊增益
QUIC 連線遷移改善行動網路切換體驗，但增加了路徑狀態、路由、反放大和觀測複雜度。0-RTT 降低首包等待，卻犧牲重放安全邊界。高品質設計把協議層的「可能重複」傳遞到業務層，用冪等和稽核吸收風險，並保留可靠的 TCP 回退。
高品質示範回答
「我會用 Connection ID 而非 UDP 四元組識別連線。收到新來源地址後先進入候選路徑狀態，傳送 PATHCHALLENGE 並驗證 PATHRESPONSE；驗證成功才切換傳送路徑，同時遵守擁塞控制和放大限制。負載平衡器要能按 Connection ID 路由，或者把連線狀態放到可共享的邊界，Connection ID 還要支援輪換和撤銷。
0-RTT 沒有完整重放保護，所以只允許冪等讀取或帶時間窗和冪等鍵的安全請求。支付、庫存和權益寫入等待 1-RTT；服務端原子記錄冪等鍵並稽核重複命中。指標涵蓋驗證耗時、遷移成功率、NAT 重綁定、0-RTT 接受率、重複請求和回退原因。
最後按客戶端、地區和節點灰度，QUIC 失敗時回退 HTTP/2 或 HTTP/1.1，並保證應用層冪等，避免兩條協議路徑重複執行同一副作用。」
常見錯誤
- 看到新地址就立即切換 → 新路徑尚未驗證 → 先完成 PATHCHALLENGE/PATHRESPONSE。
- 把 0-RTT 當作一次性請求 → 資料可能被重放 → 限制方法並使用冪等鍵和時間窗。
- 只在單機記憶體保存連線狀態 → 遷移到另一節點會失敗 → 設計 Connection ID 路由或共享狀態。
- 忽略放大限制 → 未驗證地址可能被放大攻擊 → 遵守驗證和傳送額度。
- 只監控握手成功 → 遷移、重綁定和回退問題被隱藏 → 記錄完整生命週期指標。
- 回退時重複執行寫操作 → HTTP/3 與 HTTP/2 可能各到達一次 → 業務層使用同一冪等鍵。
追問及應對
為什麼不能在握手確認前主動遷移？
RFC 9000 規定端點在握手確認前不能主動發起遷移；此時連線金鑰和路徑信任仍在建立。先完成握手，再按路徑驗證狀態切換。
NAT 重綁定和主動遷移有什麼區別？
NAT 重綁定是外部網路設備改變映射，端點可能繼續使用同一 Connection ID；主動遷移是端點有意改變地址或介面。兩者都需要驗證新路徑，但觸發原因和可觀測標籤不同。
如何判斷一個 0-RTT 寫請求安全？
確認重複執行不會改變最終結果，或由服務端以冪等鍵、資源版本和時間窗原子去重。不可逆副作用預設等待 1-RTT，不把 TLS 會話票據當作業務授權。
UDP 被企業網路阻斷時怎麼辦？
客戶端回退到 HTTP/2 或 HTTP/1.1，並保留相同的認證、冪等和逾時語意。監控回退比例與地區分布，避免把 UDP 阻斷誤判為服務端故障。