要約

  • RFC 2187でparentとsiblingを分ける核心は、HITの有無よりもMISSの後にある。確認済みのHITならどちらからでも取得できるが、MISSを受けて先へ取得できるのはparentであり、siblingにはその権限も義務もない。
  • ICPのHIT、MISS、応答遅延、RTT、設定済みweight、multicast参加は、それぞれ限定された判断材料にすぎない。相互の権限、最安経路、真正な相手、対象の安全性、将来の容量や最終的な利用成功まで証明しない。
  • parentかsiblingかは機械の固定属性ではない。要求の種類やDNSドメイン、相手側のアクセス制御などにより、同じ相手でも扱いが変わり得る。
  • RFC 2186が扱うICPv2の通信形式、RFC 9211が扱うCache-Statusによる処理結果の記述は、RFC 2187が扱う階層上の権限とは別の層である。

「上」と「横」は地理ではなく役割を表す

RFC 2187は1997年9月公開のInformational RFCで、当時のWebキャッシュ階層にICPv2をどう適用したかを記録している。ここでparentは「一段上」、siblingは「同じ段」と説明されるが、それは物理距離やネットワーク上の近さを測った呼び名ではない。違いを決めるのは、要求した対象が相手のキャッシュにないとき、その相手を経由して取得を続けてよいかどうかである。

ローカルキャッシュに対象がなければ、近隣キャッシュへICPで問い合わせられる。相手がHITを返し、その対象を保持していることが確認できれば、parentでもsiblingでも取得先になれる。ところが近隣からHITが得られなければ、要求はparentへ渡すか、オリジンへ直接送る必要がある。siblingは、自分がすでに保持している対象を返すことはできても、MISSを受けてその先から取り寄せる役割を持たない。parentは、必要ならその続きを引き受ける。

このため、parentというラベルから「近い」「速い」「常に上流」と推測することはできない。RFC 2187は、必要な中継を提供するという機能上の役割から、parentが中継ISPの内部またはその経路上にあるのが望ましい場合を述べているが、役割を定義するのは配置ではなく、MISSを扱う権限である。

役割は相手の固定身分ではなく、要求ごとの設定で決まる

当時のSquidやHarvestでは、近隣キャッシュの利用を特定の要求群やDNSドメインに限定できた。同じ相手を、ある要求ではsibling、別の要求ではparentとして扱うことも可能だった。したがってparentやsiblingは、機械そのものに永続的に貼られる身分ではなく、設定された方針の範囲で成立する役割である。

階層に載せない要求もある。ローカルでHITした要求、設定済みのローカルオリジン、GET以外の要求、停止リストに該当するURLなどは、ICPによる近隣照会を使わず、オリジンへ直接進むことがある。Pragma: no-cacheを伴う要求では、siblingに問い合わせない扱いも記録されている。siblingでMISSになれば、許可されていない中継を必要とするからである。

また、利用できるparentが一つだけなら、single_parent_bypassによってICPの返答を待たず、そのparentへ進むこともできた。ここでも重要なのは、ICPが階層そのものを作るのではなく、すでに設定された選択肢の中で次の取得先を決める材料として使われる点である。

両端の設定がそろって初めて運用上の関係になる

近隣関係には、問い合わせる側と受ける側の双方の設定が関わる。問い合わせる側は相手をparentまたはsiblingとして登録する。一方、問い合わせを受ける側は通常、アクセス制御によって、その相手からのICPやHTTP要求を受け入れる範囲を定める。

HTTPとICPの利用を認め、MISSまで中継できるなら、実質的にparentの役割を許していることになる。反対にsiblingの意味を保つには、MISSへのアクセスを拒否し、その扱いを相手側の設定とも一致させる必要がある。

ICPメッセージそのものには、相手との関係がparentかsiblingかは埋め込まれていない。HITやMISSは、問い合わせる側のローカル設定と組み合わせて解釈される。問い合わせる側はsibling経由でMISSを解決しないよう制御する必要があり、受ける側はアクセス制御によってその境界を間接的に守る。この分担があるため、片側のラベルだけで相互の権限まで証明することはできない。

両側で一致した設定が確認できれば、相互に対応した構成があるとは言える。それでも、すべての要求群に同じ方針が適用されるとは限らない。ドメインや要求の種類によって役割を変えられる以上、相互設定の存在と完全な対称性は別の事柄である。

HITとMISSは状態の答えであり、権限そのものではない

HITを受けた場合、その相手から取得を開始できる。parentからのMISSは、他にHITがなければ、そのparent経由で取得を続ける候補になり得る。一方、siblingからのMISSは中継の許可を意味しない。

