Quelltext der Seite Browser-Cache

'''Browser-Cache''' [{{IPA|ˈbɹaʊ̯zə(ɹ) kæʃ}}] ist ein [[Cache|Puffer-Speicher]] des [[Webbrowser]]s, in dem bereits abgerufene Ressourcen (z.&nbsp;B. Texte oder Bilder) auf dem Rechner des Benutzers (lokal) als Kopie aufbewahrt werden. Wird eine Ressource später erneut benötigt, ist sie aus dem Cache schneller abrufbar, als wenn sie erneut aus dem [[World Wide Web]] heruntergeladen werden müsste.

Jedes Mal, wenn für die Darstellung einer Seite die Inhalte zu einer [[Uniform Resource Locator|URL]] benötigt werden, wird zuerst im Cache nachgesehen, ob diese bereits vorhanden sind.

Vorteilhaft ist, dass Netzwerkverkehr und die Zeit zum Herunterladen aller Bestandteile einer Webseite stark reduziert werden. Nachteilig ist, dass die im Cache gespeicherten Daten veraltet sein können, wenn die Webseite zwischenzeitlich aktualisiert wurde.

== Einsatzgebiete ==
„Ressource“ ist alles, was über eine bestimmte URL abgerufen werden kann. Zu verschiedenen Zeiten können unter derselben URL unterschiedliche Inhalte vorhanden sein. Im Cache wird jeder URL der zuletzt bekanntgewordene Inhalt zugeordnet.

