要約

  • RFC 9621–9623 では、アプリが必須条件と選好を示し、実装がシステム方針、過去の状態、現在の候補を合わせて経路とプロトコルスタックを選ぶ。
  • Ready は適格なスタックが確立したことを示すが、候補一覧、順位付け、失われた選好、相手側処理、利用者の成果までは証明しない。

RFC 9621 の Transport Services Architecture は、アプリに個別の IP アドレス、インターフェース、プロトコルを固定させず、必要なサービスを記述させる。RFC 9622 は抽象 API を定め、RFC 9623 は候補の収集、枝分かれ、順位付け、競争を実装する方法を示す。

狙いは明確だ。ネットワークの変化や新しいトランスポートを、各アプリの大規模な書き換えなしに利用できる。だが、機構を下位層に移せば、選択権も移る。運用者は成功イベントだけでなく、その選択を追跡する必要がある。

必須と希望の間には停止条件がある

RFC 9622 は多くの選択プロパティに Require、Prefer、No Preference、Avoid、Prohibit の五段階を与える。Require は条件を満たす候補だけを残し、なければ失敗する。Prohibit は該当候補をすべて排除する。Prefer と Avoid は順番を動かすが、非希望の候補でも続行できる。

したがって「従量課金でない回線を Prefer」は、従量課金回線を使わないという約束ではない。費用や安全の境界なら、必須条件として表すか、接続後に別の検証が要る。実装は全ての Require と Prohibit を守らなければならない一方、選好の結果はホストと状況によって変わり得る。

Wi-Fi という名前も、無料、低遅延、私的な経路の証明ではない。RFC 9622 はインターフェース種別を従量制など別の性質の代用にしないよう求める。意思決定に必要な性質を直接表現しなければならない。

方針はアプリだけが持つのではない

RFC 9623 は、アプリの選好、動的な System Policy、実装の既定方針を区別する。管理者が特定回線を禁じ、OS がプロセスごとの制約を設け、実装が未指定項目に既定値を置く。選ばれる候補は三つの層の制約を全て満たす必要がある。

一方、RFC 9621 は System Policy の詳細がプラットフォーム固有であるため、抽象 API に共通の読み書き方法を定めない。アプリの意図は移植できても、決定理由が同じ形式で読めるとは限らない。失敗時には PolicyProhibited を返せても、成功した Ready に方針の版、候補一覧、順位の根拠が自動的に付くわけではない。

これは標準違反ではなく、監査境界である。共通契約は必須条件を扱い、ローカルな選択記録は、その時の方針が何を選んだかを扱うべきだ。

候補木の上段が下段を支配する

RFC 9623 は、ネットワーク経路、プロトコル選択、導出された宛先の順に枝を作ることを勧める。Wi-Fi と SCTP の両方を好む例では、キャッシュが Wi-Fi 上の SCTP を利用不能と判断すると、Wi-Fi の枝には TCP、LTE の枝には SCTP と TCP が残る。経路が先なので Wi-Fi/TCP が LTE/SCTP より先に試され得る。

二つの希望は消えていない。木の優先順位が組合せを決めた。勝者だけを保存しても、SCTP がなぜ試されなかったかは分からない。木の形、除外された枝、必須条件による削除、選好による順番を分けて残す必要がある。

候補は場所と時刻にも依存する。別の回線では DNS の答えが異なることがある。プロキシは実際の宛先とポートを変える。あるプロトコルが片方の経路だけで使える場合もある。同じ API 呼び出しは、同じ候補集合を保証しない。

競争は最速選手権ではない

RFC 9623 は、同時、時間差、失敗後切替えの三方式を示す。同時方式は速いが、余分な資源と未使用状態を生むため既定には勧められない。時間差方式は一定時間後に次候補を開始する。失敗後切替えは強い選好を先に完遂させる。

プロキシ経由を優先すべきとき、直接経路を同時に走らせれば数ミリ秒の差で方針を迂回し得る。強い方針なら、失敗後切替えか必須条件が必要だ。RFC 8305 の Happy Eyeballs はアドレス族での時間差競争を示し、TAPS は経路とスタックにも対象を広げる。

安全性はさらに厳しい。RFC 8922 はセキュリティ要件を Transport Services に結び付ける。攻撃者が第一候補を妨害し、弱い第二候補へ誘導できるなら、競争がダウングレード装置になる。競わせる候補は必須の安全要件を保ち、認められた安全等価性の範囲に入らなければならない。

キャッシュは次の選挙権を持つ

実装は DNS、TLS 再開状態、TCP Fast Open の情報、RTT、確立時間、成功率を保持できる。RFC 9040 は TCP 制御情報共有の背景を与える。この履歴は次回の候補を並べ、時には枝を最初から削る。

高速化の反面、古い失敗が修復後も候補を抑えたり、過去の勝者だけが新しい測定値を得たりする。RFC 9621 が、必要な性質を明示し、特定のキャッシュ挙動に依存しないよう求める理由である。

状態共有はプライバシーにも関わる。Connection Context を分離すれば、TLS 状態や多重化による結び付きも減らせる。選択記録は、秘密のチケットそのものではなく、キャッシュ領域、使用した測定種別、年齢、失効判断を残せばよい。

Ready が証明する一点

RFC 9623 では、少なくとも一つのスタックがアプリデータを送受信できる段階で確立が完了する。RFC 9622 の Ready はこの状態遷移を知らせる。これは重要なローカル受領証だ。

しかし、全ての選好、相手アプリの処理、料金回避、期限、利用者成果は別の問いである。証拠は、意図、方針、キャッシュ、候補、競争、勝者、メッセージ、相手処理、成果へ分解すべきだ。

RFC 9623 は Apple Network.framework、NEAT、NEATPy、PyTAPS を、程度の差はあるが関連する実装として挙げる。Apple の Network 文書 は経路制約とプロトコルを扱う実用 API を示すが、全実装の完全準拠や同一ログを保証しない。

情報源