Caching-Verhalten konfigurieren

Media CDN stellt Inhalte so nah wie möglich an den Nutzern bereit, indem es die globale Edge-Caching-Infrastruktur von Google nutzt, um Inhalte im Cache zu speichern und die Belastung der Ursprungsinfrastruktur zu reduzieren.

Sie können steuern, wie die Inhalte für jede Route im Cache gespeichert werden. So können Sie Ihre je nach Inhaltstyp, Client-Anfrageattributen und Anforderungen an die Aktualität.

Cache-Fähigkeit

In den folgenden Abschnitten wird beschrieben, welche Antworten Media CDN im Cache speichert und wie die Cache-Auslagerung verbessert werden kann.

Standard-Caching-Verhalten

Standardmäßig gelten für jeden Edge-Cache-Dienst die folgenden cachebezogenen Einstellungen:

  • Der Standard-Cache-Modus CACHE_ALL_STATIC:

    • Berücksichtigt Ursprungscache-Anweisungen wie Cache-Control oder Expires bis zu einer konfigurierbaren maximalen TTL.
    • Speichert statische Medientypen automatisch im Cache, mit einer Standard-TTL von 3.600 Sekunden, wenn keine Cache-Anweisungen für den Ursprung vorhanden sind.
    • Speichert HTTP 200- und HTTP 206-Statuscodes im Cache (negatives Caching ist nicht aktiviert).

  • Antworten mit der Cache-Steuerung no-store oder private werden nicht im Cache gespeichert oder anders im Cache speicherbar sind.

Antworten, die keine statischen Inhalte sind oder bei denen gültige Cache-Anweisungen fehlen, werden nur dann im Cache gespeichert, wenn das Caching explizit konfiguriert ist. Informationen zum Überschreiben des Standardverhaltens finden Sie in der Dokumentation zu Cache-Modi.

Das Standardverhalten entspricht folgender cdnPolicy. Routen ohne explizit konfigurierte cdnPolicy verhalten sich so, als hätten sie die folgende Konfiguration:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

Cachefähige Antworten

Eine cachefähige Antwort ist eine HTTP-Antwort, die von Media CDN gespeichert und schnell abgerufen werden kann. Dies ermöglicht schnellere Ladezeiten. Nicht alle HTTP-Antworten sind cachefähig.

Sie können für jede Route Cache-Modi konfigurieren, um dieses Verhalten zu überschreiben (z. B. mit dem Cache-Modus CACHE_ALL_STATIC, um gängige Medientypen im Cache zu speichern), auch wenn der Ursprung keine Cache-Steuerungsanweisung in der Antwort festlegt.

Anfragen und Antworten, die die in nicht cachefähige Antworten definierten Kriterien erfüllen, ersetzen die Cachefähigkeit.

In der folgenden Tabelle werden die Anforderungen zum Zwischenspeichern bestimmter HTTP- Antworten. Sowohl die GET- als auch die HEAD-Antwort müssen diesen Anforderungen entsprechen.

HTTP-Attribut Voraussetzungen
Status code Der Antwortstatuscode muss einer der folgenden sein: 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 oder 504.
HTTP-Methoden GET und HEAD
Anfrageheader Die meisten Anweisungen für Caching-Anfragen werden ignoriert. Weitere Informationen finden Sie unter Cache-Steuerungsanweisungen.
Antwortheader

Enthält ein gültiges HTTP-Caching -Anweisung wie zum Beispiel Cache-Control: max-age=3600, public.

Hat einen Cache-Modus, der diese Inhalte im Cache speichert, oder einen Expires-Header mit einem Datum in der Zukunft.
Antwortgröße Bis zu 100 GiB.

Der HTTP-Age-Header wird basierend auf dem Zeitpunkt festgelegt, zu dem Media CDN die Antwort zum ersten Mal im Cache gespeichert hat, und stellt in der Regel die Sekunden dar, seit das Objekt am Standort der Ursprungsabschirmung im Cache gespeichert wurde. Wenn Ihr Ursprung einen "Age"-Antwortheader generiert, verwenden Sie den Cache-Modus FORCE_CACHE_ALL, um Neuvalidierungen zu verhindern, wenn "Age" die Cache-TTL überschreitet.

Weitere Informationen dazu, wie Media CDN HTTP-Caching-Anweisungen interpretiert, finden Sie unter Cache-Steuerungsanweisungen.

Anforderungen an den Ursprung

Damit Media CDN Ursprungsantworten mit einer Größe von mehr als 1 MiB im Cache speichern kann, muss ein Ursprung in den Antwortheadern für HEAD- und GET-Anfragen Folgendes enthalten, sofern nicht anders angegeben:

  • Einen Last-Modified- oder ETag-HTTP-Antwortheader (Validator).
  • Einen gültiger HTTP-Date-Header.
  • Einen gültigen Content-Length-Header.
  • Den Content-Range-Antwortheader als Antwort auf eine Range GET-Anfrage. Der Header Content-Range muss einen gültigen Wert im Format bytes x-y/z haben (wobei z die Objektgröße ist).

Das Standardprotokoll für den Ursprung ist HTTP/2. Wenn Ihre Quellen nur HTTP/1.1 unterstützen, können Sie das Protokollfeld explizit für jeden Ursprung festlegen.

Nicht cachefähige Antworten

In der folgenden Tabelle sind die Anfrage- und Antwortattribute aufgeführt, die verhindern, dass eine Antwort im Cache gespeichert wird. Antworten, die cachefähig sind, aber mit einem „nicht cachefähig“-Kriterium übereinstimmen, werden nicht im Cache gespeichert.