この差は、同じMISSという返答でも、設定された関係によって意味が変わることを示している。ICPの返答は対象の所在に関する局所的な証拠であり、その証拠を使って何をしてよいかは別に定められた方針で決まる。

偽のHITがこの境界を崩す例もRFC 2187に記されている。HITを信じてsiblingへ取得に行った後、実際にはMISSで、そのsiblingが正しく中継を拒否すれば、要求は失敗し得る。ここで問題になるのは、siblingが中継しないこと自体ではなく、局所的な選択信号を確実な保証として扱ったことである。

遅延、RTT、weightは選択材料であって最良性の証明ではない

HITが得られない場合、複数のparentからどれを使うかという別の問題が残る。RFC 2187では、返答の遅延、保存された送信元RTT、設定済みweight、multicastでの返答順などを選択材料にできることが述べられている。

しかし、これらの値はそれぞれ限られた層しか示さない。weightは運用者が設定した優先度であり、最安経路を実測した値とは限らない。RTTは測定時点の往復遅延であり、対象全体の転送時間や将来の帯域余力を保証しない。返答が速いことは、空いている相手と相関する場合があっても、将来の配信性能そのものではない。

RFC 3143は、この区別を後年の運用上の問題として具体化した。最初に応答する低遅延の相手が、より高い帯域を持つ別の相手より実際の取得を速く終えるとは限らない例が示されている。その例では、高帯域の相手がparentとして適切でも、siblingとしては適切でない場合がある。単一の遅延観測と、関係上の役割は同じ軸ではない。

RFC 2187自身も、ICPを単なる対象所在の確認に使う見方と、相手選択や負荷分散にまで使う見方の間に曖昧さがあることを指摘している。返答時間は有用でも、容量や最終的な取得結果の完全な予測にはならない。

multicast参加と信頼関係も別である

multicastを使えば、一つの宛先へICP問い合わせを送り、複数の近隣キャッシュから返答を受けられる。しかしgroupへの参加そのものに特別な権限が必要とは限らないため、参加しているという事実だけで信頼できる相手とは言えない。

RFC 2187は、明示的に近隣として設定したアドレス以外からの返答を信用しない運用を勧めている。つまりmulticast参加が示すのは通信への参加であって、認証済みの識別や中継権限ではない。

同じことはセキュリティにも当てはまる。ICPには組み込みの認証済み識別保証がない。偽の返答によって特定の近隣を使わせたり使わせなかったりすることや、RTT情報の改変によって選択を動かすことが問題として挙げられている。firewallやセキュリティ方針は、ICPメッセージの外側で導入者が管理する領域である。

オリジンへの直接取得は独立した経路である

階層から適切な相手を選べなければ、オリジンへ直接進むことができる場合がある。これはparent経由の別名ではなく、独立した経路である。反対にfirewallの内側ではオリジンへ直接接続できず、利用可能なparentを選ぶ必要がある場合もある。

この違いは、同じHITやMISSでも、周辺の設定によって結果が変わることを意味する。直接取得が可能なら、近隣選択に失敗しても別経路へ逃がせる。直接取得が不可能なら、parent設定やアクセス制御の不一致がより大きな停止要因になる。

RFC 2187が扱うのは、こうした1997年前後の運用関係である。ここから現在のICP普及率や現代のCDN契約、価格、商業上の義務を導くことはできない。

証拠は、それが示す層より広げて読まない

設定された近隣ラベルは、少なくとも片側に記録された方針を示す。両側で対応する設定があれば相互設定の存在を補強するが、すべての要求群で対称な権限があることまでは示さない。

HITは、一つのキャッシュ状態に関する返答である。parentからのMISSは中継候補になり得る。測定された応答遅延、保存済みRTT、設定済みweight、multicast参加、返された対象、成功した取得も、それぞれ自分の層の事実を示すにとどまる。

これらのどれ一つを取っても、相手が認証済みであること、権限が相互であること、最安の経路であること、対象が新鮮で安全であること、将来の容量が十分であること、転送が完全に終わること、アプリケーションが受領すること、利用者が成功を確認すること、事業上の成果が生じることまでは証明しない。

RFC 3040がICPの通信形式と適用を別文書として整理し、RFC 2186を通信意味論、RFC 2187を適用として参照している点も、この層分けと一致する。さらにRFC 9211のCache-Statusは、キャッシュが応答をどう処理したかを後から記述するための仕組みであり、1997年の近隣関係でMISSを誰に渡してよいかを決めるものではない。

RFC 2187のキャッシュ階層は、距離を表す地図ではない。設定された関係が権限の範囲を決め、ICPがその時点の選択材料を返し、その後に取得経路が選ばれる。関係、信号、選択、転送、検証、最終結果を分けて読むことが、この資料の射程を守る最も確実な方法である。