Zwischenspeicherung mit Azure Front Door

Wichtig

Azure Front Door (klassisch) wird am 31. März 2027 eingestellt. Um Dienstunterbrechungen zu vermeiden, ist es wichtig, dass Sie Ihre (klassischen) Azure Front Door-Profile bis März 2027 zur Azure Front Door Standard- oder Premium-Stufe migrieren. Weitere Informationen finden Sie unter Einstellung von Azure Front Door (klassisch).

Azure Front Door ist ein modernes Content Delivery Network (CDN) mit Beschleunigung dynamischer Websites und Lastenausgleich. Wenn das Zwischenspeichern auf Ihrer Route konfiguriert ist, überprüft der Edgestandort, der jede Anforderung empfängt, seinen Cache auf eine gültige Antwort. Zwischenspeichern hilft, die Menge des Datenverkehrs, der an Ihren Ursprungsserver gesendet wird, zu reduzieren. Wenn keine zwischengespeicherte Antwort verfügbar ist, wird die Anforderung an den Ursprung weitergeleitet.

Jede Front Door-Edgesite verwaltet ihren eigenen Cache, und Anforderungen können von verschiedenen Edgesites verarbeitet werden. Daher kann es sein, dass immer noch ein Teil des Datenverkehrs Ihren Ursprung erreicht, auch wenn Sie zwischengespeicherte Antworten bereitgestellt haben.

Die Zwischenspeicherung kann die Wartezeit und die Last auf Ursprungsservern erheblich verringern. Allerdings können nicht alle Arten von Datenverkehr von der Zwischenspeicherung profitieren. Statische Ressourcen wie Bilder, CSS- und JavaScript-Dateien eignen sich ideal für das Zwischenspeichern. Dynamische Ressourcen, z. B. authentifizierte API-Endpunkte, sollten nicht zwischengespeichert werden, um den Verlust personenbezogener Daten zu verhindern. Es wird empfohlen, separate Routen für statische und dynamische Ressourcen zu verwenden, wobei die Zwischenspeicherung für letztere deaktiviert sein sollte.

Warnung

Lesen Sie vor dem Aktivieren der Zwischenspeicherung gründlich die öffentliche Dokumentation durch, und testen Sie alle möglichen Szenarien, bevor Sie das Zwischenspeichern aktivieren. Wie bereits erwähnt, können Sie bei falscher Konfiguration versehentlich benutzerspezifische Daten zwischenspeichern, die von mehreren Benutzern gemeinsam genutzt werden können, was zu Datenschutzvorfällen führt.

Anforderungsmethoden

Nur Anforderungen, die die Anforderungsmethode GET verwenden, können zwischengespeichert werden. Alle anderen Anforderungsmethoden werden immer per Proxy über das Netzwerk gesendet.

Übermittlung großer Dateien

Azure Front Door übermittelt große Dateien ohne Beschränkung der Dateigröße. Wenn das Zwischenspeichern aktiviert ist, kommt bei Azure Front Door eine Technik namens Objektblockerstellung zum Einsatz. Wenn eine große Datei angefordert wird, ruft Azure Front Door Service kleinere Teile der Datei vom Ursprung ab. Nachdem Front Door eine Anfrage für eine vollständige Datei oder eine Anfrage für einen Bytebereich einer Datei erhalten hat, fordert die Front Door-Umgebung die Datei in Blöcken von 8 MB vom Ursprung an.

Nachdem der Block in der Azure Front Door-Umgebung angekommen ist, wird er zwischengespeichert und sofort für den Benutzer bereitgestellt. Front Door erstellt dann einen parallelen Vorabruf für den nächsten Block. Durch dieses Vorab-Abrufen wird sichergestellt, dass der Inhalt dem Benutzer immer einen Block voraus ist, sodass sich die Wartezeit reduziert. Dieser Prozess wird fortgesetzt, bis die gesamte Datei heruntergeladen wurde (falls angefordert) oder der Client die Verbindung beendet. Weitere Informationen zur Bytebereichsanforderung finden Sie unter RFC 7233.