HTTP-Attribut Anforderung
Status code

Einen anderen Statuscode als den, der nicht als im Cache speicherbar definiert ist, z. B. HTTP 401, HTTP 412 oder HTTP 505.

Diese Statuscodes sind in der Regel repräsentativ für kundenbezogene Probleme. und nicht den Ursprungsstatus. Das Caching dieser Antworten kann zu „Cache-Poisoning“-Szenarien führen, bei denen eine vom Nutzer ausgelöste „fehlerhafte“ Antwort für alle Nutzer im Cache gespeichert wird.
Anfrageheader

Bei Anfragen mit einem Authorization-Anfrageheader müssen Antworten eine public-Cache-Steuerungsanweisung enthalten, um im Cache gespeichert zu werden.

Die Anweisung no-store in der Anfrage führt dazu, dass nicht zwischengespeichert werden soll. Weitere Informationen finden Sie unter Anweisungen zur Cache-Steuerung.
Antwortheader

Hat einen Set-Cookie-Header.

Sie hat einen Vary-Header, der nicht Accept, Accept-Encoding, Origin, X-Origin, X-Goog-Allowed-Resources, Sec-Fetch-Dest, Sec-Fetch-Mode oder Sec-Fetch-Site ist.

In CACHE_ALL_STATIC oder Modus „USE_ORIGIN_HEADERS“, hat eine no-store oder private-Anweisung zur Cachesteuerung.
Antwortgröße Größer als 100 GiB.

Diese Regeln gelten zusätzlich zum konfigurierten Cache-Modus. Zum Beispiel:

  • Wenn der Cache-Modus CACHE_ALL_STATIC konfiguriert ist, werden nur Antworten statische Inhalte oder Antworten mit gültige Cache-Anweisungen in ihren Antwortheadern im Cache gespeichert werden. Andere Antworten werden unverändert weitergeleitet.
  • Im Cache-Modus FORCE_CACHE_ALL werden alle Antworten bedingungslos im Cache gespeichert, vorbehaltlich der oben genannten Anforderungen an die Nicht-Cachebarkeit.
  • Im Cache-Modus USE_ORIGIN_HEADERS müssen Antworten zusätzlich zu einem cachefähigen Statuscode gültige Cache-Anweisungen in ihren Antwort-Headern festlegen.

Hinweise:

  • Für nicht im Cache gespeicherte Antworten sind keine Anweisungen zur Cache-Steuerung oder andere Header geändert und unverändert weitergeleitet werden.
  • Die Cache-Control- und Expires-Header von Antworten können in einem einzigen Cache-Control-Feld minimiert werden. Eine Antwort mit Cache-Control: public und Cache-Control: max-age=100 in separaten Zeilen wird als Cache-Control: public,max-age=100 minimiert.
  • Nicht im Cache speicherbare Antworten (Antworten, die nie im Cache gespeichert würden) werden nicht gezählt Aus Abrechnungsperspektive als Cache Egress.

Cache-Modi verwenden

Mit Cache-Modi können Sie festlegen, wann Media CDN Ursprungs-Cache-Anweisungen, Cache für statische Medientypen und Speichern aller Antworten im Cache vom Ursprung entfernt, unabhängig von den festgelegten Anweisungen.

Cache-Modi werden auf der Routenebene konfiguriert und ermöglichen Ihnen, in Kombination mit TTL-Überschreibungen, das Cache-Verhalten nach Host, Pfad, Abfrageparametern und Headern (beliebige vergleichbare Anfrageparameter) zu konfigurieren.

  • Standardmäßig verwendet Media CDN den Cache-Modus CACHE_ALL_STATIC, der gängige statische Medientypen automatisch für 1 Stunde (3.600 Sekunden) im Cache speichert. Dabei werden alle vom Ursprung für cachefähige Antworten angegebenen Cache-Anweisungen priorisiert.
  • Sie können die auf Antworten angewendete Cache-TTL erhöhen oder verringern, ohne dass dafür eine Cache-TTL (eine max-age- oder s-maxage-Anweisung) explizit festgelegt sein muss. Dazu legen Sie das Feld cdnPolicy.defaultTtl auf einer Route fest.
  • Um zu verhindern, dass nicht erfolgreiche Antworten länger als beabsichtigt im Cache gespeichert werden, Statuscodes, die nicht 2xx (nicht erfolgreich) sind, werden gemäß ihrer Content-Type (MIME-Typ) und haben nicht die Standard-TTL angewendet.

Die verfügbaren Cache-Modi, die im cdnPolicy.cacheMode der einzelnen Modi festgelegt werden werden in der folgenden Tabelle dargestellt.

Cache-Modus Verhalten
USE_ORIGIN_HEADERS Erfordert Ursprungsantworten, um gültige Cache-Anweisungen und gültige Caching-Header festzulegen. Eine vollständige Liste der Anforderungen finden Sie unter Im Cache speicherbare Antworten:
CACHE_ALL_STATIC

Erfolgreiche Antworten mit statischem Inhalt werden automatisch im Cache es sei denn, sie haben no-store oder private . Gültige Caching-Anweisungen vom Ursprung werden priorisiert.

Statische Inhalte umfassen Video-, Audio-, Bild- und Standardinhalte sowie definiert durch den MIME-Typ in der Content-Type-Antwort Header.
FORCE_CACHE_ALL

Erfolgreiche Antworten werden bedingungslos im Cache gespeichert, wodurch der Cache überschrieben wird. Anweisungen des Ursprungsorts.

