Website-Optimierung per Caching
Kommentare

Zwei wichtige Eigenschaften des Expire-Headers: Die Zeit wird immer in Greenwich Mean Time (GMT) angegeben und als einzige gültige Zeitangabe existiert das HTTP-Date-Format. Zum Beispiel: Expires: Fri,

Zwei wichtige Eigenschaften des Expire-Headers: Die Zeit wird immer in Greenwich Mean Time (GMT) angegeben und als einzige gültige Zeitangabe existiert das HTTP-Date-Format. Zum Beispiel: Expires: Fri, 30 Oct 2009 19:00:00 GMT. Hier erkennen wir eine Einschränkung des Expire-Headers. Der Einsatz setzt voraus, dass das Ursprungs- und Caching-System synchron sind. Das heisst, dass die Zeiten auf beiden Systemen identisch sind, ansonsten würde es zu falschen Annahmen über die Aktualität eines Inhalts kommen und dadurch geplante Änderungen (z. B. der tägliche geänderte News-Bereich) nicht zur geplanten Zeit aktiv werden. Zur Lösung dieses Problems wird empfohlen, alle beteiligten Systeme über das Network Time Protocol (NTP) (4) zu synchronisieren. Das „Validierung“-Modell beschreibt die Verwendung eines Inhalts in einem Cache nach der Validierung mit dem Ursprungsserver. Dafür muss immer ein Request aufgebaut werden. Zur Validierung gibt es so genannte Cache-Validator-Header. Einer dieser Header ist Last-Modified. Er beschreibt, wann der angefragte Inhalt das letzte Mal modifiziert wurde. Der andere ist der Entity-Tag-Header. Er beinhaltet einen Hash-Wert einer Seite, wie im Abschnitt zum Browser-Cache beschrieben.

Beide Header sollten vom Ursprungsserver gesendet werden. Allerdings hat dies auch die schon im Abschnitt Browser-Cache genannten Nachteile. Eine Lösung ist die Verwendung des Entity Tags für Inhalte, die sich öfter ändern. Weitere wichtige HTTP-1.1-Header sind die Cache-Control-Header. Mit ihnen wird das Verhalten eines Caches gesteuert. Sie sind für HTTP-1.0-Caches nicht verfügbar. Stellt der Reverse Proxy fest, dass ein angefragter Inhalt nicht mehr aktuell ist, wird er als stale markiert und muss überprüft werden. Das heißt, der Reverse Proxy baut eine Verbindung zum Ursprungsserver auf und erfragt die Gültigkeit.

Parameter Funktion
Cache-Control: max-age Definiert die maximale Zeit, die ein Inhalt als aktuell gilt. Allerdings ist die Angabe relativ zum Request in Sekunden.
Cache-Control: min-fresh Wird vom Browser gesendet und bedeutet dem Cache, eine Antwort nur dann zu liefern, wenn sie aktuell genug ist.
Cache-Control: s-max-age Funktioniert genau wie max-age, nur dass er nur für shared caches (zum Beispiel Proxies) gilt.
Cache-Control: public Markiert authentifizierte Antworten als cachebar, auch wenn diese normalerweise nicht gecacht würden.
Cache-Control: private Bedeutet, dass eine Antwort nicht von einem Shared Cache gespeichert werden darf, wohl aber vom Browser-Cache.
Cache-Control: no-cache Wird eingesetzt, um sicherzustellen, dass ein Request zur Validierung an den Ursprungsserver weitergereicht wird.
Cache-Control: no-store Bedeutet für eine Cache: Nicht cachen. Niemals.
Cache-Control: must-revalidate Wird vom Ursprungsserver gesendet und bedeutet für einen Cache, dass er die Anfragen nach diesem Inhalt immer vom Ursprungsserver validieren lassen muss.
Cache-Control: proxy-revalidate Bedeutet das Gleiche wie must-revalidate, allerdings nur für Shared Caches.
Cache-Control: stale-while-revalidate Wird eingesetzt, um hochfrequente Webseiten vor zu vielen Concurrent Requests zu schützen. Es ist nicht Teil des offiziellen RFCs, wird aber von den neueren Proxy Servern (Squid, Varnish) unterstützt.
Cache-Control: stale-while-error Mit diesem Header kann einem Proxy Cache beigebracht werden, im Fall eines 5xx einen alten Inhalt auszuliefern. Er ist auch nicht Teil des RFCs, wird aber ebenfalls von Squid und Varnish unterstützt.

Auf hochfrequentierten Webseiten ergibt sich hier ein Problem: Viele Anfragen werden bei einem stale auf einmal an den Ursprungsserver weitergeleitet. Das heißt, dass die Anzahl der Concurrent Requests schlagartig steigt. Natürlich sollte die Applikation so aufgebaut sein, dass auch diese Anfragen kein Problem darstellen, aber man kann auch über einen schönen Trick eine „BruteForce“-Attacke verhindern. Der Trick heißt: Stale-While-Revalidate und stellt sicher, dass vom Reverse Proxy so lange die alte Version einer Seite ausgeliefert wird, bis ein neuer Inhalt als aktuell im Cache des Proxies existiert. Dies hat natürlich den Nachteil, dass man sich abhängig von einem Proxy macht und kann im Fall eines Ausfalls dazu führen, dass die Webseite die Anfragen nicht mehr verarbeiten kann. Daher ist ein Proxy immer nur zur Performanceverbesserung einzusetzen, nicht aber zum Auffangen einer schlechten Applikationsarchitektur, die ohne ausgedehntes Caching nicht in der Lage ist, eine Webseite auszuliefern.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -