Media CDN stellt Inhalte so nah wie möglich bei den Nutzern bereit. Dazu wird die globale Edge-Caching-Infrastruktur von Google genutzt, um Inhalte im Cache zu speichern und die Last auf der Ursprungsinfrastruktur zu reduzieren.
Sie können steuern, wie die Inhalte für jede Route im Cache gespeichert werden. So können Sie das Verhalten basierend auf dem Inhaltstyp, den Clientanfrageattributen und Ihren Aktualitätsanforderungen optimieren.
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 beim Caching
Standardmäßig gelten für jeden Edge-Cache-Dienst die folgenden Cache-bezogenen Einstellungen:
Der Standard-Cache-Modus
CACHE_ALL_STATIC
:- Berücksichtigt Ursprungscache-Anweisungen wie
Cache-Control
oderExpires
. - Speichert statische Inhaltstypen automatisch im Cache, mit einer Standard-TTL von 3.600 s.
- Speichert HTTP 200- und HTTP 206-Statuscodes im Cache (negatives Caching ist nicht aktiviert).
- Berücksichtigt Ursprungscache-Anweisungen wie
Speichert Antworten mit
no-cache
- oderno-store
-Anweisungen oder solche, die anderweitig nicht cachefähig sind, nicht im Cache.
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 Speichern bestimmter HTTP-Antworten im Cache beschrieben:
HTTP-Attribut | Voraussetzungen |
---|---|
Statuscode | Der Antwortstatuscode muss einer der folgenden sein: 200, 203, 204, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451 oder 501 |
HTTP-Methoden | GET, HEAD und OPTIONS |
Anfrageheader | Anfrageheader haben keinen Einfluss darauf, ob ein Element im Cache gespeichert werden soll. Weitere Informationen finden Sie unter Cache-Steuerungsanweisungen. |
Antwortheader |
|
Antwortgröße | Bis zu 50 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.
Ursprungsanforderungen
Damit Media CDN Ursprungsantworten 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
- oderETag
-HTTP-Antwortheader. - Einen gültiger HTTP-
Date
-Header. - Einen gültigen
Content-Length
-Header. - Den
Accept-Ranges: bytes
-Antwortheader. - Den
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 Standardursprungsprotokoll ist HTTP/2. Wenn Ihre Ursprünge nur HTTP/1.1 unterstützen, können Sie das Protokollfeld für jeden Ursprung explizit festlegen.
Nicht cachefähige Antworten
In der folgenden Tabelle wird gezeigt, welche Anfrage- und Antwortattribute das Speichern einer Antwort im Cache verhindern. Antworten, die cachefähig sind, aber mit einem "nicht cachefähig"-Kriterium übereinstimmen, werden nicht im Cache gespeichert.
HTTP-Attribut | Anforderung |
---|---|
Statuscode | Ein anderer Statuscode als die, die als cachefähig definiert sind, z. B. HTTP 400, HTTP 403 oder HTTP 504. Diese Statuscodes kennzeichnen in der Regel clientseitige 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 | Anfrageheader haben keine Auswirkungen darauf, ob ein Element im Cache gespeichert werden soll oder nicht. Eine Ausnahme bildet der Authorization -Anfrageheader. Antworten müssen eine public -Cache-Steuerungsanweisung enthalten, um in diesem Fall im Cache gespeichert zu werden.Weitere Informationen finden Sie unter Cache-Steuerungsanweisungen. |
Antwortheader |
|
Antwortgröße | Größer als 50 GiB. |
Diese Regeln gelten zusätzlich zum konfigurierten Cache-Modus. Zum Beispiel:
- Wenn der Cache-Modus
CACHE_ALL_STATIC
konfiguriert ist, werden nur Antworten, die als statische Inhalte betrachtet werden, oder Antworten mit gültigen Cache-Anweisungen in ihren Antwort-Headern im Cache gespeichert. Andere Antworten werden "unverändert" weitergeleitet. - Der Cache-Modus
FORCE_CACHE_ALL
speichert alle Antworten bedingungslos im Cache, vorausgesetzt, die Antwort ist ein cachefähiger Statuscode. - 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:
- Bei Antworten, die nicht im Cache gespeichert werden, werden die
Cache-Control
-Anweisungen oder anderen Header nicht geändert. Sie werden "unverändert" weitergeleitet. - HTTP-Antworten mit mehreren Headerfeldern mit demselben Namen werden gegebenenfalls in einem einzelnen Headerfeld minimiert. Beispielsweise würde eine Antwort mit
Cache-Control: no-cache
undCache-Control: no-store
in separaten Zeilen alsCache-Control: no-cache, no-store
minimiert werden. - Nicht cachefähige Antworten (Antworten, die niemals im Cache gespeichert werden) werden aus Sicht der Abrechnung nicht als ausgehender Cache-Traffic gezählt.
Cache-Modi verwenden
Mit den Cache-Modi können Sie konfigurieren, wann Media CDN Ursprungscache-Anweisungen berücksichtigen, statische Inhaltstypen im Cache speichern und alle Antworten vom Ursprung im Cache speichern soll, 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 Inhaltstypen automatisch für 1 Stunde (3.600 Sekunden) im Cache speichert, sowie alle anderen cachefähigen Antworten mit gültigen Cache-Anweisungen. - 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. - Nicht-2xx-Statuscodes (nicht erfolgreich) werden nicht gemäß ihrem
Content-Type
(MIME-Typ) im Cache gespeichert und bringen nicht die Standard-TTL zur Anwendung. So wird verhindert, dass Antworten, die nicht erfolgreich sind, länger als beabsichtigt im Cache gespeichert werden.
Im Folgenden finden Sie die verfügbaren Cache-Modi, die auf der cdnPolicy.cacheMode
jeder Route festgelegt sind:
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 in der Dokumentation zu cachefähigen Antworten. |
CACHE_ALL_STATIC |
Speichert statische Inhalte, die die Anweisungen no-store , private oder no-cache nicht enthalten, automatisch im Cache. Ursprungantworten, die gültige Caching-Anweisungen festlegen, werden ebenfalls im Cache gespeichert.Statische Inhalte umfassen Video-, Audio-, Bild- und allgemeine Web-Assets, die durch den MIME-Typ im Content-Type -Antwortheader definiert sind.
|
FORCE_CACHE_ALL |
Speichert Antworten bedingungslos im Cache, wobei alle vom Ursprung festgelegten Cache-Anweisungen überschrieben werden. Achten Sie darauf, dass keine privaten, nutzerspezifischen Inhalte (wie dynamische HTML- oder API-Antworten) bereitgestellt werden, wenn dieser Modus konfiguriert ist. |
BYPASS_CACHE | Alle Anfragen, die mit einer Route übereinstimmen und bei denen dieser Cache-Modus konfiguriert ist, umgehen den Cache, auch wenn es ein im Cache gespeichertes Objekt gibt, das mit diesem Cache-Schlüssel übereinstimmt. Wir empfehlen, diese Option nur für das Debugging zu verwenden, da Media CDN als weltweite Cache-Infrastruktur und nicht als allgemeiner Proxy entwickelt wurde. |
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.
In der folgenden Tabelle sind die MIME-Typen aufgeführt, die automatisch mit dem Cache-Modus CACHE_ALL_STATIC
im Cache gespeichert werden.
Antworten werden nicht automatisch im Cache gespeichert, wenn bei ihnen ein Content-Type
-Antwortheader mit einem Wert fehlt, der den folgenden Werten entspricht. Sie müssen dafür sorgen, dass die Antwort eine gültige Cache-Anweisung festlegt oder den Cache-Modus FORCE_CACHE_ALL
verwendet, um Antworten bedingungslos im Cache zu speichern.
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
automatisch beim Upload fest, wenn Sie die Google Cloud Console oder dasgsutil
-Tool zum Hochladen von Inhalten verwenden. - Wenn eine Antwort aufgrund ihres MIME-Typs cachefähig ist, aber einen
Cache-Control
-Antwortheaderprivate
,no-store
oderno-cache
oder einenSet-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.
Beachten Sie, dass TTLs, unabhängig davon, ob sie durch Überschreibungen oder über eine Cache-Anweisung festgelegt werden, optimistisch sind. Inhalte, auf die selten zugegriffen wird oder die selten genutzt werden, werden möglicherweise aus dem Cache entfernt, bevor die TTL erreicht wird.
Es gibt drei TTL-Einstellungen:
Einstellung | Standard | Min. | Max. | Beschreibung | Anwendbare Cache-Modi |
---|---|---|---|---|---|
Default TTL | 1 Stunde (3600 Sekunden) | 0 Sekunden | 1 Jahr (31.536.000 Sekunden) | Die TTL, die festgelegt werden soll, wenn der Ursprung kein max-age oder s-maxage angegeben hat.Wenn der Ursprung den Header s-maxage angibt, wird er anstelle des Standard-TTL-Werts verwendet.Wenn FORCE_CACHE_ALL verwendet wird, um alle Antworten bedingungslos im Cache zu speichern, wird die Standard-TTL verwendet, um die Cache-TTL festzulegen. Alle anderen Werte und Anweisungen werden 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. Werte darüber werden auf den Wert maxTtl begrenzt.
|
CACHE_ALL_STATIC |
Client TTL | Standardmäßig nicht festgelegt. | 0 Sekunden | 1 Monat (2.592.000 Sekunden) | Die TTL, die in der nachgelagerten (clientseitigen) Antwort festgelegt werden soll, wenn sie sich von anderen TTL-Werten unterscheiden muss. Dies gilt nur für erfolgreiche Antworten (2xx). |
CACHE_ALL_STATIC FORCE_CACHE_ALL
|
Wenn Sie einen TTL-Wert auf null (0 Sekunden) festlegen, wird jede Anfrage mit dem Ursprung neu validiert, bevor eine Antwort zurückgegeben wird. So erhöht sich die Last auf den Ursprung, wenn dies zu häufig festgelegt wird.
Wenn der Cache-Modus auf "Ursprüngliche Header verwenden" 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, spiegelt der
Cache-Control
-Header beim Client auch diesen Wert wider. - 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
Negatives Caching definiert, wie nicht erfolgreiche HTTP-Statuscodes (andere als 2xx) von Media CDN im Cache gespeichert werden.
Auf diese Weise 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 negatives 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 Cache-Poisoning zu vermeiden.
- 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 und 501.
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 das negative Caching:
- Um das Standardverhalten für negatives Caching zu deaktivieren, legen Sie
cdnPolicy.negativeCaching: false
für eine Route fest. Beachten Sie, dass Ursprungsantworten mit gültigen Cache-Anweisungen und cachefähigen Statuscodes weiterhin im Cache gespeichert werden. - 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. - Wenn Sie die ursprünglichen Cache-Anweisungen für einen bestimmten Statuscode explizit ignorieren möchten, legen Sie für diesen Statuscode
cdnPolicy.negativeCachingPolicy[].ttl
auf0
(null) fest.
Hinweise:
- Wenn
negativeCaching
für eine Route aktiviert ist und eine Antwort gültige Cache-Anweisungen definiert, haben die Cache-Anweisungen in der Antwort 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 Höchstwert für eine durch
negativeCachingPolicy
festgelegte TTL beträgt 1.800 Sekunden (30 Minuten). Ursprungscache-Anweisungen 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.
Cache-Schlüssel
Sie können die Häufigkeit, mit der Media CDN Ihren Ursprung kontaktieren muss, reduzieren, indem Sie berücksichtigen, was eine Anfrage eindeutig identifiziert, und Komponenten entfernen, die sich häufig zwischen Anfragen ändern. Der Satz von Anfragekomponenten wird oft als "Cache-Schlüssel" bezeichnet.
In den folgenden Abschnitten wird die Konfiguration von Cache-Schlüsseln beschrieben.
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.
Cache-Schlüssel für Edge-Cache-Dienste umfassen standardmäßig den Anfrage-Host, 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 |
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 die Mindestdarstellung eines Objekts im Cache. |
Anfrageparameter | Ja | Wenn Abfrageparameter nicht zwischen verschiedenen Antworten unterscheiden, setzen Sie Wenn nur einige Abfrageparameter in einem Cache-Schlüssel enthalten sein sollen, legen Sie je nach Bedarf |
Header | Nein | Legen Sie 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. Weitere Informationen zum Einschließen von Headern finden Sie unter Header einschließen. |
Cookies | Nein | Legen Sie 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. Weitere Informationen zum Einschließen von Cookies finden Sie unter Cookies einschließen. |
Beachten Sie, dass Cache-Schlüssel:
- Nicht mit einem konfigurierten Ursprung verknüpft sind, sodass 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).
- Auf einen EdgeCacheService beschränkt sind. 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.
- Durch das Löschen eines EdgeCacheService werden alle für diesen Dienst im Cache gespeicherten Objekte effektiv ungültig.
- Nicht auf eine einzelne Route beschränkt sind. 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 den gleichen Cache verwenden sollen, aber unterschiedliche Antwortheader oder CORS-Konfigurationen zurückgeben sollen.
- Fügen Sie keine URL-Umschreibungskonfiguration hinzu (z. B. basiert ein Cache-Schlüssel auf der nutzerseitigen Anfrage, nicht auf der endgültigen "umgeschriebenen" Anfrage).
- 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.
Ein- oder Ausschließen von Abfrageparametern
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"]
Sie können für eine bestimmte Route entweder includedQueryParameters
oder excludedQueryParameters
angeben.
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 zum Signieren verwendeten Abfrageparameter nicht im Abfragestring enthalten und werden ignoriert, sofern enthalten. 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.
Beispiel: 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 - Alle Header, die mit
sec-fetch-
beginnen - Alle Header, die mit
x-amz-
beginnen - Alle Header, die mit
x-goog-
beginnen - 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 :method
, um die HTTP-Methode in den Cache-Schlüssel aufzunehmen.
Cookies einschließen
Bei Cookie-Namen 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, werden möglicherweise nicht sofort entfernt. Bei beliebten Inhalten validiert Media CDN neu, ob die im Cache gespeicherte Antwort die neueste Version ist. Dazu wird eine Anfrage an den Ursprung mit einem
If-None-Match
- und/oderIf-Modified-Since
-Anfrageheader gesendet. - Korrekt konfigurierte Ursprünge geben eine HTTP 304-Antwort (Nicht geändert) ohne die Textbyte zurück, wenn der Cache die "neueste" Kopie dieser Antwort hat.
- Antworten, die eine Cache-Anweisung
max-age
oders-maxage
festlegen oder eine TTL-Überschreibung verwenden, um einen hohen TTL-Wert anzugeben (zum Beispiel 30 Tage), werden möglicherweise nicht für die gesamte TTL im Cache gespeichert. Es gibt keine Garantie dafür, dass ein Objekt die gesamte Dauer im Cache gespeichert wird, insbesondere wenn 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
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, muss er einen der folgenden Werte angeben oder Media CDN speichert ihn nicht im Cache:
- Accept: gibt an, welche Inhaltstypen der Client akzeptiert
- Accept-Encoding: gibt an, welche Komprimierungstypen der Client akzeptiert
- Origin: wird in der Regel für Cross-Origin Resource Sharing verwendet
Media CDN speichert Antworten mit einem Vary
-Header in der Antwort im Cache, 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 der Cache für eine bestimmte URL oder ein Cache-Tag explizit entwertet wird, werden alle Varianten entwertet.
Bypass the cache
Sie können den Cache-Modus BYPASS_CACHE
auf einer Route konfigurieren, um den Cache bei übereinstimmenden Anfragen absichtlich zu umgehen. Dies kann nützlich sein, wenn Sie den Cache für einen kleinen Teil des nicht kritischen Traffics umgehen oder die Ursprungskonnektivität debuggen müssen.
In Fällen, in denen Sie dynamische Antworten bereitstellen müssen, z. B. bei API-Back-Ends, empfehlen wir die Konfiguration eines externen HTTP(S)-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 HTTP-Bereichsanfragen wie in RFC 7233 definiert, einschließlich einteiliger Bereichsanfragen und mehrerer Bytebereiche.
Darüber hinaus verwendet Media CDN Bereichsanfragen auch optimistisch, um größere Inhalte vom Ursprung abzurufen. So kann Media CDN Blöcke einzeln im Cache speichern und muss nicht das gesamte Objekt auf einmal abrufen, um es im Cache zu speichern.
- Objekte, die größer als 2 MB sind, werden als Bytebereichsanfragen ("Blöcke") abgerufen.
- Antworten bis zu 2 MB Byte können ohne Unterstützung für Bytebereiche am Ursprung abgerufen werden.
- Größere Antworten werden nicht bereitgestellt, wenn Bytebereiche am Ursprung nicht unterstützt werden.
Die Ursprungsunterstützung für Bytebereichsanfragen wird bestimmt durch:
- Den HTTP-Statuscode 200 (OK) oder 206 (Teilinhalt).
- Den
Accept-Ranges: bytes
-Anfrageheader. - Einen gültigen
Content-Length
- oderContent-Range
-Antwortheader.
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 darüber, welche Angaben protokolliert werden, finden Sie in der Cloud Logging-Dokumentation.
Unbegrenzte Bereichsanfragen
Media CDN unterstützt "unbegrenzte" Bereichsanfragen (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 über den Konfigurationswert EdgeCacheOrigin.timeouts.readTimeout
konfigurieren, wie lange Media CDN zwischen Lesevorgängen wartet. Dies sollte normalerweise auf ein Vielfaches (z. B. das 2-Fache) Ihrer Zieldauer konfiguriert werden.
Mehrteilige Bytebereiche
Insbesondere müssen mehrteilige Bereichsanfragen (z. B. bytes=0-300,1200-2000
) die folgenden Anforderungen erfüllen:
- Sie müssen RFC 7233 entsprechen.
- Bereiche müssen in aufsteigender Reihenfolge sein.
- In einer einzelnen Anfrage können maximal zwei Bereiche angegeben werden.
Die meisten Objektspeicher, einschließlich Cloud Storage und Amazon S3, unterstützen mehrteilige Bereichsanfragen nicht direkt und geben entweder einen Fehler zurück oder geben implizit das vollständige Objekt zurück. Viele beliebte Reverse- und Caching-Proxys, einschließlich Varnish, unterstützen auch keine mehrteiligen Bereichsanfragen.
Nächste Schritte
- Lesen Sie über 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.