Achten Sie darauf, dass keine privaten, nutzerspezifischen Inhalte (wie dynamische HTML- oder API-Antworten) bereitgestellt werden, wenn dieser Modus konfiguriert ist.
BYPASS_CACHE

Jede Anfrage, die mit einer Route übereinstimmt, die in diesem Cache-Modus konfiguriert ist, wird umgangen selbst wenn ein Objekt im Cache vorhanden ist, das mit dem Cache-Schlüssel übereinstimmt.

Wir empfehlen, es nur für das Debugging zu verwenden, da Media CDN ist eine weltumspannende Cache-Infrastruktur und kein allgemeiner Zweck. Proxy.

MIME-Typen für statische Inhalte

Der Cache-Modus CACHE_ALL_STATIC erlaubt Media CDN, gängige statische Inhalte wie Videos, Audio, Bilder und allgemeine Web-Assets automatisch im Cache zu speichern, basierend auf dem im Content-Type-HTTP-Antwortheader zurückgegebenen MIME-Typ. Unabhängig vom Medientyp zeigt Media CDN jedoch priorisiert alle expliziten Cache-Control- oder Expires-Header im Ursprung Antwort.

In der folgenden Tabelle sind die MIME-Typen aufgeführt, die mit dem Cache-Modus CACHE_ALL_STATIC automatisch im Cache gespeichert werden können.

Antworten ohne Content-Type werden nicht automatisch im Cache gespeichert Antwortheader mit einem Wert, der den folgenden Werten entspricht. Sie müssen sicherstellen, Die Antwort legt eine gültige Cache-Anweisung fest. müssen Sie den Cache-Modus FORCE_CACHE_ALL verwenden, um Antworten.

