Detaillierte Erläuterung des HTTP-Caching-Mechanismus

In der Entwicklung von Netzwerkanwendungen ist die Verbesserung der Zugriffsgeschwindigkeit und Effizienz von Websites von großer Bedeutung. Das Entwerfen verschiedener Arten von Caches kann unnötige Datenübertragungen und -anforderungen effektiv vermeiden und die Reaktionsgeschwindigkeit von Websites erheblich beschleunigen. Das HTTP-Protokoll selbst verfügt über einen integrierten HTTP-Caching-Mechanismus. Dieser Artikel befasst sich eingehend mit dem HTTP-Caching-Mechanismus und seinen Anwendungen.

Arten von Caches in HTTP

Das Prinzip des Cachings besteht darin, eine Kopie der angeforderten Ressource lokal zu speichern, sodass die Kopie bei einer erneuten Anforderung direkt zurückgegeben werden kann, anstatt sie erneut vom Server herunterzuladen. Dadurch werden Ressourcenübertragungen reduziert und die Effizienz gesteigert. Zusätzlich zum direkten Zugriff und der Rückgabe von Ressourcen werden HTTP-Caches hauptsächlich in zwei Kategorien unterteilt:

1. Gemeinsamer Cache: Verschiedene Clients können Ressourcen aus dem gemeinsamen Cache beziehen, der sich für Szenarien eignet, in denen mehrere Clients auf dieselben Ressourcen zugreifen. Er wird häufig in Web-Proxy-Servern eingesetzt. Viele Benutzer können die Ressourcenkopien auf dem Server gemeinsam nutzen, wodurch wiederholtes Speichern durch jeden Benutzer vermieden und ungültiges Kopieren von Ressourcen reduziert wird.
2. Privater Cache: Nur bestimmte Benutzer oder Clients können darauf zugreifen, andere haben keine Zugriffsrechte. Browser-Caches gehören normalerweise zu privaten Caches, die nur dem aktuellen Browser dienen und nicht mit anderen Browsern geteilt werden.

Status von zwischengespeicherten Antworten in HTTP

HTTP-Caching wird im Allgemeinen auf GET-Anforderungen angewendet, da GET-Anforderungen normalerweise keine anderen Parameter als den URI haben und hauptsächlich verwendet werden, um Ressourcen vom Server abzurufen. Unterschiedliche GET-Anforderungen geben unterschiedliche Statuscodes zurück:

• 200 OK: Die Ressource wurde erfolgreich zurückgegeben.
• 301: Weiterleitung.
• 404: Die angeforderte Ressource ist nicht vorhanden, und es tritt eine Ausnahme auf.
• 206: Es wird ein unvollständiges Ergebnis zurückgegeben.

Cache-Kontrolle in HTTP

Die HTTP-Cache-Kontrolle wird über HTTP-Header implementiert. In HTTP 1.1 wurde Cache-Control eingeführt, mit dessen Hilfe das Caching-Verhalten von Anforderungen und Antworten fein gesteuert werden kann:

• Kein Caching: Die Verwendung von Cache-Control: no-store stellt sicher, dass die Ressource nicht zwischengespeichert wird.
• Cache-Validierung: Cache-Control: no-cache erfordert die Validierung des Client-Caches.
• Obligatorische Validierung: Cache-Control: must-revalidate, und abgelaufene Ressourcen dürfen nicht verwendet werden.
• Cache-Bereichskontrolle: Der Server kann über Cache-Control: private oder Cache-Control: public steuern, ob der Cache privat oder öffentlich ist.
• Ablaufzeit-Einstellung: Cache-Control: max-age=31536000 legt die Gültigkeitsdauer der Ressource fest und überschreibt den Expires-Header. Innerhalb dieser Zeit gilt die Ressource als aktuell und muss nicht erneut vom Server abgerufen werden.

In HTTP 1.0 kann das Feld Pragma ähnliche Funktionen erreichen. Beispielsweise hat Pragma: no-cache eine ähnliche Wirkung wie Cache-Control: no-cache und zwingt den Client, den Cache zur Überprüfung an den Server zu senden. Die Serverantwort enthält jedoch normalerweise kein Pragma, sodass Pragma Cache-Control nicht vollständig ersetzen kann.

Cache-Aktualisierung

Nachdem der Client die Ressource zwischengespeichert hat, muss aus Sicherheitsgründen eine Ablaufzeit festgelegt werden. Nur innerhalb der Ablaufzeit ist der Cache gültig; wenn er die Ablaufzeit überschreitet, muss die Ressource erneut vom Server abgerufen werden. Dieser Mechanismus stellt sicher, dass die vom Client abgerufenen Ressourcen immer auf dem neuesten Stand sind und die Aktualisierungen auf der Serverseite rechtzeitig mit dem Client synchronisiert werden können.

• Cache-Status: Wenn sich die Client-Ressource innerhalb der Ablaufzeit befindet, ist der Status aktuell; andernfalls ist er veraltet.
• Ablaufbehandlung: Wenn sich die Ressource in einem veralteten Zustand befindet, wird sie nicht sofort vom Client gelöscht. Stattdessen wird bei der nächsten Anforderung eine If-None-Match-Anforderung an den Server gesendet, um festzustellen, ob die Ressource auf der Serverseite noch aktuell ist. Wenn sich die Ressource nicht geändert hat, gibt der Server 304 (Not Modified) zurück, was darauf hinweist, dass die Ressource noch gültig ist.
• Frischeberechnung: Die Frische der Ressource wird durch Cache-Control: max-age=N bestimmt. Wenn dieses Header-Feld in der Antwort nicht vorhanden ist, überprüfen Sie, ob der Expires-Header vorhanden ist. Wenn er vorhanden ist, ist die Frischezeit Expires - Date. Wenn keines von beiden vorhanden ist, suchen Sie nach dem Last-Modified-Header, und die Frischezeit ist (Date - Last-modified) / 10.

