Was sind zwischengespeicherte Daten? Was bedeutet Cache löschen und was macht es?

Was ist ein Cache?

Im Allgemeinen ist ein Cache (ausgesprochen "Bargeld") eine Art Repository. Sie können sich ein Repository als Speicherdepot vorstellen. Beim Militär würde dies bedeuten, Waffen, Lebensmittel und andere Vorräte aufzubewahren, die zur Fortführung einer Mission benötigt werden.

In der Informatik werden diese "Verbrauchsmaterialien" als Ressourcen bezeichnet, wobei die Ressourcen Skripte, Code und Dokumentinhalte sind. Letzteres wird manchmal spezifischer als "Assets" wie Text, statische Daten, Medien und Hyperlinks bezeichnet, aber hier verwende ich nur den Begriff " Ressourcen" .

Die Unterscheidung zwischen einem Cache und anderen Arten von Repositorys

Der Hauptzweck eines Caches besteht darin, das Abrufen von Webseitenressourcen zu beschleunigen und die Ladezeiten der Seiten zu verkürzen. Ein weiterer kritischer Aspekt eines Caches besteht darin, sicherzustellen, dass er relativ frische Daten enthält.

In diesem Artikel werden zwei gängige Methoden zum Zwischenspeichern behandelt: Browser-Zwischenspeichern und Content Delivery Networks (CDNs).

Neben Caches spielen in Webarchitekturen auch andere Repositorys eine Rolle. Oft sind diese so konzipiert, dass sie riesige Datenmengen enthalten. Sie konzentrieren sich jedoch nicht so stark auf die Abrufleistung.

Beispielsweise ist Amazon Glacier ein Datenrepository, mit dem Daten kostengünstig gespeichert, aber nicht schnell abgerufen werden können. Eine SQL-Datenbank hingegen ist flexibel, aktuell und schnell, aber selten billig und normalerweise nicht so schnell wie ein Cache.

Der Browser-Cache: Ein Speicher-Cache

Ein Speichercache speichert Ressourcen lokal auf dem Computer, auf dem der Browser ausgeführt wird. Während der Browser aktiv ist, werden abgerufene Ressourcen im physischen Speicher (RAM) des Computers und möglicherweise auch auf der Festplatte gespeichert.

Wenn später beim erneuten Aufrufen einer Webseite genau dieselben Ressourcen benötigt werden, zieht der Browser diese aus dem Cache anstelle des Remoteservers. Da der Cache lokal im schnellen Speicher gespeichert ist, werden diese Ressourcen schneller abgerufen und die Seite wird schneller geladen.

Die Geschwindigkeit des Ressourcenabrufs ist von entscheidender Bedeutung, aber auch die Notwendigkeit, dass die Ressourcen frisch sind. Eine veraltete Ressource ist veraltet und möglicherweise nicht mehr gültig.

Ein Teil der Aufgabe des Browsers besteht darin, zu identifizieren, welche zwischengespeicherten Ressourcen veraltet sind, und diese erneut abzurufen. Da eine Webseite normalerweise über Ressourcen verfügt, befindet sich normalerweise eine Mischung aus veralteten und neuen Versionen im Cache.

Woher weiß der Browser, was im Cache veraltet ist?

Die Antwort ist nicht einfach, aber es gibt zwei Hauptansätze: Cache-Busting- und HTTP-Header-Felder.

Cache-Busting

Italiener

Cache-Busting ist eine serverseitige Technik, die sicherstellt, dass der Browser nur neue Ressourcen abruft. Dies geschieht indirekt.

Während Cache-Busting dramatisch klingt, macht es wirklich nichts kaputt und berührt nicht einmal das, was bereits in einem Browser zwischengespeichert ist. Alles, was Cache-Busting bewirkt, ist, den URI der ursprünglichen Ressource so zu ändern, dass dem Browser der Eindruck entsteht, dass die Ressource völlig neu ist. Da es neu aussieht, befindet es sich nicht im Cache eines Browsers. Die alte Version der zwischengespeicherten Ressource wird weiterhin zwischengespeichert, verdorrt jedoch und stirbt, sodass nie wieder darauf zugegriffen werden kann.

