Zusammenfassung

  • RFC 2187 beschreibt parent und sibling als unterschiedliche Betriebsrollen. Ein bestätigter HIT kann von beiden bezogen werden; ein MISS darf nicht über einen sibling aufgelöst werden, während ein parent Transit anbieten kann. Der direkte Abruf beim origin bleibt ein eigener Pfad.
  • ICP-query/reply liefern Hinweise für die Wahl der nächsten Quelle, aber keine umfassende Aussage über Kosten, Identität, Sicherheit, Freshness oder künftige Kapazität. Die entscheidende Semantik entsteht aus lokaler Konfiguration, Zugriffskontrollen, timeouts, Firewall-Regeln, Multicast-Verhalten und Fallback.
  • RFC 2186 definiert das Nachrichtenformat und die opcodes von ICPv2; RFC 2187 dokumentiert dessen Anwendung. RFC 9211 behandelt wesentlich später die Beobachtbarkeit der Cache-Behandlung per HTTP-Header. Diese Ebenen sind nicht austauschbar.

Eine Hierarchie aus Rechten und Pfaden

Der zentrale Satz von RFC 2187 steht nicht in einer formalen Definition, sondern in der Beschreibung des normalen Anfrageflusses. Hat ein lokaler Cache ein Objekt nicht, kann er Nachbarn per ICP fragen. Meldet ein Nachbar einen HIT, kann das Objekt dort angefordert werden. Melden die Nachbarn keinen brauchbaren Treffer, muss die Anfrage entweder zu einem parent oder direkt zum origin weitergehen. Der entscheidende Unterschied: Ein „neighbor hit“ kann von parent oder sibling geholt werden; ein „neighbor miss“ darf nicht von einem sibling bezogen werden.

Damit ist „gleiche Ebene“ oder „eine Ebene höher“ nicht sinnvoll als bloße Geografie zu lesen. RFC 2187 sagt zwar, ein parent sei im Wesentlichen eine Stufe höher und ein sibling auf derselben Stufe. Doch die operative Bedeutung wird unmittelbar danach über erlaubte Handlungen erklärt. Der sibling stellt vorhandene Cache-Inhalte zur Verfügung. Der parent kann zusätzlich Transit leisten, also eine Anfrage weiterführen, auch wenn er das Objekt selbst nicht im Cache hat.

Figur 1 der RFC trennt außerdem ausdrücklich den parent-Pfad vom direkten Abruf beim origin: parent löst HITs und MISSes, sibling nur HITs, und bestimmte Anfragen gehen direkt zur Quelle.

Diese Unterscheidung ist eine nützliche Grenze für jede spätere Interpretation von Telemetrie. Ein neighbor label beweist zunächst nur, welche Rolle lokal konfiguriert wurde. Es beweist keine wechselseitige Autorisierung. RFC 2187 beschreibt die Einrichtung einer Peering-Beziehung als manuelle Konfiguration an beiden Endpunkten: Die eine Seite bezeichnet den anderen Cache als parent oder sibling; die Gegenseite muss typischerweise passende Access-Control-Regeln setzen. Besonders aufschlussreich ist, dass der Typ der Beziehung nicht in der ICP-query selbst codiert ist.

Die empfangende Seite kann Anfragen erlauben oder MISS-Zugriff verweigern; die sendende Seite muss ihrerseits wissen, wie sie HIT und MISS behandeln darf.

Hier liegt die eigentliche „authority“ des Systems: nicht in einem einzelnen Paketfeld, sondern in der Kombination aus lokaler Rollenzuweisung und Gegenstellen-Policy. RFC 2187 nennt diese Konstruktion selbst unbequem: ICP enthält kein Feld, das sagt, ob zwei Caches sibling oder parent sind. Ein HIT oder MISS sagt ebenfalls nicht „du darfst dieses Objekt von mir holen“ beziehungsweise „du darfst es nicht holen“. Der anfragende Cache muss das Ergebnis mit seiner Konfiguration verbinden; die befragte Seite wirkt indirekt über Access Controls mit.

HIT ist Evidenz — nicht die ganze Entscheidung

ICP wurde als leichtgewichtiges Verfahren gebaut, um Hinweise darüber auszutauschen, ob eine URL beziehungsweise ein Objekt in einem Nachbar-Cache vorhanden ist. RFC 2186 definiert dafür das Nachrichtenformat und die opcodes, darunter ICP_OP_QUERY, ICP_OP_HIT und ICP_OP_MISS. RFC 2187 beschreibt dagegen, wie Implementierungen diese Nachrichten in einem Cache-Verbund anwenden. Ein ICP_OP_HIT löst in der beschriebenen Praxis den Abruf beim antwortenden peer unmittelbar aus. Trotzdem ist der HIT kein universeller Wahrheitsbeweis. RFC 2187 verlangt für einen HIT, dass der Cache die URL lokal findet und der Eintrag nach den lokalen Refresh- oder TTL-Regeln mindestens noch für kurze Zeit frisch ist. Zugleich weist die RFC auf eine race condition hin: Zwischen ICP_OP_HIT und der folgenden HTTP-Anfrage kann das Objekt verschwinden. Ein HIT ist daher eine zeitlich lokale Aussage über den erwarteten nächsten HTTP-Schritt, keine Garantie vollständiger delivery.