Kategorie MIME-Typen
Web-Assets text/css text/ecmascript text/javascript application/javascript
Schriftarten Alle Inhaltstypen, die mit font/* übereinstimmen
Bilder Alle Inhaltstypen, die mit image/* übereinstimmen
Videos Alle Inhaltstypen, die mit video/* übereinstimmen
Audio Alle Inhaltstypen, die mit audio/* übereinstimmen
Formatierte Dokumenttypen application/pdf and application/postscript

Hinweis:

  • Die Webserversoftware Ihres Ursprungs muss den Content-Type für jede Antwort festlegen. Viele Webserver legen automatisch den Header Content-Type fest, einschließlich NGINX, Varnish und Apache.
  • Cloud Storage legt den Header Content-Type automatisch beim Upload fest, wenn Sie die Google Cloud Console oder die gcloud-Befehlszeile zum Hochladen von Inhalten verwenden.
  • Wenn eine Antwort aufgrund ihres MIME-Typs im Cache gespeichert werden kann, aber die Cache-Control-Antwortanweisung private oder no-store oder einen Set-Cookie-Header hat, wird sie nicht im Cache gespeichert.

Cache-TTLs konfigurieren

Mit Gültigkeitsdauer-Überschreibungen (Time to Live, TTL) können Sie Standard-TTL-Werte für im Cache gespeicherte Inhalte festlegen und TTL-Werte überschreiben, die in den Cache-Steuerungsanweisungen max-age und s-maxage (oder Expires-Headern) festgelegt sind, die durch Ihre Ursprünge festgelegt sind.

TTLs, ob durch Überschreibungen oder mithilfe einer Cache-Anweisung, optimistisch. Inhalte, auf die selten zugegriffen wird oder die unbeliebt sind, werden möglicherweise aus bevor die TTL erreicht wurde.

Die folgende Tabelle zeigt drei TTL-Einstellungen.

Einstellung Standard Minimum Maximum Beschreibung Anwendbare Cache-Modi
Default TTL 1 Stunde
(3.600 Sekunden)		 0 Sekunden 1 Jahr
(31.536.000 Sekunden)

Die TTL, die festgelegt werden soll, wenn der Ursprung keinen max-age- oder s-maxage-Header angegeben hat.

Wenn der Ursprung einen s-maxage-Header angibt, wird dieser hier anstelle des Standard-TTL-Werts verwendet.

Wenn Sie FORCE_CACHE_ALL verwenden, um alle Antworten enthält, wird die Standard-TTL zum Festlegen der Cache-TTL verwendet. Alle anderen Werte und Anweisungen ignoriert.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
Max TTL 1 Tag
(86.400 Sekunden)		 0 Sekunden 1 Jahr
(31.536.000 Sekunden)		 Die maximal zulässige TTL für im Cache speicherbare Antworten. Werte über diesem Wert werden auf maxTtl begrenzt. CACHE_ALL_STATIC
Client TTL Nicht standardmäßig festgelegt. 0 Sekunden 1 Tag
(86.400 Sekunden)		 Die maximal zulässige TTL für im Cache speicherbare Antworten im Downstream (clientseitige) Antwort, wenn diese sich von der anderen TTL unterscheiden muss Werte.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

Wenn Sie einen beliebigen TTL-Wert auf null (0 Sekunden) setzen, wird jede Anfrage neu validiert. mit dem Ursprung, bevor eine Antwort bereitgestellt wird, und erhöht die Last auf den Ursprung, wenn zu breit gefasst sind.

Wenn der Cache-Modus auf Use Origin Headers festgelegt ist, können keine TTL-Einstellungen konfiguriert werden, da Media CDN sich auf den Ursprung verlässt, um das Verhalten zu steuern.

Hinweise:

  • Der Wert für die maximale TTL muss immer größer als der (oder gleich dem) Wert der Standard-TTL sein.
  • Der Wert für die Client-TTL muss immer kleiner als der (oder gleich dem) Wert der maximalen TTL sein.
  • Wenn Media CDN einen Ursprungs-TTL-Wert überschreibt, wird der Der Cache-Control-Header für den Client gibt ebenfalls diesen Wert wieder.
  • Wenn der Ursprung einen Expires-Header festlegt und Media CDN die effektive TTL (basierend auf dem Zeitstempel) überschreibt, wird der Expires-Header in der nachgelagerten Antwort an den Client durch einen Cache-Control-Header ersetzt.

Negatives Caching

Negatives Caching definiert, wie nicht erfolgreiche HTTP-Statuscodes (andere als 2xx) von Media CDN im Cache gespeichert werden.

So können Sie Fehlerantworten wie Weiterleitungen (HTTP 301 und 308) und „Nicht gefunden“-Antworten (HTTP 404) näher an den Nutzern im Cache speichern sowie die Ursprungslast umfassender reduzieren, wenn sich die Antwort wahrscheinlich nicht ändert und im Cache gespeichert werden kann.

Standardmäßig ist das negative Caching deaktiviert. Die folgende Tabelle zeigt die Standardwerte für jeden Statuscode, wenn negatives Caching aktiviert und negativeCachingPolicy nicht verwendet wird.

Statuscodes Reason-phrase TTL
HTTP 300 Mehrfachauswahl 10 Minuten
HTTP 301 und HTTP 308 Permanente Weiterleitung 10 Minuten
HTTP 404 Nicht gefunden 120 Sekunden
HTTP 405 Methode nicht gefunden 60 Sekunden
HTTP 410 Gone (Nicht mehr vorhanden) 120 Sekunden
HTTP 451 Aus rechtlichen Gründen nicht verfügbar 120 Sekunden
HTTP 501 Nicht implementiert 60 Sekunden

Der Standardsatz negativer Caching-Codes entspricht den in HTTP RFC 9110 beschriebenen heuristisch cachefähigen Statuscodes, mit folgenden Ausnahmen:

  • HTTP-Code 414 (URI zu lang) wird für das Caching nicht unterstützt, um den Cache zu umgehen Vergiftung.
  • HTTP-Code 451 (Aus rechtlichen Gründen nicht verfügbar) wird für das Caching unterstützt, wie in HTTP RFC 7725 beschrieben.

Wenn Sie Ihre eigenen TTLs pro Statuscode konfigurieren und das Standardverhalten überschreiben müssen, können Sie eine cdnPolicy.negativeCachingPolicy konfigurieren. Auf diese Weise können Sie die TTL für jeden der von Media CDN zugelassenen Statuscodes festlegen: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 und 504.

Wenn Sie beispielsweise eine kurze 5-Sekunden-TTL für HTTP 404-Antworten (Nicht gefunden) und eine 10-Sekunden-TTL für HTTP 405-Antworten (Methode nicht zulässig) festlegen möchten, verwenden Sie die folgende YAML-Definition für jede anwendbare Route:

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

Um Cache-Poisoning zu verhindern, empfehlen wir, das Caching für den Statuscode 400 (Fehlerhafte Anfrage) oder 403 (Unzulässig) nicht zu aktivieren. Sollte Ihr Ursprungsserver einen dieser beiden Codes zurückgeben, achten Sie darauf, dass es sich dabei um das Ergebnis der Untersuchung ausschließlich jener Komponenten der Anfrage handelt, die im Cache-Schlüssel enthalten sind. Cache-Poisoning kann beispielsweise auftreten, wenn in Ermangelung eines korrekten Authorization-Headers der Ursprungsserver mit einer 403-Fehlerantwort antwortet. In diesem Fall führt das Speichern der 403-Fehlerantwort im Cache dazu, dass Media CDN die 403-Fehlerantwort allen nachfolgenden Anfragen bereitstellt, bis die TTL abläuft, auch wenn die Anfragen einen korrekten Authorization-Header haben.

So deaktivieren Sie negatives Caching:

  • Wenn Sie das Standardverhalten für das negative Caching deaktivieren möchten, legen Sie für eine Route cdnPolicy.negativeCaching: false fest. Ursprungsantworten mit gültigen Cache-Anweisungen und Cache-Statuscodes werden weiterhin im Cache gespeichert.
  • Wenn Sie negatives Caching für einen bestimmten Statuscode verhindern, aber trotzdem Ursprungscache-Anweisungen berücksichtigen möchten, lassen Sie den Statuscode (cdnPolicy.negativeCachingPolicy[].code) in Ihrer negativeCachingPolicy-Definition weg.
  • Zum expliziten Ignorieren der Ursprungs-Cache-Anweisungen für einen bestimmten Status , setzen Sie cdnPolicy.negativeCachingPolicy[].ttl auf 0 (null) Statuscode enthalten.

Hinweise:

  • Wenn negativeCaching für eine Route aktiviert ist und eine Antwort definiert gültige Cache-Anweisungen, die Cache-Anweisungen in der haben Vorrang.
  • Wenn Sie eine explizite negativeCachingPolicy konfigurieren und für den angegebenen Statuscode eine TTL definiert ist, wird immer die in der Richtlinie definierte TTL verwendet.
  • Der maximale Wert für eine TTL, die mit negativeCachingPolicy festgelegt wird, beträgt 1.800 Sekunden (30 Minuten). Cache-Anweisungen für den Ursprung mit einer höheren TTL werden jedoch berücksichtigt.
  • Wenn der Cache-Modus als FORCE_CACHE_ALL konfiguriert ist, werden Ursprungsanweisungen in allen Fällen ignoriert.

Anweisungen zur Cache-Steuerung

Das Verhalten von Media CDN im Hinblick auf Cache-Control-Anweisungen wird hier definiert.

Wenn die Anweisung nicht auf eine Anforderung oder Antwort anwendbar ist, wie z. B. only-if-cached (eine ausschließlich clientseitige Anweisung), dann „–“ in dieser Spalte markiert ist.

Anweisung Anfrage Antwort
no-cache Die Anfrageanweisung no-cache wird ignoriert, um zu verhindern, dass Clients den Ursprung möglicherweise initiieren oder dessen nochmalige Validierung erzwingen.

Eine Antwort mit no-cache wird im Cache gespeichert, erfordert jedoch Validierung mit dem Ursprung vornehmen, bevor er geliefert werden kann.

Dies kann für einzelne Routen mit dem Cache-Modus FORCE_CACHE_ALL überschrieben werden.
no-store Die Antwort auf eine Anfrage mit no-store wird nicht im Cache gespeichert.

Eine Antwort mit no-store wird nicht im Cache gespeichert.

Dies kann für einzelne Routen mit dem Cache-Modus FORCE_CACHE_ALL überschrieben werden.
public –

Eine Antwort mit der Anweisung public wird im Cache gespeichert, wenn der Die Antwort wird als Ganzes als cachefähig erachtet und die Antwort wird eine max-age- oder eine s-maxage-Anweisung als gut.

Bei Verwendung des CACHE_ALL_STATIC-Cache oder FORCE_CACHE_ALL-Modi, nicht erforderlich.
private –

Eine Antwort mit der Anweisung private wird von Media CDN, auch wenn die Antwort anderweitig berücksichtigt wird Cache-fähig sind. Clients wie Browser können das Ergebnis jedoch weiterhin im Cache speichern.

Dies kann für einzelne Routen mit dem FORCE_CACHE_ALL-Cache-Modus.

Verwenden Sie no-store, um das gesamte Caching der Antworten zu verhindern.
max-age=SECONDS Die Anfrageanweisung „max-age“ wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. Eine Antwort mit der Anweisung max-age wird bis zu die definierten SECONDS.
s-maxage=SECONDS –

Eine Antwort mit der Anweisung s-maxage wird bis zu die definierten SECONDS.

Wenn sowohl max-age als auch s-maxage vorhanden sind, wird vom Server s-maxage verwendet.

Hinweis: s-max-age (zwei Bindestriche) ist für das Caching nicht anwendbar.
min-fresh=SECONDS Die Anfrageanweisung min-fresh wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. –
max-stale=SECONDS

Die Anfrageanweisung max-stale wird ignoriert.

Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten.

 –
stale-while-revalidate=SECONDS – Keine Auswirkungen. Dies wird in der Antwort an den Client weitergegeben.
stale-if-error=SECONDS Die Anfrageanweisung stale-if-error wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. Keine Auswirkungen. Dies wird in der Antwort an den Client weitergegeben.
must-revalidate –

Eine Antwort mit must-revalidate wird nach dem Ablauf noch einmal mit dem Ursprungsserver validiert.
proxy-revalidate –

Eine Antwort mit proxy-revalidate wird nach dem Ablauf noch einmal mit dem Ursprungsserver validiert.
immutable – Keine Auswirkungen. Dies wird in der Antwort an den Client weitergegeben.
no-transform – Media CDN wendet keine Transformationen an.
only-if-cached Die Anfrageanweisung only-if-cached wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. –

Sofern möglich, ist Media CDN RFC-konform (HTTP RFC 7234), aber bevorzugt. Optimierung im Hinblick auf die Cache-Auslagerung und Minimierung der Auswirkungen der Clients auf die Trefferrate und den Gesamtlasten des Ursprungsservers.

Für Antworten, die den HTTP/1.1-Header Expires verwenden:

  • Der Wert des Expires-Headers muss ein gültiges HTTP-Datum sein, wie in RFC 7231 definiert.
  • Ein Datumswert in der Vergangenheit, ein ungültiges Datum oder der Wert 0 bedeutet, dass Der Inhalt ist bereits abgelaufen und muss noch einmal überprüft werden.
  • Media CDN ignoriert den Expires-Header, wenn ein Cache-Control -Header in der Antwort vorhanden ist.

Der HTTP/1.0-Header Pragma, falls in einer Antwort vorhanden, wird ignoriert und übergeben. unverändert an die Kundschaft übermittelt.

Cache-Schlüssel

Sie können die Häufigkeit reduzieren, mit der Media CDN Ihre Website kontaktieren muss indem Sie die eindeutige Identifizierung einer Anfrage berücksichtigen, und Komponenten, die sich zwischen Anfragen oft ändern können. Der Satz von Anfragekomponenten wird oft als "Cache-Schlüssel" bezeichnet.

In den folgenden Abschnitten wird beschrieben, wie Sie Cacheschlüssel konfigurieren.

Cache-Schlüsselkomponenten

Bei einem Cache-Schlüssel handelt es sich um eine Reihe von Anfrageparametern (z. B. den Host, den Pfad und Abfrageparameter), über die auf ein im Cache gespeichertes Objekt verwiesen wird.

Standardmäßig enthalten Cache-Schlüssel für Edge-Cache-Dienste den Anfragehost, den Pfad und die Abfrageparameter aus der Anfrage und sind auf einen bestimmten EdgeCacheService beschränkt.

Komponente Standardmäßig enthalten? Details
Protokoll Nein

Anfragen über HTTP und HTTPS verweisen auf dasselbe im Cache gespeicherte Objekt.

Wenn Sie die verschiedenen Antworten auf HTTP- und HTTPS-Anfragen zurückgeben möchten, setzen Sie auf den zugehörigen Routen cacheKeyPolicy.includeProtocol auf "true".
Moderator:in Ja

Verschiedene Hosts verweisen nicht auf dieselben im Cache gespeicherten Objekte.

Wenn Sie mehrere Hostnamen für denselben EdgeCacheService haben und diese dieselben Inhalte bereitstellen, setzen Sie cdnPolicy.excludeHost auf "true".
Pfad Ja Wird immer in den Cache-Schlüssel eingeschlossen und kann nicht entfernt werden. Der Pfad ist der Mindestdarstellung eines Objekts im Cache.
Anfrageparameter Ja

Wenn Suchparameter nicht zwischen verschiedenen Antworten unterscheiden, Setzen Sie cacheKeyPolicy.excludeQueryString auf „true“.

Wenn nur einige Abfrageparameter in einem Cache-Schlüssel enthalten sein sollen, legen Sie includedQueryParameters oder excludedQueryParameters.
Header Nein

Legen Sie cacheKeyPolicy.includedHeaderNames mit den Namen der Header fest, die in den Cache-Schlüssel einbezogen werden sollen.

Wenn Sie mehrere Header angeben, die insgesamt einen großen Wertebereich umfassen (z. B. identifizieren die kombinierten Headerwerte einen einzelnen Nutzer), wird die Cache-Trefferquote drastisch verringert. Dies kann zu einer höheren Entfernungsrate und reduzierter Leistung führen.
Cookies Nein

Legen Sie cacheKeyPolicy.includedCookieNames mit den Namen der Cookies fest, die in den Cache-Schlüssel einbezogen werden sollen.

Wenn Sie mehrere Cookies angeben, die insgesamt einen großen Wertebereich umfassen (z. B. identifizieren die kombinierten Cookiewerte einen einzelnen Nutzer), wird die Cache-Trefferquote drastisch verringert. Dies kann zu einer höheren Entfernungsrate und reduzierter Leistung führen.

Wichtige Hinweise:

  • Cacheschlüssel sind nicht mit einem konfigurierten Ursprung verknüpft. So können Sie eine Ursprungskonfiguration aktualisieren (oder den Ursprung vollständig ersetzen) können, ohne Gefahr zu laufen, den Cache zu „leeren“ (z. B. bei der Migration des Ursprungsspeichers zwischen Anbietern).
  • Cache-Schlüssel sind auf einen EdgeCacheService beschränkt. Verschiedene EdgeCacheServices haben unterschiedliche Cache-Namespaces. Dadurch wird verhindert, dass Objekte versehentlich wechselnd zwischen Produktions-, Staging- und anderen Testumgebungen im Cache gespeichert werden, auch wenn der Host, der Pfad oder andere Cache-Schlüsselkomponenten übereinstimmen würden. Löschen eines EdgeCacheService entwertet effektiv alle im Cache gespeicherten Objekte für für diesen Dienst.
  • Cache-Schlüssel sind nicht auf eine einzelne Route beschränkt. Mehrere Routen verweisen möglicherweise auf denselben Cache-Schlüssel, insbesondere wenn diese Routen in Komponenten übereinstimmen, die nicht im Cache-Schlüssel enthalten sind, z. B. Anfrageheader oder ausgeschlossene Parameter. Dies kann nützlich sein, wenn mehrere Routen denselben Cache verwenden, aber unterschiedliche Antwortheader oder CORS-Konfigurationen zurückgeben sollen.
  • Cache-Schlüssel enthalten keine Konfiguration zum Umschreiben von URLs. Ein Cache-Schlüssel basiert z. B. auf die nutzerseitige Anfrage und nicht auf die endgültige
  • Wenn signierte Anfragen für eine Route konfiguriert sind, sind die signierten Attribute nicht im Cache-Schlüssel enthalten. Die Anfrage wird so behandelt, als ob die (signierten) Abfrageparameter oder die Pfadkomponente, beginnend mit edge-cache-token und endend mit dem nächsten Pfadtrennzeichen ("/"), nicht Teil der URL sind.

Suchparameter ein- oder ausschließen

Sie können bestimmte Abfrageparameter aus einem Cache-Schlüssel ein- oder ausschließen, indem Sie auf einer bestimmten Route den Parameternamen zu der Cache-Schlüsselkonfiguration includedQueryParameters oder excludedQueryParameters hinzufügen.

So schließen Sie beispielsweise die Abfrageparameter contentID und country ein und ignorieren alle anderen aus dem Cache-Schlüssel:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

Achten Sie darauf, dass Sie die Abfrageparameter einfügen, die den Inhalt eindeutig identifizieren, und die ausschließen, die dies nicht tun. Schließen Sie beispielsweise Analyseabfrageparameter, Wiedergabesitzungs-IDs oder andere Parameter aus, die nur für den Client eindeutig sind. Wenn mehr Abfrageparameter als nötig hinzugefügt werden, kann dies die Cache-Trefferquoten verringern.

Statt anzugeben, welche Parameter in den Cache-Schlüssel einbezogen werden sollen, können Sie alternativ auch auswählen, welche Parameter aus dem Cache-Schlüssel ausgeschlossen werden sollen. Wenn Sie beispielsweise clientspezifische Informationen zu Wiedergabe-ID und Zeitstempel aus dem Cache-Schlüssel ausschließen möchten, nehmen Sie folgende Konfiguration vor:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

Für eine bestimmte Route können Sie includedQueryParameters oder excludedQueryParameters.

Wenn Abfrageparameter nie zum eindeutigen Identifizieren von Inhalten über Anfragen hinweg verwendet werden, können Sie alle Abfrageparameter aus dem Cache-Schlüssel für eine Route entfernen. Legen Sie dazu excludeQueryString auf true fest:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Wenn Signierte Anfragen für eine Route aktiviert sind, sind die für die Signatur verwendeten Abfrageparameter nicht im Abfragestring enthalten und werden ignoriert, wenn sie enthalten sind. Wenn die signierten Parameter in den Cache-Schlüssel einbezogen werden, wird jede Nutzeranfrage effektiv eindeutig und somit erforderlich, dass jede Anfrage vom Ursprung bereitgestellt wird.

Sortierung von Abfrageparametern

Abfrageparameter (Abfragestrings) werden standardmäßig sortiert, um die Cache-Trefferquoten zu verbessern, da Clients möglicherweise eine neue Anordnung vornehmen oder andernfalls dasselbe im Cache gespeicherte Objekt mit einer anderen Reihenfolge von Abfrageparametern anfordern können.

Die Abfrageparameter b=world&a=hello&z=zulu&p=paris und p=paris&a=hello&z=zulu&b=world werden als a=hello&b=world&p=paris&z=zulu sortiert bevor der Cache-Schlüssel abgeleitet wird. Dadurch können beide Anfragen demselben im Cache gespeicherten Objekt zugeordnet werden, sodass eine unnötige Anfrage an den (und Antwort vom) Ursprung vermieden wird.

Wenn mehrere Instanzen eines Abfrageparameterschlüssels mit jeweils unterschiedlichen Werten vorhanden sind, werden die Parameter nach ihrem vollständigen Wert sortiert (z. B. wird a=hello vor a=world sortiert). Die Sortierung kann nicht deaktiviert werden.

Header einschließen

Header-Namen berücksichtigen nicht die Groß-/Kleinschreibung und sie werden von Media CDN in Kleinbuchstaben umgewandelt.

Die folgenden Header können nicht in den Cache-Schlüssel eingeschlossen werden:

  • Alle Header, die mit access-control- beginnen
  • Beliebige Überschrift, die mit sec-fetch- beginnt
  • Beliebige Überschrift, die mit x-amz- beginnt
  • Beliebige Überschrift, die mit x-goog- beginnt
  • Alle Header, die mit x-media-cdn- beginnen
  • accept-encoding
  • accept
  • authorization
  • cdn-loop
  • connection
  • content-md5
  • content-type
  • cookie
  • date
  • forwarded
  • from
  • host
  • if-match
  • if-modified-since
  • if-none-match
  • origin
  • proxy-authorization
  • range
  • referer
  • referrer
  • user-agent
  • want-digest
  • x-csrf-token
  • x-csrftoken
  • x-forwarded-for

Verwenden Sie den speziellen Headernamen, um die HTTP-Methode in den Cache-Schlüssel aufzunehmen :method

Cookies einschließen

Bei Cookienamen wird zwischen Groß- und Kleinschreibung unterschieden.

Cookies, die mit edge-cache- in einer beliebigen Variation von Groß- oder Kleinbuchstaben beginnen, können nicht im Cache-Schlüssel verwendet werden.

Nochmalige Validierung, Bereinigung und Ablauf

Content Delivery Networks, einschließlich Media CDN, funktionieren so, dass die beliebtesten Inhalte so nah wie möglich an den Nutzern im Cache gespeichert werden.

Dank des umfangreichen Speichers von Media CDN sowie der Ursprungsabschirmung ist die Notwendigkeit verringert, sogar selten genutzte Inhalte zu entfernen. Inhalte, auf die nur wenige Male pro Tag zugegriffen wird, werden möglicherweise irgendwann entfernt.

  • Im Cache gespeicherte Antworten, die ihre konfigurierte TTL erreichen, sind möglicherweise nicht sofort entfernt. Für beliebte Inhalte: Media CDN überprüft erneut, ob die im Cache gespeicherte Antwort die neueste Version ist, indem ein HEAD-Anfrage an den Ursprung, um zu bestätigen, dass die Header nicht geändert. Unter bestimmten Umständen nutzt Media CDN sendet eine Anfrage mit einem oder beiden der folgenden Anfrageheader an den Ursprung: If-None-Match und If-Modified-Since. In diesem Fall sollten korrekt konfigurierte Ursprünge eine HTTP 304-Antwort (Nicht geändert) ohne die Textbyte zurückgeben, wenn der Cache die „aktuellste“ Kopie dieser Antwort hat.
  • Antworten, die einen max-age- oder s-maxage-Cache festlegen oder eine TTL verwenden überschreiben, um einen hohen TTL-Wert anzugeben (z. B. 30) Tage) werden möglicherweise nicht für die gesamte TTL im Cache gespeichert. Es gibt keine Garantie dafür, dass ein Objekt für die gesamte Dauer im Cache gespeichert wird, insbesondere wenn nur selten darauf zugegriffen wird.

Wenn bei Ihnen eine hohe Entfernungsrate auftritt, sollten Sie dafür sorgen, dass Ihre Cache-Schlüssel so konfiguriert sind, dass Parameter ausgeschlossen werden, die keine Antwort eindeutig identifizieren.

Weitere Hinweise

Die folgenden Überlegungen können auch für das Caching gelten.

Vary-Header

Der Vary-Header gibt an, dass die Antwort je nach Anfrageheader des Clients variiert. Wenn die Antwort einen Vary-Header enthält, wird sie von Media CDN nicht im Cache gespeichert, es sei denn, der Header enthält einen der Header, die als Cache-Schlüsseleinstellung konfiguriert sind, oder einen der folgenden Werte:

  • Akzeptieren:Damit wird angegeben, welche Medientypen der Client akzeptiert.
  • Accept-Encoding: gibt an, welche Komprimierungstypen der Client akzeptiert
  • Available-Dictionary: Wird verwendet, um den Hash eines verfügbaren Wörterbuchs für die Komprimierung bereitzustellen.
  • Origin/X-Origin: wird in der Regel für Cross-Origin Resource Sharing verwendet
  • X-Goog-Allowed-Resources: unterstützt Google Cloud-Organisationsbeschränkungen
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: Wird verwendet, um Metadatenanfrage-Header abzurufen

Media CDN speichert Antworten mit einem Vary-Header in der Antwort, indem der Wert des Headers als Teil des Cache-Schlüssels verwendet wird. Wenn der Vary-Header in der Antwort mehrere Werte enthält, werden diese lexikografisch sortiert, um sicherzustellen, dass der Cache-Schlüssel deterministisch ist.

Media CDN speichert bis zu 100 Varianten für einen bestimmten Cache-Schlüssel im Cache. Darüber hinaus werden Varianten nach dem Zufallsprinzip aus dem Cache entfernt. Wenn explizit Entwertung des Cache für eine bestimmte URL oder Cache-Tag enthält, werden alle Varianten ungültig gemacht.

Bypass the cache

Sie können den Cache-Modus BYPASS_CACHE für eine Route so konfigurieren, den Cache bei übereinstimmenden Anfragen umgehen. Das kann nützlich sein, wenn Sie den Cache für einen kleinen Teil nicht kritischer Zugriffe umgehen oder die Verbindung zur Quelle debuggen möchten.

In Fällen, in denen Sie dynamische Antworten bereitstellen müssen, z. B. bei API-Back-Ends, empfehlen wir die Konfiguration eines externen Application Load Balancers.

Es wird empfohlen, diese Nutzung im Allgemeinen auf Debugging-Szenarien zu beschränken, um eine unbeabsichtigte Ursprungslast zu vermeiden. Traffic, der ausgeht, wenn der Cache umgangen wird, wird zu Preisen für ausgehenden Internettraffic berechnet.

Cache-Entwertung

Siehe Cache-Entwertung.

Anfragen zum Byte-Bereich

Media CDN unterstützt einteilige HTTP-Bereichsanfragen wie in RFC 7233.

Darüber hinaus verwendet Media CDN Bereichsanfragen, um größere Antworten vom Ursprung abzurufen. So kann Media CDN werden einzelne Blöcke im Cache gespeichert und es muss nicht das gesamte Objekt abgerufen werden. um sie im Cache zu speichern.

  • Objekte, die größer als 1 MiB sind, werden als Bytebereichsanfragen („Blöcke“) von jeweils bis zu 2 MiB abgerufen.
  • Antworten mit bis zu 1 MiB können ohne Byte-Unterstützung abgerufen werden Bereiche am Ursprung.
  • Antworten, die größer sind, werden nicht ausgeliefert, wenn Bytebereiche am Ursprung nicht unterstützt werden.

Die Unterstützung von Bytebereichsanfragen durch den Ursprung wird anhand der folgenden Kriterien bestimmt:

  • Ein HTTP-Statuscode von 200 (OK) oder 206 (Teilinhalt).
  • Einen gültigen Content-Length- oder Content-Range-Antwortheader.
  • Eine Antwortvalidierung (ETag oder Last-Modified).

Individuelle Ursprungs-Füllungsanfragen für jeden „Block“ (Bytebereich) werden als separate Logeinträge protokolliert und ihrer übergeordneten Clientanfrage zugeordnet. Sie können diese Anfragen gruppieren, indem Sie Anfragen anhand des jsonPayload.cacheKeyFingerprint abgleichen.

Weitere Informationen dazu, was protokolliert wird, finden Sie in der Cloud Logging-Dokumentation.

Unbegrenzte Bereichsanfragen

Media CDN unterstützt „unbegrenzte“ Range-Anfragen (z. B. eine Anfrage mit Range: bytes=0-), die eine Anfrage für den Ursprung offen lassen, bis die Antwort vom Ursprung geschlossen wird (z. B. schreibt der Ursprung alle Byte an die Übertragung) oder das Zeitlimit überschritten wird.

Unbegrenzte Bytebereiche werden in der Regel von Clients verwendet, die die HLS-Segmente mit niedriger Latenz von Apple anfordern: Indem jeder CMAF-Block an die Übertragung geschrieben wird, kann das CDN diesen Block im Cache speichern und für Clients bereitstellen.

In anderen Fällen, z. B. wenn keine Interoperabilität mit DASH erforderlich ist, zeigt die Medien-Playlist dem Player an, welche Byte jeden einzelnen Block darstellen:

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

Sie können konfigurieren, wie lange Media CDN zwischen Lesevorgängen wartet, indem Sie Konfigurationswert EdgeCacheOrigin.timeouts.readTimeout. Dieser Wert sollte in der Regel ein Vielfaches (z. B. das Doppelte) der gewünschten Dauer sein.

Nächste Schritte