要約

  • ICP_HITは、問い合わせた正確なURLについて隣接キャッシュがオブジェクトを持ち、それを提供し得るという選択用の信号である。実際の通常取得はHTTPで行われるため、HIT自体は配送完了、出所、鮮度、身元、完全性、安全性を証明しない。
  • MISS、MISS_NOFETCH、DENIED、無応答、echoにはそれぞれ異なる意味があり、一括して「成功」や「障害」と扱うと、ポリシー、到達性、キャッシュ状態、取得能力を取り違える。
  • ICP応答には認証がない。これとは別に、HIT_OBJは通常のHTTP authorizationとage validationを迂回する。両者は異なる信頼境界の問題であり、混同してはならない。

RFC 2186を正確に読むには、ICPv2が何をするためのプロトコルだったかを狭く保つ必要がある。Duane WesselsとK. Claffyによる同RFCは、隣接キャッシュへURLの存在を問い合わせ、その応答から「次にどの取得元を試すか」を決めるためのICP version 2を定義した。オブジェクトそのものの通常の転送はHTTPが担う。

この役割分担こそ、ICP_HITの意味を規定する。HITは、対象URLのオブジェクトが隣接キャッシュにあり、その隣接が提供元になり得ることを示す。しかし、HITが返った時点ではHTTPによる取得はまだ別段階として残っている。したがって「HITを受け取った」と「オブジェクトが届いた」は同じ出来事ではない。

そこから先の証拠境界も明確だ。HITはオブジェクトの起源を証明しない。期待したオリジンに由来する真正な内容であることを保証しない。相手の身元を証明しない。オブジェクトの完全なバイト列を受け取ったことも示さない。

鮮度についても同じである。ICP_HITは隣接選択のシグナルであり、HTTPキャッシュにおけるfreshnessの判断やage validationが成立したという意味ではない。HTTPキャッシュの意味論と、ICPによる隣接キャッシュ選択は別の問題である。

さらにHITは、その内容が安全にレンダリングできること、候補の中で最良の取得元であること、数秒後にも同じオブジェクトが存在すること、アプリケーションまで正常に届くことを保証しない。まして、それを利用者が閲覧した、処理が完了した、収益や業務成果が生じた、といった上位の結果はHITから導けない。

言い換えれば、ICP_HITが直接支えるのは、「この時点で、この正確なURLについて、この隣接はHITと応答し、取得元候補になり得た」という限定的な命題である。それより強い結論には別の観測と検証が必要になる。

この設計思想はMISS系の応答にも現れる。ICP_MISSは、対象オブジェクトがそのキャッシュのローカルには存在しないことを示す。しかし、その隣接が要求を別の場所へ転送したり、ポリシーに従って処理したりする可能性を排除するものではない。したがってMISSは単純な「この隣接は使えない」という意味ではない。

ICP_MISS_NOFETCHはさらに具体的である。これはキャッシュが生きている一方、MISSしたオブジェクトを自ら取得しないことを伝える。相手が応答できていることと、MISSを取りに行かない方針であることを同時に示すため、無応答とは性質が違う。

ICP_DENIEDもまた、特定時点のポリシーに結び付いた応答である。恒久的な故障や能力不足を表すものではない。RFC 2186は、DENIED比率が高い場合に設定ミスの可能性を考慮すべきことを示しているが、それでも一件のDENIEDだけで原因を確定することはできない。

無応答はさらに弱い証拠である。ICP実装は通常、一、二秒だけ応答を待つべきとされる。その時間内に返答がなければ、取得元選択という目的には「今はこの隣接を選ばない」という判断ができる。しかし、沈黙の原因は分からない。

その無応答は、複数の可能な原因を一つの結果へ圧縮する。従って運用上は「do not select now」というアクションにつなげられても、「なぜ応答がなかったのか」という診断にはならない。選択判断と原因診断の距離を保つことが重要になる。

ICP echoも同じ原則に従う。echoは到達性の確認であって、キャッシュアプリケーションが正常であることや、対象オブジェクトを配送できることを証明しない。到達できることと、アプリケーションが正しく処理できることは別の事実である。

プロトコル自体も軽量な選択信号として設計されている。ICPv2のヘッダーは20オクテットで、メッセージは16,384オクテットを超えてはならない。要求番号はopaqueであり、その値自体に意味を読み込むものではない。応答側は要求番号をコピーし、問い合わせと応答を対応付けるために使う。

URLは正確でなければならない。この点は、ICP応答の来歴を理解するうえで重要である。HITやMISSは「あるサイト」や「ある種類のコンテンツ」全体についての一般的な評価ではなく、その時点の特定URLに対する応答イベントだからだ。

アドレスに関しても、異なるフィールドを別々に扱わなければならない。Sender Host Addressは、transportが観測したpeer addressより信頼してはならない。その目的は曖昧で、実務上は未使用である。従って、このフィールドを相手の確かな身元情報として扱う根拠はない。

一方、query内のRequester Host Addressは別のフィールドである。この値はzeroになり得て、all-zeroはunspecifiedを意味する。この事実をSender Host Addressの意味や信頼性と混同してはいけない。両者は異なるフィールドで、異なる意味上の問題を持つ。

Source RTTについても、値があることを過大評価すべきではない。RTTは保存されている場合も、ゼロの場合も、存在しない場合もある。また、その取得のためにICP応答を遅らせてはならない。従ってRTTは利用可能なら選択材料になり得るものの、常に観測される完全な比較尺度ではない。

通常のHITがこうした「次に試す場所」のヒントにとどまる一方、ICP_HIT_OBJは境界を変える。HIT_OBJではオブジェクト自体をICP応答に含めるため、通常のHTTP取得経路を通さずにデータが届く。

その結果、HIT_OBJはHTTP authorizationとage validationを迂回する。ここで迂回されるのはHTTP authenticationではない。この点は技術的に重要であり、ICP応答そのものに認証がないという別の事実と分離して理解する必要がある。

つまり、一つはHTTP処理経路で通常行われる認可とage validationをHIT_OBJが通らないという問題である。もう一つは、そもそもICP応答そのものに認証がないという問題である。両方とも信頼境界に関係するが、同じ問題ではない。

HIT_OBJにはMTU断片化のリスクもある。この機能は推奨されず、opt-inとされている。さらに、埋め込まれたオブジェクトが完全でない場合は、通常のHITとして扱われる。これは、部分的なデータを完全配送と誤認しないための重要な境界でもある。

RFC 2187は、認証を持たないICPのセキュリティ上の含意を明確にする。偽造されたHITは要求側の取得元選択を特定のキャッシュへ誘導し得る。逆に、偽造されたMISS_NOFETCHやDENIEDは、正当なキャッシュを候補から外す方向に働く。

未知のマルチキャスト隣接からの応答は無視されるが、それだけでなりすまし全般が解決するわけではない。認証されていない信号である以上、応答コードをそのまま主体の真正な状態報告だと扱うことはできない。

HIT_OBJが加わると、偽装の影響はさらに深くなる。通常の偽造HITが「どこへ取得しに行かせるか」を操作するのに対し、spoofingとHIT_OBJが組み合わされれば、配送されるコンテンツそのものを汚染できる可能性がある。

この差は、制御面とデータ面を分けて考える必要性を示している。取得元の選択を歪めることと、実際に受け取る内容を書き換えることは、同じ種類の影響ではない。HITという共通語だけでまとめると、その差が消えてしまう。

ICPv2を証拠として扱う際には、provenanceも重要になる。応答は世界全体についての一般論ではなく、特定の要求側と隣接の関係の中で、特定時点に、特定URLについて発生したイベントである。

DENIEDはその関係に適用されたポリシーを反映する。MISS_NOFETCHはその隣接の取得方針を反映する。HITはその時点の存在主張であり、無応答は短い待ち時間内に応答が観測されなかったという事実にすぎない。

このため、イベントの意味を保存するには、応答コードだけでなく、誰と誰の隣接関係で、いつ、どの正確なURLについて起きたかを維持する必要がある。関係や時刻から切り離せば、限定的な証拠が一般的な属性へ変質する。

RFC 2186の現在的な価値は、古いキャッシュ技術の記録にとどまらない。軽量な信号を軽量なまま扱い、観測できたもの以上の意味を加えないという設計姿勢にある。

ICP_HITは「隣接キャッシュを次に試す」ためのヒントである。出所、鮮度、身元、完全なバイト列、安全なレンダリング、最良の取得元、将来の可用性、アプリケーション配送、事業成果の証明ではない。この境界を守ることが、ICPv2を正しく運用し、正しく歴史化するための中心条件である。