要約

  • RFC 3568は、2000年12月以前に知られ、または使われていたDNS、トランスポート層、アプリケーション層のリクエストルーティングを整理した2003年のInformational文書であり、標準でも現在の導入調査でもない。
  • 「最適」はサーバーの固定属性ではない。観測した主体、見えた要求、候補集合、測定方向と鮮度、ポリシー、引き渡し方法に有効期限を付けた判断である。

URL書き換えは選択結果をページに刻む。事前書き換えならクライアント固有情報を持たず、動的書き換えなら最初の要求がオリジンに届いた時点でクライアントを考慮できる。いずれも、埋め込みオブジェクトの取得先をサロゲートへ変える。

問題はページが判断を保存することだ。RFC 3568は、書き換えたページをキャッシュ不可または短期キャッシュにすべきだと述べる。古いURLが利用不能、またはもはや適切でないサロゲートを指すからである。ここではコンテンツの鮮度と経路判断の鮮度が同じ器に入る。

DNSの判断もキャッシュに残る

専用DNSサーバーは、ポリシーや測定に応じてA、NS、CNAMEを変えられる。一つの応答は一台または仮想アドレスを返し、複数応答は候補群を示す。NSやCNAMEは判断を複数の専門DNSへ分割する。

ただし通常のDNS問い合わせはクライアントアドレスを伝えない。見えるのはクライアントサイトのDNSであり、再帰があれば、そのDNSの代理で問い合わせる別のサーバーしか見えないこともある。測ったRTTは、その可視リゾルバへのRTTである。

共有リゾルバの利用者はTTL中に同じアドレス群へ向けられるため、フラッシュクラウド時には一つのサロゲートへ集中し得る。TTLを短くすれば障害へ反応しやすいが問い合わせ量は増える。実装がTTLを守らない場合もある。キャッシュに残る選択と、その根拠の有効期間を別々に記録しなければならない。

多段解決は責任も多段にする

NSリダイレクトは名前の階層に制約され、最後のDNSが解決全体のTTLへ影響できる。異常な参照はタイムアウトを起こし、サーバーを増やすほど遅延も増える。CNAMEは新しいドメインへ移れるが、追加解決が必要だ。

最終Aレコードだけでは、どの判断主体が候補を狭め、どのキャッシュが古い情報を残したか分からない。各段について入力、候補、規則、出力、TTL、時刻を残すべきである。

Anycastは判断場所を選ぶ

同じanycastアドレスを複数のリクエストルーティングDNSが広告すると、ルーティング上クライアントサイトDNSに近いインスタンスが問い合わせを受ける。これは判断場所を見つける仕組みであって、クライアントに最良の配信ノードを決め終えた証拠ではない。

そのDNSが実クライアントに近いとは限らず、ルーティングプロトコルは通常サーバー負荷を見ない。ルーティング上の近さが最小遅延とも限らない。anycast到着とサロゲート選択は別のreceiptにする必要がある。

DNSはドメイン名までしか自然に見えない。オブジェクト種別やハッシュを名前へ符号化すれば粒度は上がるが、一ページで複数解決が起こり、総遅延が増える可能性がある。

トランスポート層では経路が分かれる

最初のパケットを調べると、クライアントIP、ポート、L4プロトコルが分かる。DNSの粗い選択を、実クライアントに近い情報で精査できる。

しかし新しいサロゲートへの順方向トラフィックは、最初にDNSが選んだサロゲートを経由し続ける場合がある。大きな逆方向トラフィックは新ノードからクライアントへ直接戻り得る。選択経路、往路、復路は同一ではない。

測定値には対象と方向が要る。引き渡しには受理と発効時刻が要る。RFC 3568は具体的なセッション引き渡し方式を範囲外にしているため、選択記録だけで成功を補ってはならない。

アプリケーション層の精度には権限が要る

アプリケーション層はURL、Cookie、言語、User-Agentなどを見て、オブジェクト単位やセッション単位で選べる。302型リダイレクトは単純だが往復を増やし、クライアントが次の要求を送るまで完了しない。経路内要素は接続を透過的に横取りし、別ノードの接続とspliceできるが、解析処理と状態をトラフィック経路へ持ち込む。

TLSでは境界がさらに明確だ。コンテンツネットワークはTLSを終端しない限り完全なURLを見られない。詳細な選択情報を得るには、証明書、鍵、要求内容と変更権限を引き受ける。可視性の向上は、権力の移転でもある。

測定は観測地点を消せない

候補選択にはRTT、ホップ数、BGP情報、サロゲート負荷、コンテンツ有無が使われ得る。文書内の近接性はRTTを意味し、DNS方式ではローカルリゾルバへ測る。片方向測定もある一方、インターネット経路は非対称になり得る。

能動probeは周期的で、NATやfirewallに遮断され、侵入検知を発火させる場合がある。無応答だけで遠い、または故障とは言えない。HTTP probeもリアルタイム負荷を得にくく、古いfeedbackは不正確になり得る。BGP AS_PATHが良い選択指標として無意味な場合があることもRFCは注意する。

測定receiptには発信元、対象、方法、方向、時刻、生値、失敗の意味を保存する。ポリシーreceiptには版、制約、重み、tie-breakを保存する。これで初めて選択を再現できる。

判断を配信結果までつなぐ

最小の証拠グラフは、見えた要求主体、リゾルバ連鎖、queryまたはobject、候補と除外、各測定から始まる。次にポリシー、選択、失効時刻を置く。さらにDNS応答、リダイレクト、書き換え、横取りまたは引き渡し、TLS終端主体を保存する。

最後にサロゲートの受理、対象オブジェクトの存在、サービス時負荷、実際の応答経路、完了、再試行、アプリケーション結果をつなぐ。DNS応答は到着ではない。リダイレクト送信は追随ではない。URL書き換えは配信ではない。選択は受理ではない。

証拠の境界

この記事はCDN、運用者、リゾルバ、クライアント、オリジン、サロゲート、製品、事故または実測成果を特定しない。RFC 3568は歴史的なInformational調査である。

RFC 3466は同時代のモデル、RFC 3238は仲介者の考慮事項を示す。RFC 2782、RFC 1546、RFC 1034、RFC 1035、RFC 2181はDNS文脈、RFC 3272、RFC 2386、RFC 3221は経路文脈である。RFC 7336とRFC 8008は後年のCDNI文脈に限り、過去へ投影しない。

Heng LuのRunning-Code PrimacyとMinimum Initial Specificationは明示した編集上の視座である。宣言された選択ではなく稼働中の配信を検証し、共通境界を小さく保つ理由になるが、RFC著者の意図や導入結果の証拠ではない。

限定的な結論は、URLもDNS回答も判断の容器になり、その容器は根拠より長生きし得るということだ。誰に対し、どの候補から、どの観測で選び、実際に届いたかまで保存して初めて「最適」は監査可能になる。

Sources