大容量ダウンロードとVPN：経路はリクエストの時点で選ぶ
ルーターは応答が届く前にその大きさを測れない。タスク単位の振り分けにはアプリケーション側の判断点か、既存の経路を保つ待ち行列ポリシーが必要だ。
「大きなダウンロードはVPNの外へ回し、小さな応答はVPNに残す」は経路制御の方針のように聞こえるが、そうではない。ルーターが判断に使えるのはその瞬間に得られる情報だけだ。アドレス、ポート、プロトコル、firewallのマーク、識別済みのフロー。応答の最終的な大きさはその集合に含まれない。まだ届いていないからであり、ルーターがバイト数を測れる頃にはすでに運んでいる。タスク単位で振り分けたいなら、判断はタスクを知る地点へ移さなければならない。以下のチェックリストは、あなたの設計にその地点があるかを確かめるためのものだ。
ルーターが応答の大きさを測れない理由
パケットに経路が必要な瞬間、ルーターが見ているのはせいぜいフローの最初の数パケットだ。誰と誰が話しているか、どのプロトコルか、どのマークか、これまで何バイト通ったかは分かる。通ったバイト数は過去を語る。応答の大きさは、まだ生成されていない応答の性質であり、分割応答やストリーミングでは事前に知りえないことすらある。
プロトコル自身のメタデータも見た目より弱い。HTTPは本文の前に長さを告知しない応答を認めており、一度の利用者操作が多数のリクエストを生み、その合計コストがどのヘッダー値とも似ないことがある。ヘッダーをタスクの大きさとみなすのは、経路の誤りである前にモデルの誤りだ。
チェック1：経路を選べる判断点はあるか
選択を行うコンポーネントを名指しする。そのうえで、選ぶ時点で何を知っているかを名指しする。文書化されたホスト群から取得する更新プログラムは、転送が始まる前に自分の目的を知っている。メタデータを見てからリクエストを開くダウンロードサービスは、接続ができる前にタスクを知っている。協調するproxyは、ルーターのふりをせずにリクエスト単位のポリシーを適用したり応答をキャッシュしたりできる。
答えが「ゲートウェイ」なら、チェックリストはすでに失敗している。ゲートウェイは既知のフローを宛先、マーク、クライアント区分で分類し、最初のパケットから既定の経路へ送れる。承認済みの更新プログラムには足りることが多く、未知の応答サイズには決して足りない。
チェック2：メタデータは実際に何を語るか
アプリケーションを意識した振り分けは、読むフィールド以上のものではない。HTTPの意味論の応答長の規則は、開始時点で長さが得られない場合を認めており、内容の符号化によって転送バイト数は表現の大きさとそもそも異なる。したがってヘッダーがしきい値を超えたときに経路を変えるポリシーは一貫しない挙動になり、しかも狙っていた大容量転送まさにそのもので起こる。
アプリケーションのメタデータが支えられるのはタスクについての判断だ。このワークフローは一括同期、これは対話的、これは既知の配布元からのソフトウェア更新。これは意図の言葉で書かれたポリシーであり、試験できる程度に安定している。「この応答は四十メガバイトより大きくなる」はその種のポリシーではない。
チェック3：フローはすでに存在するか
経路は接続の同一性を変えずにあるフローに対して変わりうる。この区別は正確に保つ価値がある。TCP接続は両端のアドレスとポートで識別され、経路表が下で変わればパケットは別の道を通れる。目に見えないまま変えられないのはネットワークアドレス変換の状態だ。トラフィックを別の出口へ移すと通常は公開の送信元タプルが変わり、遠端は対応する状態を持たない別の相手を見ることになる。
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10つまり実務上の規則は、接続の途中で出口を移すのは移行ではなく新しい関係だということだ。同じ接続を続けたいなら、判断は最初のSYNより前に済ませておく必要があり、後から足したパケット規則ではきれいに再構成できない。
チェック4：本当の要件は出口ではなく遅延か
「大容量トラフィックをよそへ送れ」という要求の多くは、実は大きな転送のせいで対話的な作業が遅く感じるという不満だ。それはスケジューリングの問題であり、スケジューリングの答えがある。既存の経路で公平な待ち行列や対応済みの帯域ポリシーを使えば、どちらも動かさずに、一括フローがチャットのメッセージを飢えさせるのを防げる。
tc qdisc replace dev eth0 root cake bandwidth 100mbit症状にこう対処すれば、出口の判断はセキュリティポリシーが置いた場所にとどまり、一つのコマンドで戻せる。トラフィックの種類ごと出口を変えるのは、認証、記録、アクセス規則に影響するポリシー変更であり、遅延の苦情に対して最初に手を伸ばす道具であるべきではない。
要件が本当に別のインターネット出口なら、その言葉で述べ、対応済みの境界で実装する。承認されたワークフローからの新しい接続、あるいは選んだ出口から自分のリクエストを開くアプリケーション。そして、どのタスクがどの出口を使うかを記録し、次の人が経路表から推測しなくて済むようにする。
チェックリストを変更記録に残す。判断点、それを動かすフィールドやタスク、フローがすでにあるか、測った症状が遅延か出口か。四つの問い。四つすべてに答えるポリシーは、守るものではなく運用できるものだ。