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 由端點產生並透過 NEWCONNECTIONID frame 提供給對端。端點還維護序號、重置令牌和可用 ID 數量；舊 ID 可以透過 RETIRECONNECTIONID 回收。連線 ID 不應把使用者 IP、帳號或可推斷的穩定身分直接編碼，否則會擴大可關聯性和隱私風險。
4. 遷移與路徑驗證流程
客戶端發現來源地址變化後，可以在新路徑使用備用 DCID 傳送資料，並攜帶 PATHCHALLENGE。伺服器在新路徑回傳 PATHRESPONSE，客戶端據此確認對端能接收並回傳該路徑的資料。驗證前，端點必須限制對新地址的傳送量，避免被偽造地址誘導放大流量。
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、
NEWCONNECTIONID、PATHCHALLENGE和PATHRESPONSE，確認地址變化前後仍映射到同一連線。 - 注入網路變化： 在測試中切換介面、觸發 NAT 連接埠變化、延遲或丟棄路徑驗證回應，觀察是否限流、重試並最終回退。
- 檢查路由與狀態： 對比負載平衡器的 DCID 路由、後端連線表和連線 ID 退休記錄，確認沒有只依賴舊五元組。
- 檢查安全訊號： 統計未知 DCID、驗證失敗、異常遷移頻率和放大位元組比，避免把攻擊流量當成普通移動性。
8. 面試評分點
能解釋連線 ID 與四元組差異
候選人應說明地址變化為何會影響 TCP 四元組，以及 QUIC 如何用 DCID/SCID 找回連線狀態。
能講清路徑驗證和放大防護
應提到 PATHCHALLENGE、PATHRESPONSE、傳送量限制、舊新路徑並存和驗證失敗回退。
能區分遷移、重新綁定和部署邊界
應區分 NAT 重新綁定與主動遷移，並覆蓋負載平衡、代理終止、共享狀態和連線 ID 輪換。
能給出可驗證的排障方案
應提出封包分析、網路故障注入、DCID 路由檢查和安全指標，而不是只說「QUIC 執行在 UDP 上所以更快」。