QUICはHTTP/3で利用されるトランスポートプロトコルであり、TCPにはない接続移行機能や柔軟なパケット管理機構を備えています。特にWi-Fiから5Gへの切り替えやNATリバインディングのように通信経路が変化する環境では、遅延やパケット順序の変化が発生します。
この記事では、QUICが経路変更時にどのようにパケット損失と単なる到着順序の変化を区別するのか、パケット番号空間、ACK処理、RTT推定、PTO、輻輳制御、path validationの関係を整理しながら解説します。
QUICではパケット番号空間が分離されている
QUICでは、すべてのパケットを同じ番号体系で管理するのではなく、暗号状態ごとに異なるパケット番号空間を使用します。
RFC 9000で定義されている主なパケット番号空間は以下の3種類です。
- Initialパケット番号空間
- Handshakeパケット番号空間
- Application Data（1-RTT）パケット番号空間
例えば、TLSハンドシェイク中のInitialパケットと、接続確立後の1-RTTパケットは別々のACK管理対象になります。そのため、Initialパケットの欠落によって1-RTTパケットの損失判定が影響を受けることはありません。
QUICの損失検出はパケット番号だけで判断しない
QUICの損失検出では、「パケット番号が飛んでいる」という単純な条件だけでパケットロスを決定しているわけではありません。
RFC 9002では、主に以下の2種類の損失検出方法が定義されています。
- Packet Threshold Loss Detection（パケット数による判定）
- Time Threshold Loss Detection（時間による判定）
Packet Thresholdでは、あるパケットより後の番号のパケットが一定数ACKされた場合、古いパケットを損失と判断します。一方、Time Thresholdでは、送信から一定時間以上経過してACKされない場合に損失と判断します。
そのため、ネットワーク経路変更によってACK順序が入れ替わった場合でも、一定の猶予を持って損失判定が行われます。
経路Aから経路Bへ移動した場合のパケット並べ替え問題
例えば、RTT20ms・低損失率の経路Aから、RTT80ms・高損失率の経路Bへ移行した場合、送信済みパケットの到着順序が変化する可能性があります。
旧経路Aを通ったパケットのACKが遅れて到着し、その後に新経路Bで送信したパケットのACKが先に到着するケースも考えられます。
このような場合、QUICは単純にACK番号の順番だけを見るのではなく、送信時刻、ACKされたパケット番号、RTT情報などを組み合わせて判断します。
つまり、「番号が前後した」という事実だけでは即座に損失とは扱わず、時間的な条件を満たした場合にのみlostとして扱います。
経路変更直後に古いRTT値で誤判定しないのか
経路変更によってRTTが急激に増加すると、過去のsmoothed_rttやrttvarを基準にしたtime thresholdが短すぎるように見える場合があります。
しかしQUICでは、このような状況が発生することを前提に、一定の誤判定を許容しながら、その後の測定結果によって状態を更新していく設計になっています。
RTT推定値は新しいACK情報を受け取るたびに更新されます。また、経路変更直後には一時的なspurious loss（実際には届いていたパケットを損失扱いする現象）が発生する可能性があります。
QUICは完全に誤判定をなくすことを目指すのではなく、誤判定が発生しても通信性能が回復できるような仕組みを採用しています。
Connection IDによる接続維持とpath validationの役割
QUICの大きな特徴として、IPアドレスやポート番号ではなくConnection IDによって接続を識別する仕組みがあります。
そのため、スマートフォンがWi-Fiから5Gへ切り替わり、送信元IPアドレスが変化しても、同じQUIC接続として継続できます。
ただし、新しい経路をすぐに信頼するわけではありません。QUICではPATH_CHALLENGEとPATH_RESPONSEを利用して、新しい経路が実際に通信可能か確認します。
この処理によって、攻撃者が偽の経路を登録することを防ぎながら、安全な移行を実現しています。
輻輳制御状態は経路ごとに管理されるのか
経路変更時の輻輳制御については、RFC 9002では基本的に送信側の輻輳制御アルゴリズムによって管理されますが、実装によって細かな扱いが異なります。
特にモバイル環境では、Wi-Fiと5Gでは帯域幅やRTT、損失特性が大きく異なるため、単純に以前のcwnd（輻輳ウィンドウ）をそのまま利用すると性能低下につながる場合があります。
そのため、一部のQUIC実装では経路ごとにRTT推定値や輻輳制御状態を保持する工夫が行われています。
例えば、GoogleのQUIC実装やモバイル向けQUICスタックでは、移動通信を考慮して、ネットワーク変更時に過去の情報を利用しながら急激な性能低下を避ける設計が採用されています。
PTOは経路変更時にどのように制御されるのか
PTO（Probe Timeout）は、ACKが返ってこない場合にプローブパケットを送信して通信状態を確認する仕組みです。
PTO値はRTT推定値とrttvarを基に計算されます。そのため、経路変更直後には一時的に適切ではない値になる可能性があります。
しかし、PTOによる再送やプローブ送信は、通信を復旧させるための安全弁として設計されています。
多少不要な送信が発生したとしても、新しいRTT情報が蓄積されることで徐々に適切な状態へ収束します。
実際のQUIC実装で行われている工夫
標準仕様では、相互接続性を重視して基本的な動作が定義されています。一方、実際の商用QUIC実装では、移動環境や大規模サービス向けに追加の最適化が行われています。
代表的な工夫として以下があります。
- 経路ごとのRTT履歴保持
- 移動検出時のcwnd調整
- spurious lossへの対応
- 経路品質に応じた送信制御
これらの工夫によって、スマートフォンのように頻繁にネットワークが変化する環境でも、接続を切断せず安定した通信を維持できます。
まとめ
QUICでは、Initial・Handshake・1-RTTごとのパケット番号空間分離、時間ベースとパケット数ベースを組み合わせた損失検出、Connection IDによる接続維持などによって、複雑なネットワーク変化に対応しています。
経路変更直後に旧経路のACKと新経路のACKが混在しても、QUICは単純な番号比較ではなく、ACK情報やRTT推定値を利用して損失判定を行います。
また、path validationによる新経路確認や、PTO・輻輳制御による状態調整によって、一時的な誤判定を許容しながら最終的には新しい経路へ適応する設計になっています。
コメント