Alle Blöcke werden von Azure Front Door Service zwischengespeichert, sobald sie eingetroffen sind, sodass nicht die gesamte Datei im Cache von Front Door zwischengespeichert werden muss. Nachfolgende Anforderungen für die Datei oder Bytebereiche werden über den Cache verarbeitet. Wenn nicht alle Blöcke zwischengespeichert sind, werden mittels Vorabruf Blöcke vom Ursprung angefordert.

Diese Optimierung beruht auf der Fähigkeit des Ursprungs, Bytebereichsanforderungen zu unterstützen. Wenn der Ursprung keine Bytebereichsanfragen unterstützt oder Bereichsanfragen nicht ordnungsgemäß verarbeitet, ist diese Optimierung nicht anwendbar.

Wenn Ihr Ursprung auf eine Anforderung mit einem Range-Header antwortet, muss er auf eine der folgenden Arten reagieren:

• Eine Bereichsantwort zurückgeben. Die Antwort muss den HTTP-Statuscode 206 verwenden. Außerdem muss der Antwortheader Content-Range vorhanden sein und der tatsächlichen Länge des Inhalts entsprechen, den Ihr Ursprung zurückgibt. Wenn Ihr Ursprung die falschen Antwortheader mit ungültigen Werten sendet, speichert Azure Front Door die Antwort nicht zwischen. Dies kann möglicherweise zu inkonsistentem Verhalten führen.

  Tipp

  Wenn Ihr Ursprung die Antwort komprimiert, stellen Sie sicher, dass der Headerwert Content-Range der tatsächlichen Länge der komprimierten Antwort entspricht.

• Eine nicht auf einen Bytebereich beschränkte Antwort zurückgeben. Wenn Ihr Ursprung keine Bereichsanfragen verarbeiten kann, kann er den Header Range ignorieren und eine nicht bereichsbezogene Antwort zurückgeben. Stellen Sie sicher, dass der Ursprung einen anderen Antwortstatuscode als 206 zurückgibt. Beispielsweise kann der Ursprung als Antwort 200 OK zurückgeben.

Wenn der Ursprung die Codierung für segmentierte Übertragung (Chunked Transfer Encoding, CTE) verwendet, um Daten an das Azure Front Door-POP zu senden, werden Antwortgrößen von mehr als 8 MB nicht unterstützt.

Dateikomprimierung

Weitere Informationen finden Sie unter Verbessern der Leistung durch Komprimieren von Dateien in Azure Front Door.

Azure Front Door (klassisch) kann Inhalte dynamisch am Edge komprimieren, wodurch die Antwort an Ihre Clients kleiner ist und schneller erfolgt. Damit eine Datei für die Komprimierung geeignet ist, muss die Zwischenspeicherung aktiviert sein, und die Datei muss einen MIME-Typ aufweisen, damit sie komprimiert werden kann. Gegenwärtig lässt Azure Front Door (klassisch) keine Änderungen an dieser Liste zu. Die aktuelle Liste umfasst folgende Typen:

• application/eot
• application/font
• application/font-sfnt
• application/javascript
• "application/json"
• application/opentype
• application/otf
• application/pkcs7-mime
• application/truetype
• application/ttf
• application/vnd.ms-fontobject
• application/xhtml+xml
• application/xml
• application/xml+rss
• application/x-font-opentype
• application/x-font-truetype
• application/x-font-ttf
• application/x-httpd-cgi
• application/x-mpegurl
• application/x-opentype
• application/x-otf
• application/x-perl
• application/x-ttf
• application/x-javascript
• font/eot
• font/ttf
• font/otf
• font/opentype
• image/svg+xml
• text/css
• text/csv
• text/html
• text/javascript
• text/js, text/plain
• text/richtext
• text/tab-separated-values
• text/xml
• text/x-script
• text/x-component
• text/x-java-source

Darüber hinaus muss die Datei zwischen 1 KB und 8 MB groß sein.

Diese Profile unterstützen die folgenden Komprimierungscodierungen:

• GZip (GNU Zip)
• Brotli

Unterstützt eine Anforderung die GZip- und Brotli-Komprimierung, hat die Brotli-Komprimierung Vorrang.

Wenn in einer Anforderung für eine Ressource eine Komprimierung angegeben ist und die Anforderung zu einem Cachefehler führt, führt Azure Front Door (klassisch) die Komprimierung der Ressource direkt auf dem POP-Server durch. Anschließend wird die komprimierte Datei aus dem Cache bereitgestellt. Das resultierende Element wird mit einem Transfer-Encoding: chunked-Antwortheader zurückgegeben.

