前言

前一天的文章中介紹了關於 Path Validation 相關的流程，今天的文章會簡介 Path Validation 與 Connection Migration 兩個機制是如何整合在一起的。

探測新路徑(Probing a New Path)

在 QUIC 中 Connection Migration 由 Client 負責發起，如果 Client 端收到來自未知的 Server address， Client 端必須要丟棄封包。

在啟動 Connection Migration 流程之前，終端可以使用昨天文章提到的 Path Validation 機制驗證自己新的 local address 到對端的可達性(reachability)。

失敗的 Path Validation 代表這個新的 local address 不可作為連線遷移的新地址，但並不會導致 Connection 中斷，原先的連線還可以繼續維持。

PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, PADDING

上述四種 frames 在 QUIC 中被定義為 probing frames，其餘的 frames 被稱為 non-probing frames，如果一個封包中只有 probing frames 會被稱為 probing packet，反之則稱為 non-probing packet。

Connection Migration 的流程可以參考以下示意圖

來源

QUIC 的 Connection ID 允許 Client 在地址更改的情況下保持原有連線，不需要重新建立連線。

一般通訊交換資料都是使用 Non-probing Packet，上圖中可以看到當 Client 切換到新的地址時，還是可以發送一般封包，這時 Server 偵測到同一個 Connection ID 卻有不同的 Source IP，啟動 Path Validation 機制。

• Server 發送 PATH_CHALLENGE
  • Client 回傳 PATH_RESPONSE 並且 payload 設定成 PATH_CHALLENGE 附帶的內容
• Client 同樣也進行 PATH_CHALLENGE 流程
  • Server 回傳 PATH_RESPONSE 並且驗證 payload

在昨天 Path Validation 的解說中有提到，該機制只負責驗證我方的封包對方是否能正常接收，所以 Connection Migration 需要雙方都使用 Path Validation 機制驗證。

Connection Migration 除了上圖的簡單流程之外，Server 端還需要做一些額外處理

• 重發 token (用以之後的 0-RTT 連線)
• 重置 congestion controller
• 重新估算 RTT
• ...

結語

今天簡單的講解了關於 QUIC 的 Connection Migration 流程，可以看到 QUIC 中每個機制之間都是互相搭配的，Connection Migration 在 QUIC 中我認為也算是一個核心的機制，對目前很多要求低延遲的場景來說，無疑是一個大殺器。

在明後天的文章中會繼續探討 RFC9000 中介紹了關於 Connection Migration 的安全問題，以及 QUIC 為此使用了什麼方式去降低風險，最後會稍微帶一點關於 ngtcp2 的程式片段，讓有興趣的讀者可以試著去 trace 看看。