Das gleiche Konzept für einen Browser-Cache auf dem [[Personal Computer|PC]] eines Benutzers wird auch von sogenannten [[Proxy (Rechnernetz)|Proxy-Servern]] für ganze [[Rechnernetz]]e genutzt, etwa für einen Firmenstandort oder eine Universität an der Verbindungsstelle zum Internet oder aber für alle Kunden eines (physischen) [[Internetdienstanbieter#Internetzugang (Konnektivität, Verbindung zum Internet)|Telekommunikationsanbieters]] in einem Versorgungsbereich. Sie liefern allen angeschlossenen Teilnehmern dieses Netzwerks häufig gefragte Dateien direkt, ohne erst das eigentliche Internet durchlaufen zu müssen.

Caching kommt grundsätzlich für jedes [[Uniform Resource Locator#Schema (scheme)|Protokoll]] in Frage, das Ressourcen abrufbar macht. Praktisch wird es aber nur für [[Hypertext Transfer Protocol|HTTP]]/[[Hypertext Transfer Protocol Secure|HTTPS]] benutzt. Wer mit dem Browser über [[File Transfer Protocol|FTP]] einen [[Herunterladen|Datei-Download]] anfordert, wird in diesem Moment eine frische Version erhalten; allerdings könnte ein Proxy-Server Kopien häufig gewünschter Dateien vorhalten. <code>mailto:</code> verschickt Daten und ruft sie nicht ab. Andere Protokolle für Ressourcen bieten keine besondere Unterstützung für das Versionsmanagement und sind heute auch kaum noch gebräuchlich.

== Benutzerkontrolle ==
Bei einem Browser haben Benutzer allgemein folgende Möglichkeiten, über Konfigurationseinstellungen oder interaktiv das Verhalten des Cache zu beeinflussen:

* Maximalgröße des Festplattenspeicherplatzes festlegen; bei null erfolgt kein Caching.
* Aktuelle Seite neu vom Server abrufen (beträfe die in der Adresszeile sichtbare URL; Einzelseite, oder eine Grafik).
* Aktuelle Seite und alle darin eingebundenen Ressourcen (Bilder, Skripte, Stile usw.) neu abrufen (beträfe meist nur [[HTML-Seite]]n).
* Gesamten Cache leeren, möglicherweise auch selektiv nur für alle Ressourcen einer bestimmten [[Domain (Internet)|Domain]] (der aktuellen Seite).
* Am Ende (oder ersatzweise zu Beginn) jeder Sitzung den gesamten Cache leeren.
* Höchstalter für Ressourcen festlegen.

== Cache-Verwaltung ==

Es gelten folgende Grundsätze auf Seiten der Browser oder Proxy-Server:

* Kein System ist verpflichtet, irgendwelche Hinweise des Ursprungs der Ressource zu beachten.
* Im Interesse eines attraktiven Angebots sind die Entwickler von Browsern interessiert, Informationen zum Cache Management auszuwerten, um die Seiten sowohl schnell als auch auf aktuellem Stand darzustellen.

Umfangreiche Anregungen wurden schon 1997 in <nowiki>RFC&nbsp;2068</nowiki><ref>{{RFC-Internet |RFC=2068 |Titel=Hypertext Transfer Protocol – HTTP/1.1 |Datum=1997-01}}</ref> und 1999 in <nowiki>RFC&nbsp;2616</nowiki><ref>{{RFC-Internet |RFC=2616 |Titel=HTTP 1.1 |Datum=1999}}</ref> gegeben, müssen aber nicht vollständig umgesetzt sein.

=== Webserver ===
Ein Webserver sollte zu jeder einzelnen Ressource Cache-Informationen ([[Metadaten]]) mitliefern, um dem Benutzer eine aktuelle Darstellung zu gewährleisten und möglichst geringen Kommunikationsaufwand für Benutzer wie Server zu erreichen.

Der Betreiber des Webservers profitiert davon, dass er nicht ständig Abfragen nach unveränderten Ressourcen beantworten und dafür Rechner- und Netzwerkkapazität aufwenden muss.

Um die Häufigkeit besuchter Seiten und Informationen über die Leser zu erhalten, verwendet man hingegen sehr kleine eingebettete [[Zählpixel|Schnipsel]], bei denen man die Aufnahme in den Cache geeignet verhindert und ein erneutes Abrufen bei jedem Darstellen der Seite erzwingt.

=== Versionsidentifikation ===
Zum Cache Management wird für jede einzelne Ressource wahlweise einer von zwei Identifizierern verwendet, sofern vom Server beigefügt:

; Timestamp
: Banaler [[Zeitstempel]] in [[Koordinierte Weltzeit|UTC]]
: [[Liste der HTTP-Headerfelder|Feld]]: <code>Last-Modified</code>
; [[HTTP ETag|ETag]]<ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.19}}</ref>
: Unterscheidung inhaltlich wesentlich verschiedener Versionen einer Ressource.<br />Kann grundsätzlich auch ein Timestamp sein; jedoch etwa auch eine fortlaufend gezählte Versionsnummer oder ein [[Hashfunktion|Hashcode]].
: Feld: <code>ETag</code>

Fehlen derartige Informationen, dann kennt das Cache Management nur den Zeitpunkt des letzten erfolgreichen Abrufs.

=== Methoden ===
Folgende Methoden stehen zur Verfügung:

; [[Heuristik|Heuristische]] Schätzungen
: Das Cache Management bestimmt nach eigenen [[Algorithmus|Algorithmen]], welche Ressource verbleiben sollen und welche zu entfernen sind. Dies wird insbesondere angewendet, wenn der Ressource keine entsprechenden Informationen mitgegeben wurden.
:* Ressourcen unbegrenzt belassen, wenn der zugelassene Festplattenspeicherplatz ausreicht; erst bei Platzproblemen geeignet löschen.
:* Ressourcen, die vor kurzer Zeit benutzt wurden, könnten vielleicht bald wieder benötigt werden. Lange Zeit nicht angesprochene Ressourcen sind zu löschen.
:* Ressourcen, die häufig angesprochen werden, sollen behalten werden. Selten und lange Zeit nicht gefragte Ressourcen sind zu löschen.
:* Dateigröße – sehr große, lange Zeit nicht und insgesamt selten benötigte Ressourcen zuerst löschen; dafür viele kleine Ressourcen eher belassen.
:* Stabilität – mehrfach veränderte Inhalte sind Löschkandidaten. Über Jahre und mehrere Gültigkeitsprüfungen hinweg unveränderte Ressourcen sollten behalten werden, wenn sie öfters benutzt werden. Kurze Restlaufzeiten sind ein Indiz für Volatilität, wenn auch das momentane Überschreiten der Mindesthaltbarkeit nicht zwangsläufig die Unbrauchbarkeit bedeuten muss.
:* [[Hypertext Transfer Protocol#HTTP-Anfragemethoden|POST]]-Daten zusätzlich zur URL führen in aller Regel dazu, dass derartige Seiten nicht wiederholbar abgerufen werden können, und werden üblicherweise nicht im Cache abgelegt. Dies wäre auch recht gefährlich, weil derartige Informationen oft den Inhalt der Zielseite verändern und eine notwendige Bestätigung an den Server nicht abgeschickt werden würde.
:* Wird in der URL am <code>?</code> eine [[Query-String|Query]] erkannt (etwa bei einer Datenbankabfrage), hatten Algorithmen ursprünglich von der Speicherung abgesehen, weil durch Kombination der Abfrageparameter viele unterschiedliche URL ohne eine Wiederverwendung zustande kamen. Zunehmend werden aber von [[Content-Management-System|CMS]] alle Seiten statisch in diesem URL-Format präsentiert, so dass diese Annahme nicht mehr verlässlich ist.
; „Verfallsdatum“{{Anker|Ablaufdatum}}
: Die Ressource ist mit einem Ablaufdatum (Zeitpunkt) versehen oder aber einem Haltbarkeitszeitraum nach Abruf (etwa: „drei Tage“), aus dem der Zeitpunkt der Ungültigkeit berechnet werden kann.<ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=13.2.4}}</ref>
:* Felder:
::* <code>Expires:</code><ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.21}}</ref> mit einem konkreten Zeitpunkt und
::* <code>Cache-Control: max-age=</code><ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.9.3}} {{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.9.4}}</ref> in Sekunden als relative Angabe<ref><code>&max-age=</code> – Manche Webserver senden auf einen URL-Parameter wie diesen hin in der Antwort das entsprechende Feld <code>Cache-Control</code>.</ref>
:: ''Beispiel:'' Wetterbericht; immer gültig für die folgenden 15 Minuten.
:* Die Ungültigkeit der Ressource bewirkt aber nicht zwangsläufig die Löschung aus dem Cache, sondern lediglich eine Überprüfung der Gültigkeit, was zu einer Verlängerung der Gültigkeitsperiode bei unverändertem Inhalt führen kann.
:* Liegt der als <code>Expires</code> angegebene Zeitpunkt im Moment der Abfrage bereits in der Vergangenheit, kann diese Version nicht in den Cache aufgenommen werden; Angaben zu dieser URL wären zu löschen.
:* Fehlen Angaben des Servers zur Gültigkeitsperiode, kann aus dem Zeitpunkt der letzten Änderung, notfalls aus dem durch das Caching aufgezeichneten Verhalten geschlossen werden, ob sich die Ressource häufig ändert oder konstant ist: Wurde zuletzt vor drei Jahren verändert, ist die Ressource wohl recht stabil; ist sie gerade eine Viertelstunde alt oder hat sie sich während des letzten Tages zweimal geändert, wäre sie kurzfristig auf Aktualität zu überprüfen. Wie genau das Cache Management adäquat mit fehlenden Meta-Informationen umgeht, bleibt der Intelligenz der Programmierer überlassen. Plump und Zeit wie Netzwerkkapazität fressend wäre es, bei fehlenden Angaben eine große Datei jedes Mal neu vom Webserver abzurufen.
:* In der Benutzerkonfiguration könnte ein Höchstalter angegeben worden sein, etwa zwei Wochen.
; No-Cache<ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.9.1}}</ref>{{Anker|No-Cache}}
: Eine Ressource gibt bekannt, dass sie nicht im Cache gehalten werden soll und bei jedem Seitenaufbau frisch vom Server abzurufen ist.
:: Felder:
::* <code>Cache-Control: no-cache</code>
::* <code>Cache-Control: max-age=0</code>
:: Traditionell werden diese beiden Felder gleichzeitig übermittelt, obwohl redundant – in der Hoffnung, dass der Browser wenigstens eines davon verstehen möge. Kombiniert wird das gern noch mit dem „Verfallsdatum“ 1.&nbsp;Januar 1970; auch dies hätte die gleiche Wirkung.
:: ''Beispiel:'' [[Börsenkurs]]e; ändern sich mit jeder Sekunde.
:: Präziser: Bei  <code>Cache-Control: no-cache</code> wäre es einem Browser erlaubt, die Ressource im Cache zu halten; er müsste sich aber vor jedem Zugriff durch Rückfrage beim Server vergewissern, dass sie noch aktuell wäre. Es ist in das freie Ermessen der Browser-Implementierer gestellt, dies so zu handhaben oder solch absehbar schnell veraltende Informationen gar nicht erst in den Cache aufzunehmen.
: In der Wirkung beim Leser und in der vom Anbieter gewünschten Darstellung unterscheidet sich das nicht.
; Versionsvergleich{{Anker|Versionsvergleich}}
: Der Browser vermutet anhand eines Ablaufzeitpunkts, dass die momentan im Cache vorhandene Ressource veraltet sein könnte (englisch: ''stale'' ‚abgestanden, schal‘). Es gibt dann zwei Möglichkeiten:
:* Die kurze [[Hypertext Transfer Protocol#HTTP-Anfragemethoden|HEAD]]-Information der Ressource beim Server abfragen (zunächst ohne den vollständigen Inhalt), das Ergebnis selbst auswerten und dann ggf. auch den Inhalt abfordern (GET).
:* Die bekannten Versionsinformationen (Last-Modified/ETag) an den Server senden. Der Server antwortet entweder mit dem [[HTTP-Statuscode]] <code>304 Not Modified</code> (die Version ist noch gültig) oder sendet eine neue Version (<code>200 OK</code>) – schlimmstenfalls nunmehr <code>404 Not Found</code>.
; Invalidation<ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=13.10}}</ref>
: Wird zu einer URL später eine der relativ selten vorkommenden POST-, PUT- oder DELETE-[[HTTP-Request#HTTP-Anfragemethoden|HTTP-Request-Methode]] festgestellt, wie sie bei Formularen oder [[WebDAV]] benutzt werden, müsste der Eintrag zu dieser URL aus dem Cache gelöscht werden, weil dadurch diese Ressource auf dem Server verändert worden sein kann.
; No-Store<ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.9.2}}</ref>{{Anker|No-Store}}
: Standardmäßig wird jede erfolgreich übertragene Ressource als einzelne Datei auf der Festplatte abgelegt. Bricht die Übertragung zusammen oder stürzt gar der Rechner ab, kann der Seitenaufbau mit den Zwischenergebnissen fortgesetzt werden. In den Anfangsjahren der Browser war der reale [[Arbeitsspeicher|Kernspeicher]] auch begrenzt, die Netzwerke langsam, so dass sich diese Vorgehensweise kaum vermeiden ließ. Das gilt für alle Ressourcen der aktuell dargestellten Seiten, unabhängig von der Verwendung eines Cache.
:* Nach Abschluss der [[HTML-Rendering|Seitendarstellung]] werden diejenigen Dateien, bei denen eine spätere Wiederverwendung möglich erscheint, in die Datenstruktur des Cache übernommen; alle anderen Dateien werden als temporär markiert und zu gegebener Zeit gelöscht.
:* Bei besonders sensiblen Ressourcen (etwa Finanztransaktionen, Kontodaten) könnten Spuren auf der Festplatte zurückbleiben; etwa weil das „Löschen“ einer Datei nur die Entfernung aus dem sichtbaren [[Dateisystem]] bedeutet, nicht aber sofort das physische Überschreiben. Stürzt der Browser oder der Rechner ab, könnten Dateien zurückbleiben; auch nach scheinbarer Löschung könnte die physische Festplatte noch sensible Informationen enthalten, die bei Anmeldung auf dem fraglichen Benutzerkonto noch lesbar wären.
:* Mit <code>Cache-Control: no-store</code> markierte Ressourcen ''soll'' ein Browser nicht auf die Festplatte zwischenspeichern, sondern nur volatil im Kernspeicher halten.
:* Das Konzept hat allerdings eine Lücke: Nur selten bietet das Betriebssystem einer Anwendung die Möglichkeit, Kernspeicher anzufordern, der zugesichert nicht in die [[Auslagerungsdatei|Speicherungsauslagerungsdatei]] auf der Festplatte ausgelagert wird.