www.foobar.com/about.htmlAngenommen, ich habe eine Webseite, auf der alles über foobar.com steht, was Sie jemals wissen möchten. Sobald Sie diese Seite besuchen, werden sie und die damit verbundenen Ressourcen vom Browser zwischengespeichert.

Später wird foobar.com von der Quxbaz Corporation aufgekauft, und der Inhalt der About-Seite wird erheblich geändert. Der Cache des Browsers enthält diesen neuen Inhalt nicht, glaubt jedoch möglicherweise, dass der Inhalt aktuell ist, und versucht niemals, ihn erneut abzurufen.

Was tun Sie als Quxbaz-Webadministrator, um sicherzustellen, dass alle neuen Inhalte veröffentlicht werden?

Da sich der Browser auf den URI stützt, um Elemente im Cache zu finden, ist es so, als hätte der Browser ihn nie gesehen, bevor er diese Ressource vom Server abruft, wenn sich der URI einer Ressource ändert.

Durch Ändern des Ressourcen-URI von www.foobar.com/about.htmlnach www.foobar.com/about2.html(oder nach www.quxbaz.com/about.html) findet der Browser keine Cache-Ressource, die diesem URI zugeordnet ist, und führt einen vollständigen Abruf vom Server durch. Die Ressource ist möglicherweise im Wesentlichen dieselbe wie das Original unter der alten URI, aber der Browser weiß das nicht.

Sie müssen den Seitennamen jedoch nicht ändern. Da der URI per Definition auch eine Abfragezeichenfolge enthält, können Sie dem URI einen Versionsparameter hinzufügen : www.foobar.com/about.html?v=2hef9eb1.

In diesem Fall wird der Versionsparameter v bei jeder Änderung des Inhalts auf einen neu generierten Hashwert gesetzt oder durch einen anderen Prozess ausgelöst, z. B. einen Serverneustart. Der Browser stellt fest, dass sich die Abfragezeichenfolge geändert hat. Da Abfragezeichenfolgen Auswirkungen auf die Rückgabe haben können, wird eine aktuelle Ressource vom Server abgerufen.

Keine dieser Techniken funktioniert, wenn auf die alte URI direkt über ein Lesezeichen zugegriffen wird. Sofern der Browser nicht angewiesen wurde, den URI bei der letzten zwischengespeicherten Anforderung erneut zu validieren (oder die zwischengespeicherte Ressource abgelaufen ist), führt er keinen vollständigen Abruf durch, um den Cache zu aktualisieren. Dies bringt uns zum nächsten Thema.

HTTP-Headerfelder

Jede Ressourcenanforderung enthält einige Metainformationen, die als Header bezeichnet werden. Umgekehrt sind jeder Antwort auch Header-Informationen zugeordnet.

In einigen Fällen sieht der Browser die Antwortheaderwerte und ändert die entsprechenden Werte in nachfolgenden Anforderungsheadern. Zu diesen Header-Werten gehören diejenigen, die sich auf die Ausführung des Ressourcen-Caching im Browser auswirken.

HEAD-Anfragen und bedingte Anfragen

Eine HEAD-Anforderung ist wie eine abgeschnittene GET- oder POST-Anforderung. Anstatt die vollständige Ressource anzufordern, fordert eine HEAD-Anforderung nur die Header-Felder an, die andernfalls bei einer vollständigen Anforderung zurückgegeben würden.

Der Header einer Ressource ist im Allgemeinen viel kleiner (in Bezug auf die Anzahl der Gesamtbytes) als die damit verbundenen Ressourcendaten (der "Hauptteil" der Antwort). Die Header-Informationen sind ausreichend informativ, damit der Browser die Aktualität der Ressource in seinem Cache bestimmen kann.

