Zum Hauptinhalt springen

13. Caching in HTTP (Caching in HTTP)

HTTP wird üblicherweise für verteilte Informationssysteme verwendet, bei denen die Leistung durch die Verwendung von Antwort-Caches verbessert werden kann. Das HTTP/1.1-Protokoll enthält viele Elemente, die darauf ausgelegt sind, das Caching so gut wie möglich funktionieren zu lassen. Die Ziele des Cachings in HTTP/1.1 bestehen darin, in vielen Fällen das Senden von Anfragen zu eliminieren und in vielen anderen Fällen das Senden vollständiger Antworten zu eliminieren. Ersteres reduziert die Anzahl der für viele Operationen erforderlichen Netzwerkumleitungen; wir verwenden einen "Ablauf"-Mechanismus (expiration) für diesen Zweck (siehe Abschnitt 13.2). Letzteres reduziert die Netzwerkbandbreitenanforderungen; wir verwenden einen "Validierungs"-Mechanismus (validation) für diesen Zweck (siehe Abschnitt 13.3).

Das HTTP/1.1-Protokoll bietet die folgenden wichtigen Elemente:

  1. Protokollfunktionen, die vollständige semantische Transparenz bieten, wenn alle Parteien sie benötigen
  2. Protokollfunktionen, die es dem Ursprungsserver oder Benutzeragenten ermöglichen, nicht-transparente Operationen explizit anzufordern und zu steuern
  3. Protokollfunktionen, die es dem Cache ermöglichen, Warnungen an Antworten anzuhängen, die die angeforderte Annäherung an semantische Transparenz nicht beibehalten

13.1.1 Cache Correctness (Cache-Korrektheit)​

Ein korrekter Cache muss (MUST) auf eine Anfrage mit der aktuellsten vom Cache gehaltenen Antwort antworten, die auf die Anfrage anwendbar ist und eine der folgenden Bedingungen erfüllt:

  1. Sie wurde auf Äquivalenz mit dem geprüft, was der Ursprungsserver zurückgeben würde, indem die Antwort beim Ursprungsserver revalidiert wurde (Abschnitt 13.3)

  2. Sie ist "frisch genug" (fresh enough) (siehe Abschnitt 13.2). Standardmäßig bedeutet dies, dass sie die am wenigsten restriktiven Frischeanforderungen des Clients, des Ursprungsservers und des Caches erfüllt (siehe Abschnitt 14.9)

  3. Es ist eine geeignete 304 (Not Modified)-, 305 (Proxy Redirect)- oder Fehler- (4xx oder 5xx) Antwortnachricht

Wenn der Cache nicht mit dem Ursprungsserver kommunizieren kann, sollte (SHOULD) ein korrekter Cache wie oben beschrieben antworten, wenn die Antwort korrekt aus dem Cache bereitgestellt werden kann; andernfalls muss (MUST) er einen Fehler oder eine Warnung zurückgeben, die den Kommunikationsfehler anzeigt.

13.1.2 Warnings (Warnungen)​

Immer wenn ein Cache eine Antwort zurückgibt, die weder aus erster Hand noch "frisch genug" ist, muss (MUST) er eine Warnung zu diesem Effekt unter Verwendung des Warning-General-Headers anhängen. Warnungen werden dreistellige Warncodes zugewiesen:

  • 1xx - Warnung, die den Frische- oder Revalidierungsstatus der Antwort beschreibt und daher nach erfolgreicher Revalidierung gelöscht werden muss
  • 2xx - Warnung, die einen Aspekt des Entitätskörpers oder der Entitätsheader beschreibt, der nicht durch Revalidierung korrigiert wird und daher nach erfolgreicher Revalidierung nicht gelöscht werden darf

13.1.3 Cache-control Mechanisms (Cache-Kontrollmechanismen)​

Die grundlegenden Caching-Mechanismen in HTTP/1.1 (vom Server angegebene Ablaufzeiten und Validatoren) sind implizite Anweisungen an den Cache. Der Cache-Control-Header erlaubt es dem Client oder Server, verschiedene Direktiven in einer Anfrage oder Antwort zu übertragen. Diese Direktiven überschreiben normalerweise den Standard-Caching-Algorithmus.