Wenn der Ursprung die Codierung für segmentierte Übertragung (Chunked Transfer Encoding, CTE) verwendet, um Daten an das Azure Front Door-POP zu senden, wird die Komprimierung nicht unterstützt.

Hinweis

Bereichsanforderungen können in verschiedene Größen komprimiert werden. Bei Azure Front Door müssen die Inhaltslängenwerte für alle GET HTTP-Anforderungen identisch sein. Senden Clients Bytebereichsanforderungen mit dem Header Accept-Encoding, der dazu führt, dass das Ursprungsobjekt mit unterschiedlichen Inhaltslängen antwortet, gibt Azure Front Door den Fehler 503 zurück. Sie können entweder die Komprimierung für den Ursprung deaktivieren oder eine Regelmodulregel erstellen, um den Header Accept-Encoding aus der Anfrage von Bytebereichsanfragen zu entfernen.

Verhalten von Abfragezeichenfolgen

Mit Azure Front Door können Sie steuern, wie Dateien für eine Webanforderung, die eine Abfragezeichenfolge enthält, zwischengespeichert werden.

In einer Webanforderung mit einer Abfragezeichenfolge ist die Abfragezeichenfolge der Teil der Anforderung, der auf das Fragezeichen (?) folgt. Eine Abfragezeichenfolge kann ein oder mehrere Schlüssel-Wert-Paare enthalten, wobei der Feldname und sein Wert durch ein Gleichheitszeichen (=) getrennt sind. Die einzelnen Schlüssel-Wert-Paare sind durch ein kaufmännisches Und-Zeichen („&“) voneinander getrennt.

Die URL http://www.contoso.com/content.mov?field1=value1&field2=value2 enthält beispielsweise zwei Abfragezeichenfolgen:

• field1, mit dem Wert value1.
• field2, mit dem Wert value2.

Falls mehrere Schlüssel-Wert-Paare in einer Abfragezeichenfolge derselben Anforderung vorhanden sind, spielt die Reihenfolge keine Rolle.

Beim Konfigurieren des Zwischenspeicherns geben Sie an, wie der Cache Abfragezeichenfolgen behandeln soll. Die folgenden Verhaltensweisen werden unterstützt:

• Abfragezeichenfolge ignorieren: In diesem Modus übergibt Azure Front Door die Abfragezeichenfolgen bei der ersten Anforderung vom Client an den Ursprung und speichert die Ressource zwischen. Für künftige Anforderungen der Ressource, die von der Front Door-Umgebung verarbeitet werden, werden die Abfragezeichenfolgen bis zum Ablauf der zwischengespeicherten Ressource ignoriert.

• Abfragezeichenfolge verwenden: In diesem Modus wird jede Anforderung mit einer eindeutigen URL, einschließlich der Abfragezeichenfolge, als eindeutiges Objekt mit eigenem Cache behandelt. So wird beispielsweise die Antwort vom Ursprung für eine Anforderung für www.example.ashx?q=test1 in der Azure Front Door Service-Umgebung zwischengespeichert und für nachfolgende Caches mit der gleichen Abfragezeichenfolge zurückgegeben. Eine Anforderung für www.example.ashx?q=test2 wird als separates Objekt mit eigener Einstellung für die Gültigkeitsdauer zwischengespeichert.

  Die Reihenfolge der Abfragezeichenfolgenparameter spielt keine Rolle. Wenn die Azure Front Door-Umgebung beispielsweise eine zwischengespeicherte Antwort für die URL www.example.ashx?q=test1&r=test2 enthält, wird auch eine Anforderung für www.example.ashx?r=test2&q=test1 aus dem Cache bereitgestellt.

• Angegebene Abfragezeichenfolgen ignorieren und Angegebene Abfragezeichenfolgen einschließen: In diesem Modus können Sie Azure Front Door so konfigurieren, dass beim Generieren des Cacheschlüssels angegebene Parameter eingeschlossen oder ausgeschlossen werden.

  Angenommen, der Standardcacheschlüssel ist /foo/image/asset.html, und es wird eine Anforderung an die URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200 gestellt. Wenn es eine Regelmodulregel zum Ausschließen des Abfragezeichenfolgenparameters userid gibt, ist /foo/image/asset.html?language=EN&sessionid=200 der Cacheschlüssel der Abfragezeichenfolge.