HEAD-Anforderungen werden häufig verwendet, um die Gültigkeit einer Serverressource zu überprüfen (dh ist die Ressource noch vorhanden, und wenn ja, wurde sie seit dem letzten Zugriff des Browsers aktualisiert?). Der Browser verwendet den Inhalt seines Caches, wenn die HEAD-Anforderung angibt, dass die Ressource gültig ist. Andernfalls führt er eine vollständige GET- oder POST-Anforderung durch und aktualisiert den Cache mit den zurückgegebenen Daten.

Bei einer bedingten Anforderung sendet der Browser Felder in der Kopfzeile, die die Aktualität seiner zwischengespeicherten Ressource beschreiben. Diesmal ermittelt der Server, ob der Cache des Browsers noch aktuell ist.

Wenn dies der Fall ist, gibt der Server eine 304-Antwort mit nur den Headerinformationen der Ressource und keinem Ressourcenkörper (den Daten) zurück. Wenn festgestellt wird, dass der Cache des Browsers veraltet ist, gibt der Server eine vollständige Antwort von 200 OK zurück.

Dieser Mechanismus ist schneller als die Verwendung von HEAD-Anforderungen, da nicht mehr zwei Anforderungen anstelle von einer ausgegeben werden müssen.

Das Obige vereinfacht einen ziemlich komplizierten Prozess. Das Caching erfordert eine Menge Feinabstimmung, aber alles wird über Header-Felder gesteuert, von denen das wichtigste die Cache-Steuerung ist.

Cache-Kontrolle

Bei der Beantwortung einer Anfrage sendet der Server Header-Felder an den Browser, die angeben, welches Verhalten beim Caching angepasst werden soll. Wenn ich die Seite bei lade //en.wikipedia.org/wiki/Uniform_Resource_Identifier, enthält die Antwort Folgendes in ihrem Header-Datensatz:

cache-control: private, s-maxage=0, max-age=0, must-revalidate 

privat bedeutet, dass nur der Browser den Dokumentinhalt zwischenspeichern soll.

s-maxage und max-age werden auf 0 gesetzt . Der s-maxage- Wert gilt für Proxyserver mit Caches, während max-age für den Browser vorgesehen ist. Das Festlegen des Maximalalters allein hat zur Folge, dass die zwischengespeicherte Ressource sofort abläuft und dennoch beim erneuten Laden von Seiten in derselben Browsersitzung verwendet werden kann (auch wenn sie veraltet ist).

Eine veraltete Ressource kann eine erneute Validierung durch eine HEAD-Anforderung sein, auf die je nach Antwort eine GET- oder POST-Anforderung folgen kann. Die Anweisung must-revalidate befiehlt dem Browser, die zwischengespeicherte Ressource erneut zu validieren, wenn sie veraltet ist.

Da in diesem Fall das maximale Alter auf 0 gesetzt ist, ist die zwischengespeicherte Ressource nach dem Empfang sofort veraltet. Die Kombination der beiden Anweisungen entspricht der Einzelanweisung ohne Cache .

Die beiden Einstellungen stellen sicher, dass der Browser die zwischengespeicherte Ressource immer erneut überprüft, unabhängig davon, ob sie sich noch in derselben Sitzung befindet oder nicht.

Cache-Steuerungsanweisungen sind sehr umfangreich und manchmal verwirrend - sie sind ein eigenständiges Thema. Eine vollständige dokumentierte Liste der Richtlinien finden Sie hier.

E-Tag

Dies ist ein Token, das der Server sendet und das der Browser bis zur nächsten Anforderung aufbewahrt. Dies wird nur verwendet, wenn der Browser weiß, dass die Cache-Lebensdauer der Ressource abgelaufen ist.