13.1.4 Explicit User Agent Warnings (Explizite Benutzeragenten-Warnungen)​

Viele Benutzeragenten haben Historienlisten-Mechanismen, wie einen "Zurück"-Button und eine Historienliste, die verwendet werden können, um kürzlich vom Benutzer abgerufene Entitäten erneut anzuzeigen. Historienmechanismen und Caches sind unterschiedlich.

13.1.5 Exceptions to the Rules and Warnings (Ausnahmen von den Regeln und Warnungen)​

In bestimmten Situationen wählen Betreiber die Konfiguration von Caches, um veraltete Antworten zurückzugeben, selbst wenn sie nicht den HTTP/1.1-Regeln entsprechen. Solche Situationen umfassen, sind aber nicht beschränkt auf:

  • Rückgabe veralteter Daten, wenn der Ursprungsserver nicht erreichbar ist
  • Wenn Netzwerkverbindungen langsam oder unzuverlässig sind
  • Bereitstellung schnellerer Antwortzeiten während bestimmter Zeiträume

13.1.6 Client-controlled Behavior (Clientgesteuertes Verhalten)​

Benutzeragenten haben typischerweise Historienmechanismen, wie einen Zurück-Button, der verwendet werden kann, um zuvor abgerufene Darstellungen erneut anzuzeigen.

13.2 Expiration Model (Ablaufmodell)​

HTTP-Caches speichern Cache-Einträge normalerweise bis zu dem Zeitpunkt, zu dem sie diese verwenden können, ohne den Ursprungsserver zu fragen. Wir verwenden den Begriff "semantisch transparent", um einen Cache zu beschreiben, wenn seine Verwendung weder für den anfragenden Client noch für den Ursprungsserver sichtbar ist.

13.2.1 Server-Specified Expiration (Vom Server angegebener Ablauf)​

Das HTTP-Cache-Protokoll verwendet explizite Ablaufzeiten, um anzuzeigen, wann eine Antwort veraltet ist. Der Ablaufmechanismus gilt nur für Antworten, die wie folgt definiert sind:

  • Antworten auf 200-, 203-, 206-, 300-, 301- oder 410-Antworten
  • Antworten, für die das Cache-Control-Header-Feld das Caching explizit erlaubt

13.2.2 Heuristic Expiration (Heuristische Ablauf)​

Da Ursprungsserver nicht immer eine explizite Ablaufzeit bereitstellen, weisen HTTP-Caches normalerweise heuristische Ablaufzeiten zu, unter Verwendung von Algorithmen, die andere Headerwerte des Cache-Eintrags verwenden (wie die Last-Modified-Zeit).

13.2.3 Age Calculations (Altersberechnungen)​

Um zu wissen, ob eine Antwort frisch ist, muss der Cache ihr Alter (age) kennen. Der Age-Wert ist eine Schätzung der Zeit, die seit der Generierung oder erfolgreichen Validierung der Antwort vergangen ist.

Altersberechnungsformel:

age_value = now - date_value
apparent_age = max(0, response_time - date_value)
corrected_received_age = max(apparent_age, age_value)
response_delay = response_time - request_time
corrected_initial_age = corrected_received_age + response_delay
resident_time = now - response_time
current_age = corrected_initial_age + resident_time

13.2.4 Expiration Calculations (Ablaufberechnungen)​

Um festzustellen, ob eine Antwort frisch ist, vergleichen wir ihr aktuelles Alter mit ihrer Frischelebensdauer. Eine Antwort ist frisch, wenn ihr Alter ihre Frischelebensdauer nicht überschritten hat.

Frischelebensdauer-Berechnung:

freshness_lifetime = max_age_value
oder
freshness_lifetime = expires_value - date_value
oder
freshness_lifetime = (now - last_modified_value) * 0.1

13.2.5 Disambiguating Expiration Values (Klärung von Ablaufwerten)​

Da der Vergleich zwischen Ablaufzeiten und aktueller Zeit empfindlich auf Uhrversatz reagiert, sollten Implementierungen die konservativste Ablaufzeit verwenden.

13.2.6 Disambiguating Multiple Responses (Klärung mehrerer Antworten)​