== Sicherheitsaspekte ==
Der Cache eines Benutzers lässt Rückschlüsse zu, welche Themen aufgerufen werden.

* Ein Benutzer sollte auf seinem Rechner einen individualisierten Cache verwenden; für jedes Benutzerkonto also ein eigener und vor dem Lesen durch andere Benutzer geschützter Bereich.
** Etwa 2000/2005 wurden die bis dahin gebräuchlichen zentralen Cache-Verzeichnisse, die von allen Benutzern eines PCs gemeinsam benutzt wurden und auch von jedem Benutzer gelesen werden konnten, durch individualisierte Cache ersetzt, deren Zugriffsrechte auf den beim Betriebssystem angemeldeten Benutzer begrenzt sind, und die auch jeweils auf ein Benutzerprofil des Browsers beschränkt sind.
** Die meisten Browser kennen einen „Privat-Modus“. Hierbei wird unter anderem eine zusätzliche Cache-Datenstruktur aufgebaut, die alle jetzt abgerufenen Ressourcen aufnimmt. Der „normale“ Cache kann ggf. parallel lesend benutzt werden, es dürfen dort aber keine Informationen geschrieben werden. Mit Ende des Privat-Modus wird der zusätzliche Cache gelöscht.
* [[Proxy (Rechnernetz)|Proxy]]-Server, über die offen kommuniziert wird, speichern für alle Benutzer des Netzwerks die von ihnen genutzten Seiten und die Zugriffsstatistik.
* Über [[Hypertext Transfer Protocol Secure|HTTPS]] abgerufene URL lassen sich auf Proxy-Servern nicht speichern, die zugehörigen Inhalte und sogar URL-Pfade sind verschlüsselt.
** HTTPS hat hingegen keinen Einfluss auf das Caching beim anfordernden Einzelbenutzer, der die URL und entschlüsselten Inhalte ja kennt. Allerdings gibt es bei manchen Browsern eine individuelle Konfigurationseinstellung,<!-- IE: Einstellungen; FF: about:config   browser.cache.disk_cache_ssl=true --> nach der über HTTPS abgerufene Informationen nicht im Cache abgelegt werden sollen. Durch die starke Verbreitung von HTTPS auch für drahtlose Verbindungen lässt die Verwendung dieses Protokolls aber kaum noch einen Rückschluss auf einen besonderen Geheimhaltungsbedarf der damit übertragenen Seiten zu.
* Die Server-Antwort <code>Cache-Control: private</code> soll bewirken, dass diese Ressource nur in dem individualisierten Cache eines Benutzers gespeichert werden darf, nicht aber auf Proxy-Servern oder geteiltem Browser-Cache.