E-Tags sind vom Server generierte Hash-Werte, die häufig den physischen Dateinamen der Ressource und das Datum der letzten Änderung auf dem Server als Startwert verwenden. Wenn eine Ressourcendatei aktualisiert wird, ändert sich das Änderungsdatum und ein neuer Hashwert wird generiert und im Antwortheader an die Anforderung gesendet.

Andere Header-Tags, die sich auf das Caching auswirken

Die Header-Tags laufen ab und die zuletzt geänderten Tags sind so gut wie veraltet, werden jedoch aus Gründen der Abwärtskompatibilität mit älteren Browsern von den meisten Servern gesendet. Ein Beispiel:

expires: Thu, 01 Jan 1970 00:00:00 GMT last-modified: Sun, 01 Mar 2020 17:59:02 GMT 

Hier wird das Ablaufdatum auf das nullte Datum gesetzt (historisch vom UNIX-Betriebssystem). Dies zeigt an, dass die Ressource sofort abläuft, genau wie max-age = 0 . Zuletzt geändert teilt dem Browser mit, wann das letzte Update für die Ressource vorgenommen wurde. Anschließend kann er entscheiden, ob er erneut abgerufen werden soll, anstatt den Cache-Wert zu verwenden.

Erzwingen einer Cache-Aktualisierung über den Browser

Was ist ein hartes Nachladen?

Ein hartes Neuladen erzwingt das erneute Abrufen aller Ressourcen auf einer Seite, unabhängig davon, ob es sich um Inhalte, Skripte, Stylesheets oder Medien handelt. So ziemlich alles, oder?

Nun, einige Ressourcen sind möglicherweise nicht explizit auf einer Seite enthalten. Stattdessen können sie dynamisch abgerufen werden, normalerweise nachdem alles Explizite geladen wurde.

Der Browser weiß nicht im Voraus, dass dies passieren wird, und wenn dies der Fall ist, verwenden die späteren Anforderungen (normalerweise durch Skripte initiiert) weiterhin zwischengespeicherte Kopien dieser Ressourcen, sofern verfügbar.

Was ist klarer Cache und hartes Neuladen?

Dieser Vorgang löscht den gesamten Browser-Cache, was den gleichen Effekt wie ein hartes Neuladen hat, aber zusätzlich dazu führt, dass auch dynamisch geladene Ressourcen abgerufen werden - schließlich befindet sich nichts im Cache, sodass keine Wahl bleibt!

Content Delivery Networks: Ein geografisch lokalisierter Cache

Ein CDN ist mehr als nur ein Cache, aber das Caching ist eine seiner Aufgaben. Ein CDN speichert Daten an geografisch verteilten Standorten, sodass die Umlaufzeiten zu und von einem geografisch lokalen Browser reduziert werden.

Browseranforderungen werden an ein nahe gelegenes CDN weitergeleitet, wodurch die physische Entfernung verkürzt wird, die Antwortdaten zurücklegen müssen. CDNs sind auch in der Lage, große Datenmengen zu verarbeiten und bieten Sicherheit gegen einige Arten von Angriffen.

Ein CDN erhält seine Ressourcen über einen Internet Exchange Point (IXP), Knoten, die Teil des Rückgrats des Internets sind (in Großbuchstaben). Es sind Schritte erforderlich, um das Anforderungsrouting so einzurichten, dass es zu einem CDN anstelle des Hostservers wechselt. Der nächste Schritt besteht darin, sicherzustellen, dass das CDN den aktuellen Inhalt Ihrer Website enthält.

Früher unterstützten die meisten CDNs die Push-Methode: Eine Website übertrug neuen Inhalt an einen CDN-Hub, der dann an geografisch verteilte Knoten verteilt wurde.

Heutzutage verwenden die meisten CDNs die oben beschriebenen (oder ähnlichen) Caching-Protokolle, um 1) neue Ressourcen herunterzuladen und 2) vorhandene zu aktualisieren. Der Browser hat immer noch seinen Cache und nichts davon ändert sich. Ein CDN beschleunigt lediglich die Übertragung neuer Ressourcen.