Da Clients möglicherweise über mehrere Pfade auf Ressourcen zugreifen, können Caches mehrere Antworten für dieselbe Ressource empfangen. Caches sollten die neueste Antwort verwenden.

13.3 Validation Model (Validierungsmodell)​

Wenn ein Cache einen veralteten Cache-Eintrag hat, den er verwenden möchte, muss er zuerst beim Ursprungsserver (oder über einen Cache mit einem frischen Eintrag) prüfen, ob sein Cache-Eintrag noch verwendbar ist. Wir nennen dies "Validierung" des Cache-Eintrags.

13.3.1 Last-Modified Dates (Letzte Änderungsdaten)​

Der Last-Modified-Entitätsheaderfeldwert wird häufig als Cache-Validator verwendet. Normalerweise wird der Last-Modified-Wert des Cache-Eintrags zusammen mit einem If-Modified-Since-Anfrage-Header gesendet.

13.3.2 Entity Tag Cache Validators (Entitäts-Tag-Cache-Validatoren)​

Der ETag-Antwort-Headerfeldwert (Entitäts-Tag) bietet einen "opaken" Cache-Validator. Dies kann eine zuverlässigere Validierung ermöglichen, insbesondere wenn:

  • Änderungsdaten nicht bequem gespeichert werden können
  • Die Einsekundenauflösung des HTTP-Datumswerts des Dokumentänderungsdatums nicht ausreicht
  • Änderungsdaten nicht konsistent sind

13.3.3 Weak and Strong Validators (Schwache und starke Validatoren)​

Da die Ziele des Ursprungsservers und des Caches unterschiedlich sein können, benötigen Clients manchmal nur eine ausreichend gute Antwort, anstatt eine absolut aktuelle Kopie.

  • Starker Validator - ändert sich jedes Mal, wenn sich die Entität ändert, unabhängig davon, ob die Änderung bedeutsam ist
  • Schwacher Validator - kann sich nicht bei jeder Entitätsänderung ändern (Präfix "W/")

13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates (Regeln für die Verwendung von Entitäts-Tags und Last-Modified-Daten)​

HTTP/1.1-Ursprungsserver sollten (SHOULD) wenn möglich Entitäts-Tag-Validatoren senden, anstelle von oder zusätzlich zu Last-Modified-Werten.

13.3.5 Non-validating Conditionals (Nicht-validierende Bedingungen)​

Bedingte Anfragen können auch für andere Zwecke verwendet werden, wie die Optimierung von Anfragen oder die Verhinderung des Verlusts von Aktualisierungen.

13.4 Response Cacheability (Antwort-Cachbarkeit)​

Sofern nicht anders angegeben, sind mit GET abgerufene Antworten cachebar. Die folgenden Regeln definieren, wann eine Antwort cachebar ist:

  1. Die Anfragemethode selbst ist cachebar (GET und HEAD)
  2. Der Antwortstatuscode ist verständlich und cachebar (200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501)
  3. Der Cache-Control-Header zeigt kein Caching-Verbot an
  4. Bei Verwendung eines gemeinsam genutzten Caches erscheint der Authorization-Header nicht, es sei denn, Cache-Control erlaubt es explizit

13.5 Constructing Responses From Caches (Konstruktion von Antworten aus Caches)​

13.5.1 End-to-end and Hop-by-hop Headers (End-to-End- und Hop-by-Hop-Header)​

HTTP-Headerfelder werden in End-to-End-Header und Hop-by-Hop-Header klassifiziert:

  • End-to-End-Header - müssen an den endgültigen Empfänger übertragen werden
  • Hop-by-Hop-Header - haben nur für eine einzelne Transportverbindung Bedeutung

13.5.2 Non-modifiable Headers (Nicht modifizierbare Header)​

Einige Funktionen erfordern möglicherweise, dass der Cache die Header bestimmter Cache-Einträge ändert. Nur End-to-End-Header können geändert werden.

13.5.3 Combining Headers (Kombinieren von Headern)​

Wenn ein Cache eine Antwort auf eine Anfrage validiert und die Antwort einige Headerfelder, aber nicht andere enthält, muss der Cache die neuen Felder mit den Feldern des alten Eintrags kombinieren.

13.5.4 Combining Byte Ranges (Kombinieren von Byte-Bereichen)​

