Teilen über

Funktionsweise der Zwischenspeicherung

  • Artikel

Wichtig

Azure CDN Standard von Microsoft (klassisch) wird am 30. September 2027 eingestellt. Um Dienstunterbrechungen zu vermeiden, ist es wichtig, dass Sie Ihre Profile von Azure CDN Standard von Microsoft (klassisch) bis zum 30. September 2027 auf die Dienstebene Azure Front Door Standard oder Premium migrieren. Weitere Informationen finden Sie unter Einstellung von Azure CDN Standard von Microsoft (klassisch).

Azure CDN von Edgio wurde am 15. Januar 2025 eingestellt. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Einstellung von Azure CDN von Edgio.

Dieser Artikel enthält einen Überblick über allgemeine Konzepte zum Zwischenspeichern und darüber, wie das Azure Content Delivery Network mithilfe der Zwischenspeicherung die Leistung verbessert. Wenn Sie erfahren möchten, wie Sie das Zwischenspeicherungsverhalten an Ihrem Content Delivery Network-Endpunkt anpassen, lesen Sie Steuern des Verhaltens beim Zwischenspeichern im Azure Content Delivery Network mit Cacheregeln und Steuern des Azure Content Delivery Network-Zwischenspeicherverhaltens mit Abfragezeichenfolgen.

Einführung zum Zwischenspeichern

Unter Zwischenspeichern versteht man das lokale Speichern von Daten, um im Fall einer erneuten Anforderung dieser Daten schneller darauf zugreifen zu können. Bei dem am häufigsten verwendeten Cachetyp, dem Webbrowsercache, speichert ein Webbrowser Kopien von statischen Daten auf einer lokalen Festplatte. Durch das Zwischenspeichern kann der Webbrowser verhindern, dass mehrere Roundtrips zum Server ausgeführt werden, und stattdessen lokal auf diese Daten zugreifen, wodurch Zeit und Ressourcen gespart werden. Das Zwischenspeichern ist besonders für die lokale Verwaltung kleiner, statischer Daten (z.B. statischen Bildern, CSS-Dateien und JavaScript-Dateien) geeignet.

Gleichermaßen wird die Funktion zum Zwischenspeichern von einem Content Delivery Network auf Edgeservern in der Nähe des Benutzers verwendet, um zu vermeiden, dass Anforderungen zum Ursprung zurückkehren, und die Latenzen für Endbenutzer zu verringern. Im Gegensatz zu einem Webbrowsercache, der nur für einen einzelnen Benutzer verwendet wird, verfügt das Content Delivery Network über einen freigegebenen Cache. In einem freigegebenen Content Delivery Network-Cache kann auf eine von einem Benutzer angeforderte Datei von einem anderen Benutzer verwendet werden, was die Anzahl der Anforderungen an den Ursprungsserver stark reduziert.

Dynamische Ressourcen, die häufig geändert werden oder für einen einzelnen Benutzer eindeutig sind, können nicht zwischengespeichert werden. Bei diesen Arten von Ressourcen kann zur Verbesserung der Leistung jedoch die DSA-Optimierung (Dynamic Site Acceleration) im Azure Content Delivery Network eingesetzt werden.

Eine Zwischenspeicherung kann auf mehreren Ebenen zwischen dem Ursprungsserver und dem Endbenutzer erfolgen:

  • Webserver: Verwendet einen freigegebenen Cache (für mehrere Benutzer).
  • Content Delivery Network: Verwendet einen freigegebenen Cache (für mehrere Benutzer).
  • Internetdienstanbieter (ISP): Verwendet einen freigegebenen Cache (für mehrere Benutzer).
  • Webbrowser: Verwendet einen privaten Cache (für einen Benutzer).

Die einzelnen Caches stellen in der Regel die Aktualität ihrer eigenen Ressourcen sicher und führen eine Überprüfung durch, wenn eine Datei veraltet ist. Dieses Verhalten ist in der HTTP-Zwischenspeicherungsspezifikation RFC 7234 definiert.

Ressourcenaktualität

Da eine zwischengespeicherte Ressource möglicherweise nicht mehr aktuell oder veraltet ist (im Vergleich zu der entsprechenden Ressource auf dem Ursprungsserver), ist es wichtig, dass Mechanismen zum Zwischenspeichern steuern, wann Inhalte eine Aktualisierung erhalten. Um Zeit und Bandbreitenkapazitäten zu sparen, wird eine zwischengespeicherte Ressource nicht mit der Version auf dem Ursprungsserver abgeglichen, wenn darauf zugegriffen wird. Solange eine zwischengespeicherte Ressource als aktuell gilt, wird stattdessen davon ausgegangen, dass es sich um die neueste Version handelt, und sie wird direkt an den Client gesendet. Eine zwischengespeicherte Ressource gilt als aktuell, wenn diese neuer ist als der durch eine Cacheeinstellung definierte Zeitraum. Wenn ein Browser beispielsweise eine Webseite neu lädt, stellt er sicher, dass jede zwischengespeicherte Ressource auf Ihrer Festplatte aktuell ist, und lädt diese. Wenn die Ressource nicht „frisch“ (d.h. veraltet) ist, wird eine aktuelle Kopie vom Server geladen.

