1. 題目
一個行動客戶端正在透過 HTTP/3 下載大檔案。使用者從 Wi-Fi 切換到行動網路後，客戶端的來源 IP 和 UDP 來源連接埠都改變；產品希望下載繼續，不因網路變化而重新完成一次完整連線建立。
請解釋 QUIC 如何識別仍屬於同一連線的封包，描述遷移到新路徑時的驗證步驟，並區分 NAT 重新綁定、客戶端主動遷移和伺服器遷移。還要說明連線遷移對負載平衡、狀態管理、放大攻擊防護、可觀測性和隱私的影響。
2. 約束與釐清
- 討論的是 RFC 9000 傳輸層語義；HTTP/3 只是承載應用，不改變 QUIC 的路徑驗證規則。
- 客戶端和伺服器已完成握手，客戶端擁有可用的備用連線 ID；若伺服器只提供零長度連線 ID，遷移能力會受到部署約束。
- 「保持連線」不等於舊路徑上的每個封包都可達。路徑變化期間仍可能丟包、重排或觸發擁塞控制重新探測。
- 題目不要求實作完整 QUIC 協定棧，重點是狀態機、攻擊面和可驗證的診斷訊號。
3. 核心機制：連線 ID 脫離地址四元組
TCP 通常用本地地址、遠端地址、本地連接埠和遠端連接埠的四元組定位連線；行動網路切換會改變四元組。QUIC 在握手後使用 Destination Connection ID（DCID）和 Source Connection ID（SCID）把封包映射到連線狀態，因此新路徑可以繼續攜帶同一連線的識別。
連線 ID 由端點產生並透過 NEW_CONNECTION_ID frame 提供給對端。端點還維護序號、重置令牌和可用 ID 數量；舊 ID 可以透過 RETIRE_CONNECTION_ID 回收。連線 ID 不應把使用者 IP、帳號或可推斷的穩定身分直接編碼，否則會擴大可關聯性和隱私風險。
4. 遷移與路徑驗證流程
客戶端發現來源地址變化後，可以在新路徑使用備用 DCID 傳送資料，並攜帶 PATH_CHALLENGE。伺服器在新路徑回傳 PATH_RESPONSE，客戶端據此確認對端能接收並回傳該路徑的資料。驗證前，端點必須限制對新地址的傳送量，避免被偽造地址誘導放大流量。
on_packet(packet, source_address):
conn = lookup_by_destination_connection_id(packet.dcid)
if conn is unknown:
reject_or_handle_as_new_connection()
elif source_address == conn.validated_path:
process_with_current_congestion_state()
else:
mark_possible_new_path(source_address)
send_path_challenge_on_new_path()
cap_bytes_sent_until_validation()
on_path_response(token, source_address):
if token matches outstanding_challenge:
conn.validated_path = source_address
switch_active_path()
update_congestion_and_rtt_measurement()路徑驗證證明封包能往返，不證明該地址屬於某個使用者，也不自動證明舊路徑已失效。實作必須處理同時存在的舊路徑和新路徑、亂序回應、重複挑戰、逾時以及新路徑驗證失敗。
5. 三種情況與系統影響
NAT 重新綁定是中間設備改變外部連接埠或映射，但端點觀察到的地址變化可能是被動的。RFC 允許端點在滿足條件時繼續使用連線，而不把每次連接埠變化都當成客戶端主動遷移；實作仍應完成路徑驗證並重新測量 RTT 與擁塞狀態。
客戶端主動遷移通常發生在網路介面切換，客戶端選擇備用連線 ID 在新地址傳送。伺服器遷移則受協定規則和實作支援限制，不能把「伺服器換了出口 IP」簡單當成對稱操作。連線 ID 輪換還能減少不同網路路徑之間的關聯，但日誌和風控系統需要用受控的連線識別關聯同一工作階段。
負載平衡器必須根據 DCID 把同一連線路由到能恢復狀態的後端，或讓共享狀態層保存加密握手和傳輸狀態。只按五元組黏滯會在地址變化後失效。觀測上應記錄路徑驗證結果、遷移次數、舊路徑與新路徑 RTT、丟包、重傳和連線 ID 生命週期，而不記錄未受保護的使用者識別。
6. 追問與陷阱
- 為什麼不能直接接受任意新地址？ 攻擊者可偽造來源地址，誘使伺服器把大量回應傳給受害者；路徑驗證和傳送量限制可降低放大風險。
- 連線 ID 是永久身分嗎？ 不是。端點可以輪換、撤回並限制 ID 的存活；應用不應把它當作使用者身分或跨連線追蹤鍵。
- 遷移後是否保留全部擁塞狀態？ 不能盲目照搬。新路徑容量和 RTT 可能不同，應重新探測並避免突發傳送；實作可以保守地繼承部分狀態，但必須有驗證和回退策略。
- 代理或四層負載平衡會破壞遷移嗎？ 如果設備終止 QUIC、改寫 DCID 或無法把新路徑路由到原後端，遷移可能退化為新連線；部署必須明確連線 ID 編碼、狀態歸屬和健康轉移協定。
7. 驗證與排障清單
- 封包對齊： 關聯握手產生的 DCID/SCID、
NEW_CONNECTION_ID、PATH_CHALLENGE和PATH_RESPONSE，確認地址變化前後仍映射到同一連線。 - 注入網路變化： 在測試中切換介面、觸發 NAT 連接埠變化、延遲或丟棄路徑驗證回應，觀察是否限流、重試並最終回退。
- 檢查路由與狀態： 對比負載平衡器的 DCID 路由、後端連線表和連線 ID 退休記錄，確認沒有只依賴舊五元組。
- 檢查安全訊號： 統計未知 DCID、驗證失敗、異常遷移頻率和放大位元組比，避免把攻擊流量當成普通移動性。
8. 面試評分點
能解釋連線 ID 與四元組差異
候選人應說明地址變化為何會影響 TCP 四元組，以及 QUIC 如何用 DCID/SCID 找回連線狀態。
能講清路徑驗證和放大防護
應提到 PATH_CHALLENGE、PATH_RESPONSE、傳送量限制、舊新路徑並存和驗證失敗回退。
能區分遷移、重新綁定和部署邊界
應區分 NAT 重新綁定與主動遷移，並覆蓋負載平衡、代理終止、共享狀態和連線 ID 輪換。
能給出可驗證的排障方案
應提出封包分析、網路故障注入、DCID 路由檢查和安全指標，而不是只說「QUIC 執行在 UDP 上所以更快」。