Media CDN stellt Inhalte so nah wie möglich bei Nutzern bereit, indem es der globalen Edge-Caching-Infrastruktur von Google, um Inhalte im Cache zu speichern und die Last auf Ursprungsinfrastruktur.
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.
Standardverhalten für das Caching
Standardmäßig gelten die folgenden Cache-bezogenen Einstellungen für jeden Edge-Cache Dienst:
Der Standard-Cache-Modus
CACHE_ALL_STATIC
:- Berücksichtigt Ursprungs-Cache-Anweisungen wie
Cache-Control
oderExpires
bis zu einer konfigurierbaren maximalen TTL. - speichert statische Medientypen automatisch mit einem Standard-TTL von 3.600 Sekunden, wenn keine Ursprungs-Cache-Anweisungen vorhanden sind.
- Speichert HTTP 200- und HTTP 206-Statuscodes im Cache (negatives Caching ist nicht aktiviert).
- Berücksichtigt Ursprungs-Cache-Anweisungen wie
Antworten mit der Cache-Steuerung
no-store
oderprivate
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 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 Anweisungen zur Cache-Steuerung. |
Antwortheader | Enthält ein gültiges HTTP-Caching
-Anweisung wie zum Beispiel einen Cache-Modus hat, in dem diese Inhalte im Cache gespeichert werden,
|
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 im Cache speichern kann, die größer sind als
1 MiB hat, muss ein Ursprung Folgendes in den Antwortheadern für
HEAD
- und GET
-Anfragen, sofern nicht anders angegeben:
- Einen HTTP-Antwortheader
Last-Modified
oderETag
(ein Validator). - Einen gültiger HTTP-
Date
-Header. - Einen gültigen
Content-Length
-Header. - Der
Content-Range
-Antwortheader als Antwort auf eineRange GET
-Anfrage. Der HeaderContent-Range
muss einen gültigen Wert im Formatbytes x-y/z
haben (wobeiz
die Objektgröße ist).
Das standardmäßige Ursprungsprotokoll 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. Im Cache speicherbare Antworten, die übereinstimmen „nicht im Cache speicherbar“ Kriterien 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 Speichern dieser Antworten im Cache kann zu Vergiftung“ Szenarien, in denen ein vom Nutzer ausgelöster Antwort im Cache gespeichert allen Nutzenden. |
Anfrageheader | Bei Anfragen mit einer Die Anweisung |
Antwortheader | Hat einen Hat einen anderen In |
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. unterliegen den zuvor genannten Anforderungen an die Cache-Fähigkeit. - Für den Cache-Modus
USE_ORIGIN_HEADERS
müssen Antworten festgelegt werden in ihren Antwort-Headern in den die nicht nur einen cache-fähigen Statuscode sind.
Hinweise:
- Für nicht im Cache gespeicherte Antworten sind keine Anweisungen zur Cache-Steuerung oder Andere Header wurden geändert und werden unverändert weitergeleitet.
- Für Antworten können die Header
Cache-Control
undExpires
minimiert werden in ein einzelnesCache-Control
-Feld. Eine Antwort mitCache-Control: public
undCache-Control: max-age=100
in separaten Zeilen wird alsCache-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
. das häufig verwendete statische Medientypen automatisch 1 Stunde lang (3.600 Sekunden), während alle Cache-Anweisungen priorisiert werden, die vom Ursprung angegeben werden für cachefähige Antworten. - Sie können die auf Antworten angewendete Cache-TTL erhöhen oder verringern, ohne dass dafür eine Cache-TTL (eine
max-age
- oders-maxage
-Anweisung) explizit festgelegt sein muss. Dazu legen Sie das FeldcdnPolicy.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 gespeichert.
es sei denn, sie haben Statische Inhalte umfassen Video-, Audio-, Bild- und Standardinhalte sowie
definiert durch den MIME-Typ in der |
FORCE_CACHE_ALL |
Erfolgreiche Antworten werden bedingungslos im Cache gespeichert, wodurch der Cache überschrieben wird. Anweisungen des Ursprungsorts. Stellen Sie sicher, dass Sie keine privaten, nutzerspezifischen Inhalte (z. B. dynamisches HTML) bereitstellen. oder API-Antworten), 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
Im Cache-Modus CACHE_ALL_STATIC
kann Media CDN
automatisch im Cache gängiger statischer Inhalte wie Video-, Audio-, Bild- und
allgemeine Web-Assets basierend auf dem MIME-Typ, der im Content-Type
-HTTP
-Antwortheader. 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 automatisch im Cache gespeichert werden können
mit dem Cache-Modus CACHE_ALL_STATIC
.
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 HeaderContent-Type
fest, einschließlich NGINX, Varnish und Apache. - Cloud Storage legt den Header
Content-Type
fest automatisch beim Upload, wenn Sie über die Google Cloud Console oder die gcloud CLI. - Ob eine Antwort aufgrund ihres MIME-Typs im Cache gespeichert werden kann,
Cache-Control
-Antwortanweisung vonprivate
oderno-store
- oderSet-Cookie
-Header enthält, wird er nicht im Cache gespeichert.
Cache-TTLs konfigurieren
Mit Überschreibungen der Gültigkeitsdauer (TTL) können Sie Standard-TTL-Werte für im Cache gespeicherte Inhalte festlegen
und überschreiben die in der Cachesteuerung max-age
und s-maxage
festgelegten TTL-Werte
Anweisungen (oder Expires
-Header), die von Ihren Ursprüngen festgelegt werden.
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 für den Ursprung kein Wenn der Ursprung einen Wenn Sie |
|
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 größer als
sind auf den Wert 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. |
|
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 die TTL-Einstellungen nicht
da Media CDN auf den Ursprung angewiesen ist,
verhalten.
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 derExpires
-Header in der nachgelagerten Antwort an den Client durch einenCache-Control
-Header ersetzt.
Negatives Caching
Durch negatives Caching wird definiert, wie HTTP-Statuscodes (andere als 2xx) werden von Media CDN im Cache gespeichert.
So können Sie Fehlerantworten wie Weiterleitungen (HTTP 301 und 308) im Cache speichern Antworten vom Typ „Nicht gefunden“ (HTTP 404), die sich näher am Nutzer befinden und den Ursprung verringern breiter geladen werden, wenn sich die Antwort wahrscheinlich nicht ändert und im Cache gespeichert werden kann.
Negatives Caching ist standardmäßig 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 dem heuristisch cachefähigen Statuscodes beschrieben in HTTP RFC 9110 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. So können Sie
Legen Sie die TTL für einen der von Media CDN zulässigen Statuscodes fest:
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:
- Um das Standardverhalten für negatives Caching zu deaktivieren, legen Sie Folgendes fest:
cdnPolicy.negativeCaching: false
auf einer Route. Beachten Sie, dass Ursprungsantworten mit gültigen Cache-Anweisungen und dem Status „cachefähig“ Codes 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 IhrernegativeCachingPolicy
-Definition weg. - Zum expliziten Ignorieren der Ursprungs-Cache-Anweisungen für einen bestimmten Status
, setzen Sie
cdnPolicy.negativeCachingPolicy[].ttl
auf0
(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 Maximalwert für eine von
negativeCachingPolicy
festgelegte TTL beträgt 1.800 Sekunden (30 Minuten), aber Ursprungs-Cache-Anweisungen mit einer höheren TTL werden berücksichtigt. - Wenn der Cache-Modus als
FORCE_CACHE_ALL
konfiguriert ist, wird der Ursprung -Anweisungen in allen Fällen ignoriert.
Anweisungen zur Cache-Steuerung
Das Verhalten von Media CDN in Bezug 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 Dies kann für einzelne Routen mit dem
|
no-store |
Die Antwort auf eine Anfrage mit no-store wird nicht im Cache gespeichert. |
Eine Antwort mit Dies kann für einzelne Routen mit dem Cache-Modus |
public |
– | Eine Antwort mit der Anweisung Bei Verwendung des |
private |
– | Eine Antwort mit der Anweisung Dies kann für einzelne Routen mit dem
Mit |
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 Wenn sowohl
|
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 Eine im Cache gespeicherte Antwort wird so zurückgegeben, als wäre dieser Header nicht in der Anfrage. |
– |
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 |
proxy-revalidate |
– | Eine Antwort mit |
immutable |
– | Keine Auswirkungen. Dies wird in der Antwort an den Client weitergegeben. |
no-transform |
– | Von Media CDN werden keine Transformationen angewendet. |
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 Headers
Expires
muss ein gültiges HTTP-Datum wie folgt sein: 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 einCache-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 Cache-Schlüssel konfiguriert werden.
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 Abfrageparameter aus der Anfrage und gelten für eine bestimmte EdgeCacheService.
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 |
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 |
Pfad | Ja | Immer im Cache-Schlüssel enthalten 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 Wenn nur einige Abfrageparameter in einem Cache-Schlüssel enthalten sein sollen, legen Sie
|
Header | Nein | Legen Sie für 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 |
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:
- Cache-Schlüssel sind nicht an einen konfigurierten Ursprung angehängt, sodass Sie Folgendes aktualisieren können: eine Ursprungskonfiguration (oder den Ursprung vollständig ersetzen) ohne das Risiko eines „Leerens“ aus dem Cache (z. B. beim Migrieren des Ursprungsspeichers zwischen Anbietern)
- Cache-Schlüssel sind auf einen EdgeCacheService beschränkt. Verschiedene EdgeCacheServices haben Cache-Namespaces ändern, wodurch verhindert wird, dass versehentlich zwischen Produktions-, Staging- und anderen Testumgebungen zu erstellen, selbst wenn Host, Pfad oder andere Cache-Schlüsselkomponenten passen. 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 Sie möchten, dass mehrere Routen den gleichen Cache, aber unterschiedliche Antwortheader oder CORS-Konfigurationen zurückgeben.
- 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"]
Geben Sie unbedingt die Suchparameter an, mit denen Inhalte eindeutig identifiziert werden. die anderen ausschließen. 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. Vorgehensweise
Setzen von excludeQueryString
auf true
:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: excludeQueryString: true
Wenn Signierte Anfragen für eine Route aktiviert sind, gilt Folgendes: zum Signieren verwendete Suchparameter sind nicht im Abfragestring enthalten und werden werden ignoriert, falls 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
wurden 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:
- Beliebige Überschrift, die mit
access-control-
beginnt - Beliebige Überschrift, die mit
sec-fetch-
beginnt - Beliebige Überschrift, die mit
x-amz-
beginnt - Beliebige Überschrift, die mit
x-goog-
beginnt - Beliebige Überschrift, die mit
x-media-cdn-
beginnt 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
undIf-Modified-Since
. In diesem Fall korrekt konfigurierte Ursprünge sollten den HTTP-Statuscode 304 (nicht geändert) zurückgeben Antwort ohne die Textbyte, wenn der Cache das neueste Kopie von dieser Antwort. - Antworten, die einen
max-age
- oders-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 dass ein Objekt für die gesamte Dauer im Cache gespeichert wird, vor allem, wenn sie selten aufgerufen werden.
Wenn Sie eine hohe Anzahl von Bereinigungen feststellen, haben Ihre Cache-Schlüssel so konfiguriert, dass Parameter ausgeschlossen werden, die ein Antwort.
Weitere Hinweise
Die folgenden Überlegungen können auch in Bezug auf Caching zutreffen.
Vary
-Header
Der Vary
-Header gibt an, dass die Antwort je nach Anfrageheader des Clients variiert. Wenn in der Antwort ein Vary
-Header vorhanden ist,
Media CDN speichert ihn nicht im Cache, es sei denn, der Header gibt entweder
einer der Header, die als
cache key setting 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örterbuch für Komprimierung
- Origin/X-Origin:wird in der Regel für Cross-Origin Resource Sharing verwendet
- X-Goog-Allowed-Resources: unterstützt Google Cloud-Organisation Einschränkung
- Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: wird zum Abrufen von Metadatenanfragen verwendet. Überschriften
Media CDN speichert Antworten mit einem Vary
-Header in der Antwort im Cache
unter Verwendung des Header-Werts als Teil des Cache-Schlüssels. 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. Dies kann nützlich sein, wenn Sie
den Cache für einen kleinen Teil des nicht kritischen Traffics oder den Debug-Ursprung
Konnektivität haben.
Für Fälle, in denen dynamische Antworten bereitgestellt werden müssen, wie z. B. API-Back-Ends, empfehlen, einen externen Application Load Balancer zu konfigurieren.
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.
Außerdem nutzt Media CDN Bereichsanfragen, 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. gleichzeitig im Cache gespeichert werden.
- 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.
- Größere Antworten werden nicht bereitgestellt, wenn Bytebereiche nicht unterstützt werden auf den Ursprung.
Die Ursprungsunterstützung für Bytebereichsanfragen wird so festgelegt:
- Ein HTTP-Statuscode von 200 (OK) oder 206 (Teilinhalt).
- Einen gültigen
Content-Length
- oderContent-Range
-Antwortheader. - Eine Antwortvalidierung (
ETag
oderLast-Modified
).
Individuelle Ursprungsausführungsanfragen für jeden „Block“ (Bytebereich) werden protokolliert als
diskrete Logeinträge, die der jeweiligen übergeordneten Clientanfrage zugeordnet sind. Sie können diese Anfragen gruppieren, indem Sie Anfragen anhand des jsonPayload.cacheKeyFingerprint
abgleichen.
Weitere Informationen dazu, was protokolliert wird, findest du in der Cloud Logging-Dokumentation
Unbegrenzte Bereichsanfragen
Media CDN unterstützt „offene Antworten“ Range
-Anfragen (z. B. eine
Anfrage mit Range: bytes=0-
), die eine Anfrage für den Ursprung offen halten
bis die Antwort durch den Ursprung geschlossen wird (der Ursprung schreibt z. B. alle
Byte) oder das Zeitlimit überschreitet.
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
. Dies sollte
in der Regel auf ein Vielfaches (z. B. 2x) deiner Zieldauer konfiguriert.
Nächste Schritte
- Erweitertes Routing
- Informieren Sie sich darüber, wie Sie Verbindungen zu verschiedenen Ursprüngen herstellen.
- Richten Sie TLS-Zertifikate (SSL) für Ihren Dienst ein.
- Konfigurieren Sie signierte Anfragen, um den Zugriff auf Inhalte zu authentifizieren.