Revving

Um die Effizienz von HTTP-Anforderungen zu verbessern, ist es im Allgemeinen wünschenswert, eine längere Cache-Zeit zu haben. Eine zu lange Cache-Zeit erschwert jedoch die Aktualisierung von Serverressourcen. Für Dateien, die nicht häufig aktualisiert werden, können der Dateiname und die Versionsnummer zur Anforderungs-URL hinzugefügt werden. Dieselbe Versionsnummer gibt an, dass sich der Ressourceninhalt nicht geändert hat und lange zwischengespeichert werden kann. Wenn sich der Inhalt der Serverressource ändert, muss nur die Versionsnummer in der Anforderungs-URL aktualisiert werden. Mithilfe moderner Front-End-Paketierungstools ist es nicht schwierig, diese Operation zu implementieren.

Cache-Verifizierung

Wenn die zwischengespeicherte Ressource abläuft, gibt es zwei Möglichkeiten, damit umzugehen: Fordern Sie die Ressource erneut vom Server an oder überprüfen Sie die zwischengespeicherte Ressource erneut. Die erneute Verifizierung erfordert Serverunterstützung und das Setzen des Anforderungs-Headers Cache-Control: must-revalidate.

• Verifizierungsmethode: Wenn der Client die Gültigkeit der Ressource überprüft, kann er die Ressource nicht direkt an den Server senden, da dies zu einer Ressourcenverschwendung führen würde. HTTP stellt den ETags-Header als eindeutigen Bezeichner für die Ressource bereit. Der Client sendet eine If-None-Match-Anforderung, damit der Server feststellen kann, ob die Ressource übereinstimmt, was eine starke Verifizierung darstellt. Wenn die Antwort Last-Modified enthält, kann der Client eine If-Modified-Since-Anforderung senden, um den Server zu fragen, ob sich die Datei geändert hat, was eine schwache Verifizierung darstellt.
• Serverantwort: Der Server kann wählen, ob er eine Dateiverifizierung durchführen möchte. Wenn er nicht verifiziert, gibt er direkt den Statuscode 200 OK und die Ressource zurück; wenn er verifiziert, gibt er 304 Not Modified zurück und teilt dem Client mit, dass er die zwischengespeicherte Ressource weiterhin verwenden kann. Gleichzeitig kann er andere Header-Felder zurückgeben, z. B. die Aktualisierung der Ablaufzeit des Caches.

Vary-Antwort

Der Server kann den Vary-Header in der Antwort tragen, und sein Wert ist ein bestimmter Schlüssel im Antwort-Header, z. B. Content-Encoding, was darauf hinweist, dass die Ressource für eine bestimmte Codierung zwischengespeichert wird. Zum Beispiel:

1. Erste Anforderung: Der Client sendet GET /resource HTTP/1.1, Accept-Encoding: *, und der Server gibt HTTP/1.1 200 OK, Content-Encoding: gzip, Vary: Content-Encoding zurück. Zu diesem Zeitpunkt werden die Ressource und die Content-Encoding mit gzip-Codierung zusammen zwischengespeichert.
2. Nachfolgende Anforderung: Der Client sendet GET /resource HTTP/1.1, Accept-Encoding: br. Da die Codierung der aktuell zwischengespeicherten Ressource gzip ist, die sich von der vom Client erwarteten br unterscheidet, muss die Ressource erneut vom Server abgerufen werden. Der Server gibt HTTP/1.1 200 OK, Content-Encoding: br, Vary: Content-Encoding zurück, und der Client speichert die Ressource erneut im br-Format zwischen. Wenn der Client das nächste Mal eine Ressource des br-Typs anfordert, kann er den Cache treffen.

Vary implementiert das Caching durch zusätzliche Klassifizierung von Ressourcen (z. B. Codierungstypen), führt aber zu wiederholter Speicherung von Ressourcen. Um dieses Problem zu lösen, muss die Ressourcenanforderung standardisiert werden, d. h. die Codierungsmethode wird vor der Anforderung überprüft, und es wird eine Codierung für die Anforderung ausgewählt, um mehrere Caches zu vermeiden.

Fazit

Dieser Artikel bietet eine umfassende Einführung in den HTTP-Caching-Mechanismus und behandelt Cache-Typen, Antwortstatus, Cache-Kontrolle, Cache-Aktualisierung, Revving, Cache-Verifizierung und Vary-Antworten. In der Praxis kann ein tiefes Verständnis und eine vernünftige Anwendung des HTTP-Caching-Mechanismus dazu beitragen, die Website-Performance und die User Experience zu verbessern.

Leapcell: Das Beste aus Serverless Web Hosting

Schliesslich empfehle ich eine Plattform, die sich am besten für die Bereitstellung von Webdiensten eignet: Leapcell

🚀 Entwickeln Sie mit Ihrer Lieblingssprache

Entwickeln Sie mühelos in JavaScript, Python, Go oder Rust.

🌍 Stellen Sie unbegrenzt Projekte kostenlos bereit

Zahlen Sie nur für das, was Sie nutzen – keine Anfragen, keine Gebühren.

⚡ Pay-as-You-Go, keine versteckten Kosten

Keine Leerlaufgebühren, nur nahtlose Skalierbarkeit.

📖 Entdecken Sie unsere Dokumentation

🔹 Folgen Sie uns auf Twitter: @LeapcellHQ