Freigeben ü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 wird am 15. Januar 2025 eingestellt. Sie müssen Ihre Workload vor diesem Datum zu Azure Front Door migrieren, um Dienstunterbrechungen zu vermeiden. 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

Wichtig

Standardmäßig ignoriert ein für die DSA optimierter Azure Content Delivery Network-Endpunkt Header mit Cacheanweisungen und umgeht die Zwischenspeicherung. Für Profil Azure CDN Standard von Edgio können Sie anpassen, wie ein Azure Content Delivery Network-Endpunkt diese Header behandelt, indem Sie Cacheregeln für Content Delivery Network verwenden, um die Zwischenspeicherung zu aktivieren. Nur bei Azure CDN Premium von Edgio-Profilen verwenden Sie die Regel-Engine, um die Zwischenspeicherung zu aktivieren.

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.
  • Bei Verwendung in einer HTTP-Antwort vom Ursprungsserver an das Content Delivery Network-POP:
    • Azure CDN Standard/Premium von Edgio und Azure CDN Standard von Microsoft unterstützen alle Cache-Control-Anweisungen.
    • Azure CDN Standard/Premium von Edgio und Azure CDN Standard von Microsoft berücksichtigen 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/Premium von Edgio unterstützt standardmäßig sowohl ETag - als auch Last-Modified -Validierungssteuerelemente, wohingegen Azure CDN Standard von Microsoft nur Last-Modified unterstützt.

ETag:

  • Azure CDN Standard/Premium von Edgio unterstützt standardmäßig ETag, während Azure CDN Standard von Microsoft dies nicht tut.
  • ETag definiert eine Zeichenfolge, die für jede Datei und Dateiversion eindeutig ist. Beispiel: ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Es wurde in HTTP 1.1 eingeführt und ist neuer als Last-Modified. Ist nützlich, wenn die Ermittelung des Datums der letzten Änderung schwierig ist.
  • Unterstützt sowohl eine starke als auch eine schwache Validierung, wobei Azure Content Delivery Network nur die starke Validierung unterstützt. Für eine sichere Überprüfung müssen die beiden Ressourcendarstellungen Byte für Byte identisch sein.
  • Ein Cache überprüft eine Datei mit ETag, indem er einen If-None-Match-Header mit einem oder mehreren ETag-Validierungssteuerelementen in der Anforderung sendet. Beispiel: If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Wenn die Serverversion mit einem ETag-Validierungssteuerelement in der Liste übereinstimmt, wird der Statuscode 304 (Nicht geändert) in der Antwort gesendet. Wenn die Version unterschiedlich ist, antwortet der Server mit dem Statuscode 200 (OK) und der aktualisierten Ressource.

Last-Modified:

  • Nur bei Azure CDN Standard/Premium von Edgio wird Last-Modified verwendet, wenn ETag nicht Teil der HTTP-Antwort ist.
  • 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. Nur bei Azure CDN Premium von Edgio können Sie mithilfe der Regel-Engine einige dieser Bedingungen anpassen.

Azure Content Delivery Network von Microsoft Azure Content Delivery Network von Edgio
HTTP-Statuscodes (Azure Cognitive Search) 200, 203, 206, 300, 301, 410, 416 200
HTTP-Methoden GET, HEAD GET
Dateigrößenbeschränkungen 300 GB 300 GB

Damit das Zwischenspeichern von Azure CDN Standard von Microsoft 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

In der folgenden Tabelle werden das Standardverhalten beim Zwischenspeichern für Azure Content Delivery Network-Produkte und Optimierungen beschrieben.

Microsoft: Allgemeine Webbereitstellung Edgio: allgemeine Webbereitstellung Edgio: DSA
Berücksichtigung des Ursprungs Ja Ja No
Content Delivery Network-Cachedauer Zwei Tage Sieben Tage Keine

Berücksichtigung des Ursprungs: Gibt an, ob die unterstützten Header mit Cacheanweisungen berücksichtigt werden sollen, wenn sie in der HTTP-Antwort des Ursprungsservers enthalten sind.

CDN-Cachedauer: Gibt den Zeitraum an, für den eine Ressource in Azure Content Delivery Network zwischengespeichert wird. Wenn Ursprung berücksichtigen jedoch auf „Ja“ festgelegt ist und die HTTP-Antwort des Ursprungsservers den Header mit Cacheanweisungen Expires oder Cache-Control: max-age enthält, verwendet Azure Content Delivery Network stattdessen den vom Header angegebenen Wert für die Dauer.

Hinweis

Azure Content Delivery Network gibt keine Garantien über die Mindestzeit, für 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