Wi-Fiから携帯回線へ切り替わると、端末が通信に使うIPアドレスやポート番号が変わることがあります。QUICには、この変化をまたいで一つの接続を続けるための接続移行（connection migration）があります。ただし「同じ接続だと分かること」「次の送信先を選ぶこと」「新しい経路へ実際に届くと確かめること」は、別々の役目です。
簡単にまとめると？
- QUICの接続IDは、IPアドレスとポートの組だけに頼らず、受信パケットを既存の接続へ結び付けます。一つの接続で複数のIDを使えます。
- 意図的に新しいローカルアドレスから送るときは、相手が発行した未使用の接続IDを使います。同じIDの使い回しを避け、異なる経路の通信を結び付ける手掛かりを減らします。
- 新しいアドレスの選択と経路検証は別です。遅れて来た古いパケットで送信先を戻さない規則もあります。
接続の「住所」と「識別子」を分ける
IPアドレスとUDPポート番号は、パケットを届ける先を表します。一方、接続ID（Connection ID）は、届いたパケットをどのQUIC接続として扱うか判断するための識別子です。RFC 9000の5.1節は、この分離によって下位のアドレスが変わっても接続を識別できる仕組みを説明しています。
たとえばサーバーが、同じ接続を指すID「S1」と「S2」をクライアントへ渡したとします。クライアントはサーバーへ送るパケットの宛先接続IDに、そのどちらかを入れます。S1からS2へ変えても、それだけで新しい接続を作ったことにはなりません。IDは相手が発行して受信時に解釈するものであり、利用者の名前や端末の恒久的な番号ではありません。
接続を続けるのに、なぜIDを変えるのか
旧アドレスAと新アドレスBで同じ接続IDを使い続ければ、途中でパケットを観察する人にも両者の結び付きが見えやすくなります。RFC 9000の9.5節は、複数のローカルアドレスから送信するときに同じ接続IDを再利用してはならないと定めています。意図的な移行だけでなく、新しい経路を試すパケットにも関わる規則です。
したがって、AではS1、Bではあらかじめ受け取っていた未使用のS2、という使い分けが必要になります。相手はNEW_CONNECTION_IDフレームなどで追加のIDを用意します。新しいIDを勝手に作って送ればよいわけではありません。
これは匿名性を保証するものではありません。IDを変えても、送信の時刻や大きさなどから通信が関連付けられる可能性は残ります。また、ネットワーク内のNATが外側のポートなどを変えるNATリバインディングは、端末が意図して移行する場合とは事情が違います。端末が変化を知らないため、受信側には新しいアドレスから同じIDのパケットが届くこともあります。
遅れて届いた旧経路のパケットで、宛先を戻さない
経路が変わる前後では、送った順と届く順が入れ替わることがあります。移行が許され、ハンドシェイクも確認済みの接続で、サーバーが正当なデータ入りパケットを次の順に受け取ったとします。番号は説明用で、同じアプリケーションデータのパケット番号空間を使います。
最初はAから番号40が届き、次にBから番号42が届きます。Bのパケットはそれまでで最大の番号なので、サーバーは以後の送信先をBへ変えます。その後、遅れてAから番号41が来ても、41は42より小さいため、宛先をAへ戻す理由にはしません。
これは9.3節にある、送信先のアドレス変更はそれまでで最大の番号を持つ非プロービングパケットに応じて行う、という規則の例です。非プロービングとは、経路を試すためだけのパケットではない、という意味です。番号41の中身を受信処理することと、送信先を切り替えることは区別します。
経路検証は「その先へ届くか」を確かめる
接続IDが一致しても、新しいアドレスへ確実に通信できるとは限りません。経路検証（path validation）では、PATH_CHALLENGEに予測しにくい値を入れて送り、同じ値を返すPATH_RESPONSEを確認します。単にチャレンジを含むパケットがACKで確認された、というだけでは検証完了になりません。
この確認は、相手がそのアドレスでパケットを受け取れるか調べるためのものです。パケットの暗号学的な認証を接続IDで代用する仕組みではありません。移行前に経路を試すことはできますが、常に検証が終わってから最初のデータを送る、という単純な順番でもありません。検証前には送信量の制限などを守りながら扱います。
そのためログを読むときは、IDがS2へ変わった時刻だけで「移行成功」と決めず、新アドレスの採用、チャレンジへの応答、実際のデータの継続を分けて見ると、どこで止まったかを追いやすくなります。
移行できる条件と、維持されない性能
ここで扱ったのはQUIC version 1の基本仕様です。ハンドシェイクの確認前に移行を始めることはできません。相手がdisable_active_migrationを示した場合など、能動的な移行が許されない条件もあります。サーバーが通知したpreferred_addressへ移る仕組みには別の条件があり、自由にどちらの端点でも住所を変えられる、という意味ではありません。
接続が続いても、回線の往復時間や使える帯域は変わります。新しい経路では輻輳制御や往復時間の見積もりを見直す必要があり、ポートだけの変更などには例外があります。「接続を作り直さずに続けられる」と「速度も待ち時間も変わらない」は別の性質です。
この例は仕様の一部を小さな時系列で示したものです。実パケットを送る試験でも、特定アプリの回線切替を保証する測定でもありません。運用上は、移行の許可、利用できる接続ID、経路検証、切替後の性能を別々に確かめることが判断の材料になります。
出典
- RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport（2021年5月）。5.1節の接続ID、8.2節の経路検証、9節の接続移行、特に9.3〜9.5節。
- RFC Editor: RFC 9000の書誌・標準化状況。参照した本文はQUIC version 1の基本仕様。