Überprüfen

Wenn eine Ressource als veraltet gilt, wird der Ursprungsserver aufgefordert, diese zu überprüfen, um festzustellen, ob die Daten im Cache immer noch mit den Daten auf dem Ursprungsserver übereinstimmen. Wenn die Datei auf dem Ursprungsserver geändert wurde, aktualisiert der Cache die jeweilige Version der Ressource. Wenn die Ressource aktuell ist, werden die Daten direkt aus dem Cache bereitgestellt, ohne dass dieser vorher überprüft wird.

Zwischenspeicherung für Content Delivery Networks

Die Zwischenspeicherung ist für die Funktionsweise eines Content Delivery Networks von zentraler Bedeutung, um die Bereitstellung zu beschleunigen und die Auslastung des Ursprungsservers im Hinblick auf statische Ressourcen wie Bilder, Schriftarten und Videos zu reduzieren. Bei Content Delivery Network-Caches werden statische Ressourcen selektiv auf strategisch angeordneten Servern gespeichert, die sich näher an einem Benutzer befinden und folgende Vorteile bieten:

  • Da der Großteil des Webdatenverkehrs statisch ist (z. B. Bilder, Schriften und Videos), reduzieren Content Delivery Network-Caches die Netzwerklatenzen, indem sie Inhalte näher an den Benutzer verlagern und so die Entfernung der Datenübertragung verringern.

  • Durch die Auslagerung von Aufgaben in ein Content Delivery Network können der Netzwerkdatenverkehr und die Auslastung des Ursprungsservers durch Zwischenspeicherung reduziert werden. Hierdurch werden der Kosten- und Ressourcenaufwand für die Anwendung selbst bei einer großen Benutzeranzahl reduziert.

Ähnlich wie bei der Implementierung der Zwischenspeicherung in einem Webbrowser können Sie durch Senden von Headern mit Cacheanweisungen steuern, wie das Zwischenspeichern in einem Content Delivery Network durchgeführt wird. Header mit Cacheanweisungen sind HTTP-Header, die üblicherweise vom Ursprungsserver hinzugefügt werden. Obwohl die meisten dieser Header ursprünglich für die Zwischenspeicherung in Clientbrowsern konzipiert wurden, werden sie nun auch von sämtlichen Zwischencaches wie z. B. Content Delivery Networks verwendet.

Zum Definieren der Cacheaktualität können zwei Header verwendet werden: Cache-Control und Expires. Cache-Control ist neuer und hat gegenüber Expires Vorrang, wenn beide vorhanden sind. Es gibt auch zwei Arten von Headern, die zur Überprüfung verwendet werden (sogenannte Validierungssteuerelemente): ETag und Last-Modified. ETag ist neuer und hat gegenüber Last-Modified Vorrang, wenn beide definiert sind.

Header mit Cacheanweisungen

Azure Content Delivery Network unterstützt die folgenden HTTP-Header mit Cacheanweisungen, die die Cachedauer und die -freigabe definieren.

Cache-Control:

  • Es wurde in HTTP 1.1 eingeführt, um Webpublishern eine größere Kontrolle über ihre Inhalte zu ermöglichen und die Beschränkungen des Expires-Headers zu umgehen.
  • Überschreibt den Expires-Header, wenn beide sowie Cache-Control definiert sind.
  • Wenn sie in einer HTTP-Anforderung vom Client zum Content Delivery Network-POP verwendet werden, wird Cache-Control standardmäßig von allen Azure Content Delivery Network-Profilen ignoriert.
  • Wenn sie in einer HTTP-Antwort vom Ursprungsserver zum Content Delivery Network-POP verwendet werden, wird Cache-Control standardmäßig von allen Azure Content Delivery Network-Profilen berücksichtigt. Azure CDN berücksichtigt auch das Verhalten bei Zwischenspeicherung für Cachesteuerungsanweisungen in RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Caching (ietf.org).

Expires:

  • Die in HTTP 1.0 eingeführten Legacyheader werden aus Gründen der Abwärtskompatibilität unterstützt.
  • Verwendet eine datumsbasierte Ablaufzeit mit sekundengenauer Genauigkeit.
  • Ähnlich wie Cache-Control: max-age.
  • Wird verwendet, wenn Cache-Control nicht vorhanden ist.