== Proxy-Server ==
Einige Felder richten sich speziell an Proxy-Server, also beliebige Zwischenstationen zwischen dem Browser und dem Server mit dem eigentlichen Ursprung der Daten. Die Zwischenstellen können auf „geteiltem Cache“ für alle Teilnehmer des Netzwerks (oder Benutzer des Computers) häufiger abgefragte Ressourcen bereithalten.

; Felder in der Ressource:
:* <code>Cache-Control: s-maxage=</code>''nSeconds''<ref>{{RFC-Internet |RFC=2616 |Titel=- |Abschnitt=14.9.3}}</ref><br />Wie <code>max-age</code>, jedoch nur auf geteiltem (“s”=“shared”) Cache.
:* <code>Cache-Control: private</code><br />Nicht auf geteiltem Cache speichern.
:* <code>Cache-Control: public</code><br />Explizit freigegeben zur Speicherung auf geteiltem Cache.
; Ein Browser kann in seiner Anfrage übermitteln:
: <code>Pragma: no-cache</code><br />Ein unterwegs angetroffener Proxy-Server soll die Anfrage zum Ursprung durchreichen und nicht aus seinem Cache beantworten. Auch wird empfohlen, die Ressource zu dieser URL bereits als überholt (Mindesthaltbarkeit abgelaufen) zu markieren, da offenkundig Zweifel an der Aktualität aufgetreten sind.