Beim speziellen ICP_OP_HIT_OBJ kann ein kleines Objekt direkt in der ICP-Antwort mitgeliefert werden. RFC 2187 warnt, dass ICP wesentliche HTTP-Anforderungssemantik nicht ausdrücken kann, darunter damals relevante Cache-Control- und Validierungsbedingungen. Deshalb kann ein per HIT_OBJ geliefertes Objekt gegen Constraints der eigentlichen HTTP-Anfrage verstoßen; die Nutzung dieser Funktion wird ausdrücklich abgeraten. Später fasst RFC 3040 das Problem ähnlich: ICP übermittelt nicht die zu einer Ressource gehörenden HTTP-Header, obwohl darin Zugriffskontrollen und Cache-Regeln liegen können; dadurch sind „false cache hits“ möglich.

Damit ist auch Freshness sauber abzugrenzen. Ein ICP-HIT ist nicht dasselbe wie ein vollständiger, nach allen HTTP-Bedingungen bewerteter Cache-Status. RFC 2187 dokumentiert eine begrenzte lokale Freshness-Prüfung für die HIT-Antwort, zeigt aber zugleich, warum ICP die reichere HTTP-Semantik nicht abbilden kann. Aus einem HIT allein lässt sich deshalb weder allgemeine Freshness noch die Eignung des Objekts für jede konkrete HTTP-Anfrage ableiten.

MISS bedeutet je nach Rolle etwas anderes

Noch stärker als beim HIT zeigt sich die Rollensemantik beim MISS. Ein ICP_OP_MISS von einem sibling wird ignoriert. Ein MISS von einem parent kann dagegen für den späteren Abruf vorgemerkt werden. RFC 2187 beschreibt etwa den FIRST_PARENT_MISS und eine Variante, bei der RTT-Informationen zum origin berücksichtigt werden. Sind alle verwertbaren Antworten MISSes, muss der Cache zwischen einem passenden parent und dem origin wählen.

Auch hier entscheidet nicht ein einzelnes Messsignal. Squid konnte parent-MISS-RTTs gewichten, ausdrücklich weil der „closest parent“ nicht zwingend der parent ist, den man tatsächlich verwenden will. Gemessener delay ist damit eine Eingabe in den Auswahlalgorithmus; konfiguriertes weight ist Betreiberpräferenz, keine Bescheinigung niedrigster Gesamtkosten.

RFC 3143 führt den Punkt später an heterogenen Netzen weiter aus. Ein peer mit niedriger Antwortlatenz kann für große Objekte dennoch der schlechtere Datenpfad sein, wenn seine Bandbreite wesentlich geringer ist. Ein auf die erste HIT-Antwort gestützter Auswahlmechanismus kann deshalb die tatsächliche Retrieval-Latenz verfehlen. RFC 3143 behandelt dies ausdrücklich als architektonisches Problem der peer selection. Ein schneller ICP-reply beweist folglich nur die Geschwindigkeit dieser Antwort unter den aktuellen Bedingungen, nicht die schnellste vollständige Objektübertragung.

Der direkte origin-Pfad bleibt dabei eigenständig. Wenn ICP keinen geeigneten parent liefert, beschreibt RFC 2187 den direkten Abruf beim origin als Fallback — sofern eine Firewall ihn nicht verhindert. Zudem können Administratoren „lokale“ Server oder bestimmte Anfrageklassen so konfigurieren, dass überhaupt kein ICP benutzt wird. Die Hierarchie bleibt damit ein vom Betreiber definierter Entscheidungsraum, keine Zwangsroute.

Timeouts, Multicast und Firewall machen den Betreiber zum Entscheider

Weil ICP in der beschriebenen Praxis über UDP läuft, können Antworten ausbleiben. RFC 2187 dokumentiert deshalb einen timeout, nach dessen Ablauf eine Quelle gewählt wird, auch wenn nicht alle erwarteten Antworten eingetroffen sind. Ein timeout ist damit kein Beweis, dass ein Nachbar kein Objekt besitzt. Er ist ein Betriebsmechanismus, um eine Entscheidung trotz unvollständiger Evidenz zu erzwingen. Schon RFC 2186 formuliert den Zweck vorsichtig: Das Ausbleiben einer Antwort kann auf Netz- oder Systemprobleme hindeuten und soll verhindern, dass dieser Nachbar im Moment ausgewählt wird.