Pragma:

  • Von Azure Content Delivery Network werden sie standardmäßig nicht berücksichtigt.
  • Die in HTTP 1.0 eingeführten Legacyheader werden aus Gründen der Abwärtskompatibilität unterstützt.
  • Wird als Clientanforderungsheader mit der folgenden Anweisung verwendet: no-cache. Diese Anweisung weist den Server dazu an, eine neue Version der Ressource zu übermitteln.
  • Pragma: no-cache entspricht Cache-Control: no-cache.

Validierungssteuerelemente

Wenn der Cache veraltet ist, werden Validierungssteuerelemente des HTTP-Caches verwendet, um die zwischengespeicherte Version einer Datei mit der Version auf dem Ursprungsserver abzugleichen. Azure CDN Standard von Microsoft unterstützt nur Last-Modified.

Hinweis

Azure CDN von Microsoft (klassisch) unterstützt ETag nicht.

Last-Modified:

  • Gibt das Datum und die Uhrzeit an, an dem der Ursprungsserver festgestellt hat, dass die Ressource zuletzt geändert wurde. Beispiel: Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • Bei Inhalten, die größer als 8 MB sind, sollten Back-End-Ursprungsserver konsistente Last-Modified-Zeitstempel pro Ressource beibehalten. Das Zurückgeben inkonsistenter Last-Modified-Zeiten von Back-End-Servern führt zu Fehlern aufgrund von Validierungskonflikten und Fehlern vom Typ „HTTP 5XX“. Azure Storage unterstützt möglicherweise keine replikatübergreifenden konsistenten Last-Modified-Zeitstempel, was zu ähnlichen Fehlern aufgrund von Validierungskonflikten führen kann.
  • Ein Cache überprüft eine Datei mit Last-Modified, indem er einen If-Modified-Since-Header mit Datum und Uhrzeit in der Anforderung sendet. Der Ursprungsserver gleicht dieses Datum mit dem Last-Modified-Header der aktuellen Ressource ab. Wenn die Ressource seit dem angegebenen Zeitpunkt nicht geändert wurde, gibt der Server in seiner Antwort den Statuscode 304 (Nicht geändert) zurück. Wenn die Ressource geändert wurde, gibt der Server den Statuscode 200 (OK) und die aktualisierte Ressource zurück.

Ermitteln der zwischenspeicherbaren Dateien

Nicht alle Ressourcen können zwischengespeichert werden. Die folgende Tabelle zeigt, welche Ressourcen abhängig von der Art der HTTP-Antwort zwischengespeichert werden können. Mit HTTP-Antworten bereitgestellte Ressourcen, die nicht alle diese Bedingungen erfüllen, können nicht zwischengespeichert werden.

Bedingungen Wert
HTTP-Statuscodes (Azure Cognitive Search) 200, 203, 206, 300, 301, 410, 416
HTTP-Methoden GET, HEAD
Dateigrößenbeschränkungen 300 GB

Damit das Zwischenspeichern bei einer Ressource funktioniert, muss der Ursprungsserver HEAD- und GET-HTTP-Anforderungen unterstützen, und die Inhaltslängenwerte müssen für alle HEAD- und GET-HTTP-Antworten für die Ressource identisch sein. Bei einer HEAD-Anforderung muss der Ursprungsserver die HEAD-Anforderung unterstützen und mit den gleichen Headern antworten wie wenn er eine GET-Anforderung erhalten hätte.

Hinweis

Anforderungen, die einen Autorisierungsheader enthalten, werden nicht zwischengespeichert.

Standardverhalten beim Zwischenspeichern

Das standardmäßige Zwischenspeicherungsverhalten für Azure CDN besteht in der Berücksichtigung des Ursprungs und dem Zwischenspeichern der Inhalte für zwei Tage.

Berücksichtigung des Ursprungs: Diese Einstellung gibt an, ob die Header mit Cacheanweisungen (Cache-Control oder Expires) berücksichtigt werden sollen, wenn sie in der HTTP-Antwort des Ursprungsservers vorhanden sind.

CDN-Cachedauer: Diese Einstellung gibt die Dauer an, für die eine Ressource im Azure CDN zwischengespeichert wird. Wenn Berücksichtigung des Ursprungs aktiviert ist und die HTTP-Antwort vom Ursprungsserver den Cache-Control: max-age- oder Expires-Header enthält, verwendet Azure CDN die durch diese Header angegebene Dauer anstelle des standardmäßigen Zeitraums von zwei Tagen.

Hinweis

Azure CDN gibt keine Garantien über die Mindestzeit, die das Objekt im Cache gespeichert wird. Zwischengespeicherte Inhalte können aus dem Content Delivery Network-Cache entfernt werden, bevor sie ablaufen, wenn die Inhalte nicht so häufig angefordert werden, um Platz für häufiger angeforderte Inhalte zu schaffen.

Nächste Schritte