Eine Antwort aus dem Cache kann eine Teilinhaltsantwort sein. In einigen Fällen kann der Cache einen Satz gespeicherter Byte-Bereiche und einen neuen Byte-Bereich kombinieren, um die Anfrage zu erfüllen.

13.6 Caching Negotiated Responses (Caching von verhandelten Antworten)​

Die Verwendung von servergesteuerter Inhaltsverhandlung (Abschnitt 12.1) kann unterschiedliche Antworten basierend auf den Werten bestimmter Headerfelder der Anfrage erstellen. Das Vary-Headerfeld wird verwendet, um anzuzeigen, welche Anfrage-Headerfelder bei der Auswahl verwendet werden.

13.7 Shared and Non-Shared Caches (Gemeinsam genutzte und nicht gemeinsam genutzte Caches)​

Da der Zweck und die Einschränkungen einiger Headerfelder für verschiedene Cache-Typen unterschiedlich sind, unterscheiden wir:

  • Nicht gemeinsam genutzte Caches - Cache, auf den nur ein einzelner Benutzer zugreifen kann (z.B. Benutzeragenten-Cache)
  • Gemeinsam genutzte Caches - Cache, auf den mehrere Benutzer zugreifen können (z.B. Proxy-Cache)

13.8 Errors or Incomplete Response Cache Behavior (Fehler- oder unvollständiges Antwort-Cache-Verhalten)​

Wenn ein Cache eine unvollständige Antwort empfängt (z.B. weniger Content-Length-Bytes als angegeben), kann (MAY) er die unvollständige Antwort speichern. Der Cache muss (MUST) sie jedoch als Teilantwort behandeln.

13.9 Side Effects of GET and HEAD (Nebenwirkungen von GET und HEAD)​

Sofern der Ursprungsserver das Caching der Antwort nicht explizit verbietet, sollten (SHOULD) die Anwendungen der GET- und HEAD-Methoden keine Nebenwirkungen haben.

13.10 Invalidation After Updates or Deletions (Ungültigmachung nach Aktualisierungen oder Löschungen)​

Die erfolgreiche Ausführung einer Methode, die den Zustand ändern würde (POST, PUT, DELETE), muss alle Cache-Einträge für die durch diesen Request-URI identifizierte Ressource ungültig machen.

13.11 Write-Through Mandatory (Durchschreiben obligatorisch)​

Alle Methoden, die zu einer Ressourcenänderung auf dem Ursprungsserver führen, müssen (MUST) zum Ursprungsserver durchschreiben. Die aktuelle Spezifikation definiert keine Möglichkeit, solche Antworten an anderer Stelle zu cachen.

13.12 Cache Replacement (Cache-Ersetzung)​

Wenn ein Cache eine Antwort empfängt, die dazu führen würde, dass ein Eintrag durch einen neueren Eintrag ersetzt wird, und der alte Eintrag Cache-Control-Direktiven enthält, sollte (SHOULD) der Cache diese Direktiven befolgen.

13.13 History Lists (Historienlisten)​

Benutzeragenten haben typischerweise Historienmechanismen, wie einen "Zurück"-Button und eine Historienliste, die verwendet werden können, um zuvor in der Benutzersitzung abgerufene Darstellungen erneut anzuzeigen.

Anforderungen an den Historienmechanismus:

  1. Der Historienmechanismus sollte (SHOULD) zuvor abgerufene Ressourcen gemäß den Benutzerpräferenzen anzeigen
  2. Der Historienmechanismus sollte (SHOULD NOT) nicht versuchen, Ressourcen zu validieren
  3. Der Historienmechanismus sollte (SHOULD) zuvor abgerufene Darstellungen anzeigen, auch wenn sie jetzt abgelaufen sind

Wichtiger Hinweis: Dieses Kapitel beschreibt detailliert die HTTP/1.1-Caching-Mechanismen, einschließlich des Ablaufmodells, des Validierungsmodells, der Cache-Kontrolle und anderer Kernkonzepte. Caching ist ein wichtiger Mechanismus zur Verbesserung der HTTP-Leistung, und das Verständnis dieser Konzepte ist für den Aufbau hochperformanter Webanwendungen unerlässlich.

Letztes Update am