通用技術面試：QUIC 如何在網路切換時保持連線？
題干與適用場景
行動客戶端正在下載大檔案，網路從 Wi-Fi 切換到行動網路，來源 IP 和 UDP 埠號發生變化。請解釋 QUIC connection migration 如何識別同一連線、何時允許遷移、如何驗證新路徑，以及驗證失敗時如何保護連線和伺服器資源。
面試官考察什麼
- 能否區分連線識別與網路地址，不把四元組變化等同於新連線。
- 能否說明握手確認、路徑驗證、
PATHCHALLENGE和PATHRESPONSE的先後關係。 - 能否處理 NAT rebinding、Connection ID 耗盡、伺服器禁用遷移和異常流量。
- 能否討論遷移對隱私、壅塞控制、計費和觀測的影響。
回答前要釐清的問題
- 是客戶端主動切換網路，還是 NAT 只改變了外部埠號？
- 連線是否已完成握手，伺服器是否設定
disableactivemigration？ - 業務能否接受短暫重傳和路徑探測開銷？
- 是否需要減少不同網路地址之間的可關聯性？
- 新路徑驗證失敗時，是繼續舊路徑還是重新建立連線？
30 秒回答框架
QUIC 使用 Connection ID 關聯連線狀態，而不是依賴來源 IP 和埠號不變。握手確認後，客戶端從新地址傳送探測封包，伺服器用 PATHCHALLENGE 和 PATHRESPONSE 驗證可達性；驗證成功才傳送普通資料。NAT rebinding 可在現有連線上處理，但主動遷移受 transport parameter 限制。新路徑失敗時保留舊路徑或重新建立連線，並限制未驗證地址的狀態和放大風險。
分步驟深入解答
第一步：區分連線狀態與地址
TLS、串流和壅塞控制狀態屬於 QUIC 連線，IP 地址和 UDP 埠號只是路徑屬性。Connection ID 讓伺服器在地址變化後仍能找到連線狀態；沒有合適的非零長度 ID 時，遷移和路徑探測能力會受限。負載平衡器也必須按 Connection ID 路由，而不能只按五元組雜湊。
第二步：確認遷移時機
端點在握手確認前不能主動遷移。客戶端發現本地地址變化後，可在新路徑上傳送探測；若伺服器宣告 disableactivemigration，客戶端不能主動從不同地址傳送普通資料，除非使用伺服器提供的 preferred address。這個限制避免把握手期間的地址變化當成已驗證路徑。
第三步：執行路徑驗證
新地址先傳送只含探測框的封包，伺服器回送 PATH_RESPONSE。驗證成功表示對端能收到並返回路徑上的封包；失敗只表示該路徑不可用，不應立即終止仍有有效路徑的連線。實作要設定探測逾時、重試上限和未驗證路徑的資源預算。
第四步：處理 NAT rebinding
NAT 可能在連線閒置後更換客戶端外部埠號，伺服器看到地址變化但仍收到帶有效 Connection ID 的封包。應先驗證新路徑，再更新路徑狀態；不能要求客戶端每次埠號變化都重新握手。對異常頻繁變化設定速率和狀態上限，避免攻擊者消耗探測資源。
第五步：保護壅塞與放大邊界
遷移後繼續使用舊的壅塞控制上下文可能不適合新路徑；實作應按協定和測量結果處理壅塞視窗、丟包和 RTT。伺服器不能向未驗證地址傳送大量非探測資料，避免 UDP 放大。新路徑驗證期間保留舊路徑，直到新路徑具備可用性證據。
第六步：考慮隱私與可關聯性
同一個 Connection ID 讓伺服器關聯地址變化，但觀察者也可能據此關聯使用者活動。客戶端可更換新的 Connection ID，並避免頻繁或可預測的地址切換；伺服器應遵守連線 ID 生命週期和加密要求，不能把公開 ID 當作使用者身份。
第七步：定義回退和觀測
記錄路徑驗證成功率、探測 RTT、遷移中斷時間、舊路徑保活、Connection ID 餘量、丟包和重新建立連線比例。驗證失敗時繼續舊路徑並指數退避；舊路徑不可用且無驗證新路徑時，關閉連線或重新握手。演練 Wi-Fi 切換、NAT rebinding、伺服器禁用遷移和惡意探測。
高品質示範回答
我會把 QUIC 連線狀態與地址路徑分開處理：Connection ID 讓伺服器在客戶端 IP 或埠號變化後識別同一連線。握手確認後，客戶端從新地址傳送 PATHCHALLENGE，收到 PATHRESPONSE 才把新路徑標記為可用；驗證期間繼續使用舊路徑並限制未驗證地址的狀態和傳送量。NAT rebinding 可沿用連線，但要驗證新埠號；若伺服器設定 disableactivemigration，客戶端不能主動遷移。連線 ID 要由負載平衡器支援，隱私場景更換 ID 並避免可預測關聯。監控驗證成功率、切換中斷、探測 RTT、丟包和重連，失敗時回退舊路徑或重新建立連線。
常見錯誤
- 把 QUIC 連線綁定到來源 IP 和埠號，網路切換就直接建立新連線。
- 在握手未確認時主動遷移，或跳過路徑驗證直接傳送大量資料。
- 把 NAT rebinding 當成協定異常，要求每次埠號變化都重新握手。
- 忽略
disableactivemigration和伺服器 preferred address 的限制。 - 遷移後無視新路徑 RTT、丟包和壅塞視窗，繼續假設舊網路條件。
- 複用可預測 Connection ID，或讓負載平衡器只按五元組路由。
追問及應對
追問一：為什麼不能只看 Connection ID 就信任新路徑？
Connection ID 關聯連線，但不能證明新地址上的對端可達。路徑挑戰和回應用於驗證返回路徑，避免向偽造地址傳送資料。
追問二：驗證失敗會破壞連線嗎？
不會，只要舊路徑仍有效。失敗表示新路徑不可用，端點應回退或繼續探測；只有沒有任何可用路徑時才關閉或重建連線。
追問三：伺服器為什麼要限制未驗證地址的傳送？
攻擊者可能偽造來源地址誘導伺服器放大流量。未驗證路徑只允許有限探測和受控狀態，驗證成功後才提高傳送預算。
追問四：遷移後壅塞視窗是否必須清零？
不能只憑地址變化作固定結論。新路徑的 RTT、頻寬和丟包可能不同，實作應遵循 QUIC 恢復機制並以測量校準，避免過度傳送或過度保守。
追問五：如何減少網路觀察者的關聯？
使用新的 Connection ID、合理輪換並避免可預測模式；同時仍需滿足伺服器路由和連線狀態管理，不能把 ID 當作身份憑證。
追問六：負載平衡器要改什麼？
它必須根據加密後的 Connection ID 或專用路由機制，把遷移前後的封包送到同一連線狀態所在的伺服器，不能假設地址變化代表新工作階段。