通用面試：QUIC 連線遷移如何跨網路維持連線？

題幹與適用場景

行動用戶端正在下載或維持長連線，網路從 Wi-Fi 切到行動網路，來源 IP 和 UDP 埠發生變化。請解釋 QUIC 如何辨識仍是同一條連線、如何驗證新路徑，以及什麼時候必須重新連線。範圍限定在 QUIC v1 傳輸層；應用層重試、HTTP 會話恢復和 0-RTT 複用分開說明，不能把它們混成「遷移一定成功」。

面試官考察點

強回答會區分四元組和 QUIC Connection ID：位址變化不一定代表連線狀態遺失，但新路徑必須驗證。面試官會追問握手尚未確認、對端設定 disableactivemigration、NAT 重新繫結、連線 ID 耗盡、伺服器 preferred address，以及 0-RTT 的重播風險。只說「UDP 不連線所以能切換」代表沒有理解 QUIC 的狀態和安全邊界。

回答前需要釐清的問題

1. 是用戶端主動切網還是 NAT 被動換埠？ 主動遷移和 NAT 重新繫結的觸發與驗證路徑不同。
2. 握手是否已確認？ QUIC v1 在握手確認前不能主動遷移，必須繼續使用原位址。
3. 對端是否停用主動遷移？ 收到 disableactivemigration 後，不能從新本地位址主動發包，除非使用伺服器宣告的 preferred address。
4. 連線 ID 是否為零長度？ 零長度 ID 無法用新的 ID 隔離路徑，隱私和多路徑路由能力較弱。
5. 應用能否接受短暫無資料？ 若舊路徑失效且新路徑驗證失敗，只能等待、關閉連線或由應用重建會話。

30 秒回答框架

「QUIC 不把連線綁在 TCP 四元組上，而是使用對端提供的 Connection ID。握手確認後，用戶端從新位址傳送探測封包，伺服器透過 PATHCHALLENGE/PATHRESPONSE 驗證新路徑，驗證成功後才把資料遷移過去。NAT 重新繫結也要做路徑驗證。Connection ID 不能跨多條路徑複用，而且對端可以停用主動遷移。遷移失敗不代表協定立即遺失狀態：有可用舊路徑就繼續，沒有就等待或重連。0-RTT 是恢復握手能力，不等於遷移安全，應用必須防重播。」

分步驟深入解答

QUIC 的連線狀態由 Connection ID、加密金鑰、串流狀態和擁塞控制等組成。Connection ID 讓接收方在 IP 或埠變化後仍能把資料封包映射到同一條連線；它不是驗證憑據，也不能單獨證明新位址屬於原用戶端。

握手確認後，端點可以從新本地位址探測路徑。新路徑先送出 PATHCHALLENGE，收到 PATHRESPONSE 後才視為可用；驗證失敗只代表該路徑不可用，不必立刻結束仍有其他有效路徑的連線。對端位址突然變化（例如 NAT 重新繫結）也要執行路徑驗證，避免任意偽造來源位址把流量導向攻擊者。

每條傳送路徑應使用沒有在另一條路徑使用過的 Destination Connection ID。這既幫助多實例服務路由，也減少觀察者把兩條網路路徑關聯起來的機會。端點應預先提供多個可用 ID；ID 耗盡時無法探測新路徑或回應遷移。若用戶端選擇零長度 ID，伺服器必須依靠位址等其他資訊分流，遷移和隱私邊界更差。

遷移會影響擁塞控制。位址改變可能讓對端重設擁塞狀態，因此協定建議不要頻繁換位址。伺服器可以在握手中提供 preferred address；用戶端仍需先驗證它，失敗時繼續使用原位址。若對端設定 disableactivemigration，用戶端不能隨意從新位址發包，避免繞過協定語意。

0-RTT 解決的是恢復連線時提前傳送應用資料，RFC 明確它沒有重播保護。切網後的遷移應使用已確認的 1-RTT 狀態；應用若把重試請求設計成非冪等，不能因為「QUIC 維持連線」就跳過冪等鍵或伺服器去重。

高品質示範回答

「我會先區分連線識別和網路路徑。QUIC 使用 Connection ID 映射連線，所以 Wi-Fi 到行動網路導致 IP 或埠變化時，狀態仍可能保留。握手確認後，端點從新位址送 PATHCHALLENGE，只有收到 PATHRESPONSE 才把該路徑當作可用；NAT 重新繫結同樣需要驗證。不能複用同一個 ID 跨不同傳送路徑，也要考慮 ID 池耗盡和 disableactivemigration。遷移失敗時，舊路徑仍活著就繼續，否則等待路徑恢復或重建應用會話。最後我會把 0-RTT 當成有重播風險的恢復機制，而不是遷移的安全證明。」

常見錯誤

• 錯誤表現 → 說 UDP 天生支援遷移；失敗原因 → UDP 沒有連線語意，QUIC 仍需管理連線 ID、金鑰和串流狀態；修正方法 → 解釋 Connection ID 與路徑驗證。
• 錯誤表現 → 位址一變就立即接受資料；失敗原因 → 攻擊者可偽造來源位址造成放大或劫持；修正方法 → 用 PATHCHALLENGE/PATHRESPONSE 驗證。
• 錯誤表現 → 把 0-RTT 當成遷移；失敗原因 → 0-RTT 可提前發資料但沒有重播保護；修正方法 → 分開討論恢復握手與遷移。
• 錯誤表現 → 同一 Connection ID 在多條路徑同時傳送；失敗原因 → 違反路徑關聯規則並損害隱私；修正方法 → 每條傳送路徑使用未在其他路徑使用的 ID。
• 錯誤表現 → 忽略 disableactivemigration；失敗原因 → 對端明確禁止主動更換本地位址；修正方法 → 僅在 preferred address 等協定條件滿足時遷移。

追問及應對

如果新路徑驗證一直失敗，連線會怎樣？

失敗只代表新路徑不可用；仍有舊路徑時繼續使用舊路徑。若沒有任何有效路徑，可以等待新路徑、回報不可用並關閉，或由應用層重新建立會話。不要把一次 PATH_RESPONSE 逾時直接等同於資料遺失。

為什麼要準備多個 Connection ID？

遷移或路徑探測時需要未使用過的 ID；如果 ID 池耗盡，端點既不能安全探測新路徑，也無法正確回應對端遷移。伺服器應依 activeconnectionid_limit 補充 ID。

遷移怎樣降低可關聯性？

在新路徑換用新的 Connection ID，並透過標頭保護避免直接用封包號關聯；但時序、封包大小等流量特徵仍可能被觀察者關聯，不能聲稱完全匿名。

遷移是否保留擁塞視窗？

實作可以根據路徑變化重設或調整擁塞控制狀態，因為新路徑容量未知。換位址應節制，探測成功後重新估計可用頻寬；應用層只應依賴傳輸層最終交付，不假設瞬時吞吐不變。