== HTTP-Caching ==
Zusammengefasst beeinflussen vor allem folgende [[Liste der HTTP-Headerfelder|Felder des HTTP]] das Caching – falls vom Webserver geliefert oder die Grundlage geschaffen wurde:

; Webserver:
:* [[#Versionsidentifikation|<code>Last-Modified:</code>]] timestamp
:* [[#Versionsidentifikation|<code>ETag:</code>]] version
:* [[#Ablaufdatum|<code>Expires:</code>]] timestamp
:* <code>Cache-Control:</code>
:** [[#Ablaufdatum|<code>max-age</code>]]
:** <code>must-revalidate</code>
:** [[#No-Cache|<code>no-cache</code>]]
:** [[#No-Store|<code>no-store</code>]]
:** [[#Sicherheitsaspekte|<code>private</code>]]
:** <code>public</code>
:** [[#Proxy-Server|<code>s-maxage</code>]]
:** ''… und weitere''
:* <code>Vary</code>
; Browser-Anfrage:
:* [[#Versionsvergleich|<code>If-Modified-Since</code>]] &nbsp; ''für Last-Modified''
:* [[#Versionsvergleich|<code>If-None-Match</code>]] &nbsp; ''für ETag''
:* <code>Pragma: no-cache</code> &nbsp; ''[[#Proxy-Server|Proxy-Server umgehen]]''

Die gleichen Informationen, die ein Webserver zusätzlich zum Inhalt übermittelt, können auch in ein [[Hypertext Markup Language|HTML]]-Dokument integriert werden<ref>[https://www.w3.org/TR/REC-html40/struct/global.html#edef-META HTML.4]</ref> und die Standard-Angaben des Servers ggf. überschreiben:

<syntaxhighlight lang="html">
   <meta http-equiv="Last-Modified" content="..." />
</syntaxhighlight>

== Weblinks ==
* [https://www.browser-cache.de/ Anleitung zum Leeren des Caches gängiger Browser.] browser-cache.de
* [https://clear-my-browser-cache.com/ Anleitung zum Leeren des Caches gängiger Browser.] clear-my-browser-cache.com
* {{RFC-Internet |RFC=2616 |Titel=HTTP 1.1 |Datum=1999 |Kommentar=insbesondere Abschnitte 13 und 14; grundlegende Techniken für die Browser-Entwicklung}}
* [[Hilfe:Cache]] – zur Caching-Problematik in der Wikipedia
* [http://bitsup.blogspot.com/2016/05/cache-control-immutable.html Cache-Control: immutable]

== Einzelnachweise und Anmerkungen ==
<references />

[[Kategorie:Speicherverwaltung]]
[[Kategorie:Webbrowser]]