HTTP Caching

Der Datenaustausch über das Internet nimmt täglich und inzwischen im bedenklichen Maße zu. Unmengen von Informationen werden zwischen Server- und Clientsystemen transferiert, ausgewertet und angezeigt. Einen großen Teil davon - für beispielsweise eine statische Webseite - müsste man oftmals aber gar nicht mehrfach übertragen. Jedwede Information, die sich in absehbarer Zeit nicht ändert bzw. nicht sekundengenau aktualisiert werden muss, kann grundsätzlich und auf unterschiedliche Weise zwischengespeichert werden. Dies kann auf dem Clientsystem im Browser oder auch in einem Proxy-Server in der Informationskette vorgenommen werden.

Wenn also eine Bilddatei zu einem Newsbeitrag mit an den Empfänger übertragen wird, so könnte diese zur späteren Anzeige im Browser vorgehalten werden. Eine mehrfache Anzeige auf der Webseite würde dann ungleich schneller erfolgen, da der Browser die „unveränderte“ Datei sofort zur Verfügung hat und diese nicht erneut über das Internet vom Informationsserver angefordert werden muss. Dieses Verfahren ist seit geraumer Zeit bereits üblich und ausreichend im HTTP-Standard als HTTP-Caching definiert.

Die Zwischenspeicherung von Daten und Informationen unterliegt einem festen Schema. Der Datenfluss beginnt dabei mit dem beispielsweisen Aufruf einer Webseite über den Webbrowser. Als Antwort auf die Anfrage erhält der Browser eine bzw. mehrere Antworten vom Server mit entsprechenden Parametern. Beim Übertragen einer Bilddatei wie beispielsweise das Webseitenlogo hat der Header die folgende exemplarische Form:

Anhand dieser Sammlung von Parameter erkennt der Browser nun zuerst einmal eine Bilddatei (content-type: image/jpeg). Die Größe beträgt hier im Beispiel 4.255 Bytes. Im Parameter cache-control: max-age=31536000 wird dem Browser zusätzlich mitgeteilt, dass diese Bilddatei für 1 Jahr (Wert wird in Sekunden angegeben) als aktuell gekennzeichnet ist. Mit den beiden folgenden Parametern date: Thu, 13 Dec 2018 11:53:44 GMT und etag: "109f-57b4155594e55" stehen weitere Kennzeichnungen für das Browser-Caching zur Verfügung. Über date: weiß der Browser jederzeit, wann diese Datei erstmalig angefordert wurde. Mittels dem Parameter etag: wurde der Bilddatei eine eindeutige ID mit auf den Weg gegeben.

Wird diese Bilddatei nun durch einen Seitenrefresh oder einige Tage später sogar erneut aufgerufen, so findet der Browser diese Bilddatei im Browser und kann anhand dieser Parameter entscheiden, ob die Bilddatei noch gültig ist (max-age: und date:) und diese dann sofort aus dem Cache darstellen. Eine erneute Übertragung vom Server fällt damit wirkungsvoll weg. Ist die Bilddatei jedoch bereits veraltet, so muss der Browser diese zwar erneut anfordern, kann die Bilddatei jedoch über die ID aus dem Parameter etag: schnell und eindeutig identifizieren.

Damit ein Client (zumeist der Kundenbrowser) das Zwischenspeichern ordentlich durchführen und steuern kann, werden sogenannte Cache-Direktiven zu jeder Anfrage und Antwort hinzugefügt. Um allen Beteiligten die Möglichkeit der korrekten Bearbeitung einräumen zu können, müssen alle Direktiven zunächst grundsätzlich auch jeweils weitergereicht werden. Grundsätzlich beschreibt HTTP-Caching entsprechende Protokolle für Requests und Responses, die wir im Folgenden als Schnittmenge und auszugsweise kurz beschreiben:

Cache-Request-Direktiven:

Die Cache-Response-Direktiven verwenden die o.g. Request-Direktiven und zusätzlich noch folgende erweiterte Direktiven:

Es existieren noch weitere Kontrolloptionen für das HTTP-Caching, die Sonderfälle und spezielle Anforderungen bedienen. Für eine umfassende Dokumentation und Quellcode-Beispiele bietet das Mozilla Developer-Netzwerk einen optimalen Überblick.

Wie so oft gibt es auch beim HTTP-Caching keine optimale Lösung. Vielmehr ist hier eine gezielte Ablaufkontrolle und Einbindung von Sicherheitsaspekten der erste Schritt. In einem Flowchart sollte der Entwickler vorab festlegen, welche Ressourcen sinnvollerweise „cacheable“ sind und dahingehend eine passende Parametrisierung vornehmen. Weiterhin wäre es wichtig, Ressourcen auch eine ID über den ETag-Parameter zuzuweisen. Somit ist im Falle des Nachladens eine sichere Identifikation und schnelle Auffindbarkeit gewährleistet.

Werden Ressourcen mehrfach mit verschiedenen URLs verwendet, sollte dahingehend eine gewisse Konsistenz forciert werden und Ressourcen besser zentral verwaltet werden (siehe CDN-Netzwerke und -Server). Um größere Downloadkapazitäten zu vermeiden, kann eine Prüfung auf Proxy-Speicherung gute Ergebnisse erzielen. Somit können unterschiedliche Nutzerebenen auf Proxyebene schnell mit gleichbleibenden Ressourcen bedient werden. Nicht weniger wichtig ist auch die strikte Vergabe einer sinnvollen Cache-Lebensdauer für Ressource. So können die Browser auf der Clientseite bereits selbst bestimmen, welche und wie oft Ressourcen nachgeladen werden müssen.