Bei Multicast wird die Unsicherheit größer. Caches können ICP-query an eine Multicast-Adresse schicken; Gruppenmitglieder können darauf antworten. RFC 2187 betont jedoch, dass die Zahl der erwarteten Antworten nicht exakt bekannt ist und in Squid aus Beobachtungen geschätzt wurde. Vor allem ist multicast membership keine Vertrauensbeziehung. Der Text warnt ausdrücklich davor, jeden antwortenden Cache automatisch zu vertrauen: Der Empfänger soll nur Antworten von explizit konfigurierten Nachbarn akzeptieren. Der Beitritt zu einer Multicast-Gruppe erfordert nach der RFC keine besondere Berechtigung.

Auch sicherheitlich gilt die Grenze. ICPv2 besitzt laut RFC 2187 keine Authentifizierungsfelder. Die beschriebene erste Verteidigungslinie ist die Prüfung der Quelladresse und das Ignorieren von Antworten unbekannter Adressen; zugleich erkennt die RFC die Anfälligkeit für IP-Spoofing an. Ein bekanntes neighbor label oder eine passende Quelladresse ist daher keine kryptografisch authentifizierte identity. Weil ICP_OP_HIT_OBJ Objektdaten tragen kann, behandelt die RFC manipulierte Antworten zudem als Cache-Poisoning-Risiko.

Die Firewall verändert schließlich den verfügbaren Entscheidungsraum. Kann ein Cache den origin nicht direkt erreichen, muss er bei fehlenden ICP-Antworten möglicherweise einen parent anhand von Konfiguration statt anhand eines aktuellen HIT wählen. Damit wird Fallback sichtbar als Policy-Entscheidung: Nicht das Protokoll „entdeckt“ automatisch die einzig richtige Route; der Betreiber legt fest, welche Wege überhaupt zulässig und welche Ersatzentscheidungen akzeptabel sind.

Was RFC 2187 gerade nicht belegt

Aus der Dokumentation lassen sich deshalb klare Evidenzgrenzen ziehen. Ein neighbor label belegt eine konfigurierte Beziehung, nicht zwingend eine symmetrische Policy. Ein HIT belegt eine lokale Cache-Aussage zu diesem Zeitpunkt, nicht vollständige HTTP-Semantik oder garantierte delivery. Ein weight belegt eine Präferenz im Auswahlverfahren, nicht niedrigste objektive costs. Ein gemessener delay oder RTT belegt eine Messung einer begrenzten Strecke oder Phase, nicht automatisch die schnellste End-to-End-Übertragung. Multicast membership belegt Empfangsmöglichkeiten, nicht Autorisierung.

Ein zurückgegebenes object belegt Datenübermittlung, nicht sicheren content. Ein erfolgreicher fetch belegt, dass ein Abruf funktioniert hat, nicht künftige capacity oder ein business outcome.

Diese Grenzen passen zu der späteren Problemaufnahme in RFC 3143. Cache-Meshes können unter wechselnden Pfaden sogar dazu führen, dass ein Nutzer ältere Inhalte erhält als bei einer früheren Anfrage. Die RFC warnt außerdem vor Skalierungs- und Peer-Selection-Problemen. Erfolg auf einer einzelnen Transaktionsebene ist daher keine belastbare Aussage darüber, wie ein ganzes Mesh unter Last, bei wechselnden Inhalten oder über längere Zeit funktioniert.

Drei Dokumente, drei Ebenen

Für die historische Einordnung sollten drei Ebenen nicht vermischt werden. RFC 2186 ist das Informational-Dokument zum Format von ICPv2: Header, Felder, Optionen und opcodes. RFC 2187 ist ebenfalls Informational und dokumentiert die praktische Anwendung von ICPv2 auf Web-Caching, einschließlich Hierarchie, peer selection, Firewall, Multicast und Security. Beide spezifizieren laut ihrem Status keinen Internet Standard.

RFC 9211 gehört in eine andere Epoche und auf eine andere Ebene. Der Standards-Track-Text definiert den HTTP-Response-Header Cache-Status, mit dem Caches sichtbar machen können, wie sie eine konkrete Anfrage behandelt haben. Ein hit bedeutet dort, dass die Anfrage vom Cache befriedigt und nicht weitergeleitet wurde; fwd kann Gründe für das Weiterleiten angeben. Das ist delivery observability entlang einer HTTP-Antwort, nicht die parent/sibling-Autorisierung von ICP. Auch Cache-Status bleibt beobachtende Metadaten: Die RFC macht die Parameter optional und weist auf Sicherheitsrisiken hin, wenn Cache-Verhalten offengelegt wird.

Ebenso wenig sollte RFC 2187 als Quelle für moderne CDN-Ökonomie gelesen werden. Die zugelassenen Primärquellen liefern keine Grundlage für heutige CDN-Vertragsmodelle, Preise, Marktstrukturen oder Erfolgsmetriken. Dasselbe gilt für allgemeines cache-control: RFC 2187 ist gerade deshalb interessant, weil sie festhält, dass ICP die reichere HTTP-Cache-Semantik nicht vollständig transportiert. Wer diese Ebenen vermischt, macht aus einem lokalen Auswahlhinweis mehr, als das Protokoll hergibt.