Konfigurieren Sie das Verhalten der Abfragezeichenfolgen für die Front Door-Route.

Cachebereinigung

Unter Cachebereinigung in Azure Front Door erfahren Sie, wie Sie die Cachebereinigung konfigurieren.

Azure Front Door speichert Ressourcen zwischen, bis deren Gültigkeitsdauer (Time-to-live, TTL) abläuft. Wenn ein Client eine Ressource nach Ablauf ihrer Gültigkeitsdauer anfordert, ruft die Front Door-Umgebung eine neue aktualisierte Kopie der Ressource ab, um die Anforderung zu erfüllen und den aktualisierten Cache zu speichern.

Die bewährte Methode, um sicherzustellen, dass Ihre Benutzer immer die neueste Kopie Ihrer Assets abrufen, besteht darin, Ihre Assets für jedes Update mit einer Version zu versehen und sie als neue URLs zu veröffentlichen. Azure Front Door Service ruft sofort die neuen Ressourcen für die nächsten Clientanforderungen ab. Manchmal möchten Sie möglicherweise zwischengespeicherten Inhalt aus allen Edgeknoten löschen und sie zwingen, neue aktualisierte Assets abzurufen. Gründe hierfür können Updates Ihrer Webanwendung oder eine schnelle Aktualisierung von Ressourcen sein, die falsche Informationen enthalten.

Wählen Sie die Ressourcen aus, die Sie von den Edgeknoten löschen möchten. Wählen Sie Alles löschen aus, um alle Ressourcen zu löschen. Andernfalls geben Sie in Pfad den Pfad jeder Ressource ein, die Sie bereinigen möchten.

Diese Formate werden in der Liste der zu löschenden Pfade unterstützt:

• Löschen eines einzelnen Pfads: Löschen Sie einzelne Ressourcen, indem Sie den vollständigen Pfad der Ressource, ohne Protokoll und Domäne, aber mit der Dateierweiterung angeben. Beispiel: /pictures/strasbourg.png.
• Mit Platzhalter löschen: Das Sternchen (*) kann als Platzhalterzeichen verwendet werden. Löschen Sie alle Ordner, Unterordner und Dateien unter einem Endpunkt, indem Sie „/*“ im Pfad angeben, oder löschen Sie alle Unterordner und Dateien unter einem bestimmten Ordner, indem Sie den Ordner gefolgt von „/*“ angeben. Beispiel: „/pictures/*“.
• Stammdomäne löschen: Löschen Sie den Stamm des Endpunkts, indem Sie „/“ im Pfad angeben.

Hinweis

Löschen von Platzhalterdomänen: Das Angeben zwischengespeicherter Pfade für das Löschen, wie in diesem Abschnitt beschrieben, gilt nicht für Platzhalterdomänen, die mit Front Door verknüpft sind. Derzeit wird das direkte Löschen von Platzhalterdomänen nicht unterstützt. Sie können Pfade aus bestimmten Unterdomänen löschen, indem Sie die jeweilige Unterdomäne und den Löschpfad angeben. Wenn meine Front Door-Instanz beispielsweise *.contoso.com aufweist, kann ich Ressourcen meiner Unterdomäne foo.contoso.com bereinigen, indem ich foo.contoso.com/path/* eingebe. Gegenwärtig ist die Angabe von Hostnamen im Pfad für die Bereinigung von Inhalten ggf. auf Unterdomänen von Platzhalterdomänen beschränkt.

Bei Cachebereinigungen in Azure Front Door Service muss die Groß-/Kleinschreibung beachtet werden. Darüber hinaus sind Cachebereinigungen abfragezeichenfolgenagnostisch, d. h. beim Bereinigen einer URL werden alle Variationen der Abfragezeichenfolge der URL gelöscht.

Cacheablauf

Die folgende Reihenfolge der Header wird verwendet, um zu bestimmen, wie lange ein Element in unserem Cache gespeichert wird:

1. Cache-Control: s-maxage=<seconds>
2. Cache-Control: max-age=<seconds>
3. Expires: <http-date>

Einige Cache-Control-Antwortheaderwerte weisen darauf hin, dass die Antwort nicht zwischengespeichert werden kann. Diese Werte schließen Folgendes ein: private, no-cache, und no-store. Front Door respektiert diese Headerwerte und speichert die Antworten nicht zwischen, auch wenn Sie das Zwischenspeichernverhalten mithilfe der Regel-Engine außer Kraft setzen.

Wenn der Cache-Control-Header in der Antwort vom Ursprung nicht vorhanden ist, bestimmt Front Door standardmäßig nach dem Zufallsprinzip eine Aufbewahrungsdauer im Cache zwischen einem und drei Tagen.

Hinweis

Der Cacheablauf darf nicht größer als366 Tage sein.

Möglicherweise wird REVALIDATED_HIT im Cache-Control -Antwortheader angezeigt. Dies gibt an, dass der zwischengespeicherte Inhalt in Azure Front Door mit dem Ursprungsserver neu überprüft wurde, bevor er dem Client bereitgestellt wird. Dies kann passieren, wenn der zwischengespeicherte Inhalt abgelaufen ist, aber der Ursprungsserver angibt, dass der Inhalt nicht geändert wurde. In diesem Fall wird der zwischengespeicherte Inhalt dem Client bereitgestellt, und der Cacheablauf wird zurückgesetzt.

Anforderungsheader

Die folgenden Anforderungsheader werden nicht an den Ursprung weitergeleitet, wenn das Zwischenspeichern aktiviert ist:

• Content-Length
• Transfer-Encoding
• Accept
• Accept-Charset
• Accept-Language

Antwortheader

Wenn die Antwort des Ursprungs zwischengespeichert werden kann, wird der Set-Cookie-Header entfernt, bevor die Antwort an den Client gesendet wird. Wenn eine Antwort vom Ursprungs nicht zwischengespeichert werden kann, entfernt Front Door den Header nicht. Wenn die Antwort des Ursprungs beispielsweise einen Cache-Control-Header mit einem max-age-Wert enthält, bedeutet dies für Front Door, dass die Antwort zwischengespeichert werden kann, und der Set-Cookie-Header wird entfernt.

Darüber hinaus fügt Front Door den X-Cache-Header an alle Antworten an. Der X-Cache-Antwortheader enthält einen der folgenden Werte:

• TCP_HIT oder TCP_REMOTE_HIT: Der erste 8 MB-Block der Antwort ist ein Cachetreffer und der Inhalt wird aus dem Front Door-Cache bereitgestellt.
• TCP_MISS: Der erste 8 MB-Block der Antwort ist ein Cachefehler und der Inhalt wird vom Ursprung abgerufen.
• PRIVATE_NOSTORE: Die Anforderung kann nicht zwischengespeichert werden, da der Cache-Control-Antwortheader auf private oder no-store festgelegt ist.
• CONFIG_NOCACHE: Die Anforderung ist so konfiguriert, dass sie nicht im Front Door-Profil zwischengespeichert wird.

Protokolle und Berichte

Das Zugriffsprotokoll enthält den Cachestatus für jede Anforderung. Außerdem enthalten Berichte Informationen darüber, wie der Azure Front Door-Cache in Ihrer Anwendung verwendet wird.

Das Zugriffsprotokoll enthält den Cachestatus für jede Anforderung.

Cacheverhalten und -dauer

Cacheverhalten und -dauer können im Regelmodul konfiguriert werden. Die Konfiguration des Zwischenspeichers im Regelmodul hat immer Vorrang vor der Routen-Konfiguration.

• Wenn das Zwischenspeichern deaktiviert ist, speichert Azure Front Door den Inhalt der Antwort unabhängig von den Anweisungen der Antwort vom Ursprung nicht zwischen.

• Wenn das Zwischenspeichern aktiviert ist, entspricht das Cacheverhalten dem Wert für das Cacheverhalten, der vom Regelmodul festgelegt wird:

  • Respektieren des Ursprungs: Front Door respektiert immer die Anweisung im Antwortheader des Ursprungs. Wenn die Anweisung des Ursprungs fehlt, speichert Azure Front Door Inhalte ein bis drei Tage lang zwischen.
  • Immer überschreiben: Azure Front Door überschreibt die Cachedauer immer. Das bedeutet, dass es die Inhalte für die Cachedauer zwischengespeichert und die Werte der Anweisungen der Ursprungsantwort ignoriert. Dieses Verhalten gilt nur, wenn die Antwort zwischengespeichert werden kann.
  • Überschreiben, wenn der Ursprung fehlt: Wenn der Ursprung keine TTL-Werte für das Zwischenspeichern zurückgibt, verwendet Azure Front Door die angegebene Cachedauer. Dieses Verhalten gilt nur, wenn die Antwort zwischengespeichert werden kann.

Hinweis

• Azure Front Door garantiert nicht, wie lange der Inhalt im Cache gespeichert wird. Zwischengespeicherte Inhalte können vor dem Ablauf des Inhalts aus dem Edgecache entfernt werden, wenn der Inhalt nicht häufig verwendet wird. Front Door kann möglicherweise auch dann Daten aus dem Cache anbieten, wenn die zwischengespeicherten Daten abgelaufen sind. Dieses Verhalten kann dazu beitragen, dass Ihre Website teilweise verfügbar bleibt, wenn Ihre Ursprünge offline sind.
• Ursprünge können angeben, dass bestimmte Antworten nicht zwischengespeichert werden, indem der Cache-Control-Header mit dem Wert „no-cache“, „private“ oder „no-store“ verwendet wird. Bei Verwendung in einer HTTP-Antwort vom Ursprungsserver an die Azure Front Door-POPs unterstützt Azure Front Door Cachesteuerungsanweisungen und berücksichtigt das Verhalten bei Zwischenspeicherung für Cachesteuerungsanweisungen in RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Caching (ietf.org).

Cacheverhalten und Cachedauer können sowohl in der Front Door-Designer-Routingregel als auch in der Regel-Engine konfiguriert werden. Die Zwischenspeichernkonfiguration der Regel-Engine überschreibt immer die Konfiguration der Front Door-Designer-Routingregel.

• Wenn das Zwischenspeichern deaktiviert ist, speichert Azure Front Door (klassisch) den Inhalt der Antwort unabhängig von den Anweisungen der Antwort vom Ursprung nicht zwischen.

• Wenn das Zwischenspeichern aktiviert ist, unterscheidet sich das Zwischenspeicherverhalten je nachdem, welcher Wert für Standardcachedauer verwenden verwendet wird.

  • Wenn Standardcachedauer verwenden auf Ja festgelegt ist, berücksichtigt Azure Front Door (klassisch) immer die Anweisung im Antwortheader des Ursprungs. Wenn die Anweisung des Ursprungs fehlt, speichert Front Door Inhalte ein bis drei Tage lang zwischen.
  • Wenn Standardcachedauer verwenden auf Nein festgelegt ist, überschreibt Azure Front Door (klassisch) immer die Cachedauer (erforderliche Felder), was bedeutet, dass es die Inhalte für die Cachedauer zwischenspeichert und die Werte aus den Anweisungen der Ursprungsantwort ignoriert.

Hinweis

• Azure Front Door (klassisch) garantiert nicht, wie lange der Inhalt im Cache gespeichert wird. Zwischengespeicherte Inhalte können vor dem Ablauf des Inhalts aus dem Edgecache entfernt werden, wenn der Inhalt nicht häufig verwendet wird. Azure Front Door (klassisch) kann möglicherweise auch dann Daten aus dem Cache anbieten, wenn die zwischengespeicherten Daten abgelaufen sind. Dieses Verhalten kann dazu beitragen, dass Ihre Website teilweise verfügbar bleibt, wenn Ihre Ursprünge offline sind.
• Die in der Front Door-Designer-Routingregel festgelegte Cachedauer ist die minimale Cachedauer. Diese Außerkraftsetzung funktioniert nicht, wenn der Cachesteuerungsheader vom Ursprung eine längere Gültigkeitsdauer aufweist als der Außerkraftsetzungswert.

Nächste Schritte

• Erfahren Sie, wie Sie ein Profil für Azure Front Door (klassisch) erstellen.
• Erfahren Sie, wie Azure Front Door (klassisch) funktioniert.

• Weitere Informationen zu Vergleichsbedingungen für Regelsätze
• Weitere Informationen über Regelsatzaktionen