Caching-Verhalten konfigurieren

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

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 Attributen der Clientanfrage 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 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 s, wenn keine Cache-Anweisungen für den Ursprung vorhanden sind.
  • Speichert HTTP 200-, 204- und 206-Statuscodes im Cache (negatives Caching ist nicht aktiviert).

• Speichert Antworten mit no-store- oder private-Cache-Control-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. Sowohl GET- als auch HEAD-Antworten müssen diesen Anforderungen entsprechen.

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 (ein 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 Standardursprungsprotokoll ist HTTP/2. Wenn Ihre Ursprünge 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 werden die Anfrage- und Antwortattribute aufgeführt, die 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.

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 statischer Inhalt betrachtet werden, oder Antworten mit gültigen Cache-Anweisungen in ihren Antwort-Headern im Cache gespeichert. Andere Antworten werden unverändert weitergeleitet.
• Im Cache-Modus FORCE_CACHE_ALL werden alle Antworten bedingungslos im Cache gespeichert, sofern die oben genannten Anforderungen für das Nicht-Cachen erfüllt sind.
• 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.
• Die Header Cache-Control und Expires von Antworten können in einem einzelnen Cache-Control-Feld zusammengefasst werden. Beispielsweise würde eine Antwort mit Cache-Control: public und Cache-Control: max-age=100 in separaten Zeilen als Cache-Control: public,max-age=100 minimiert werden.
• Nicht cachefähige Antworten (Antworten, die niemals im Cache gespeichert werden) werden aus Sicht der Abrechnung nicht als Cache Egress gezählt.

Cache-Modi verwenden

Mit Cache-Modi können Sie konfigurieren, wann Media CDN Ursprungs-Cache-Anweisungen berücksichtigen, statische Medientypen 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 Medientypen automatisch für 1 Stunde (3.600 Sekunden) im Cache speichert und dabei 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 Antworten, die nicht erfolgreich sind, länger als beabsichtigt im Cache gespeichert werden, werden nicht erfolgreiche Statuscodes (nicht 2xx) nicht gemäß ihrem Content-Type (MIME-Typ) im Cache gespeichert und bringen nicht die Standard-TTL zur Anwendung.

Die verfügbaren Cache-Modi, die auf der cdnPolicy.cacheMode jeder Route festgelegt sind, sind in der folgenden Tabelle aufgeführt.

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 priorisiert Media CDN jedoch alle expliziten Cache-Control- oder Expires-Header in der Ursprungsantwort.

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 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 in der Antwort eine gültige Cache-Anweisung festgelegt wird, oder Sie müssen den Cache-Modus FORCE_CACHE_ALL verwenden, um Antworten bedingungslos im Cache zu speichern.

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 CLI zum Hochladen von Inhalten verwenden.
• Cloud Storage stellt Media CDN immer einen Cache-Control-Header zur Verfügung. Wenn kein Wert explizit ausgewählt wird, wird ein Standardwert gesendet. Daher werden alle erfolgreichen Cloud Storage-Antworten gemäß den Cloud Storage-Standardwerten im Cache gespeichert, sofern Sie die Cachesteuerungs-Metadaten für Objekte in Cloud Storage nicht explizit anpassen oder den FORCE_CACHE_ALL-Modus verwenden, um die von Cloud Storage gesendeten Werte zu überschreiben.

Wenn eine Antwort aufgrund ihres MIME-Typs cachefähig ist, aber eine Cache-Control-Antwortanweisung private oder no-store oder einen Set-Cookie-Header hat, wird sie nicht im Cache gespeichert.

Andere Medientypen wie HTML (text/html) und JSON (application/json) werden standardmäßig nicht im Cache gespeichert. Diese Antworttypen sind in der Regel dynamisch (nutzerbasiert) und eignen sich auch nicht gut für die Architektur von Media CDN. Wir empfehlen die Verwendung von Cloud CDN zum Bereitstellen von Web-Assets und zum Zwischenspeichern von API-Antworten.

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, die durch Überschreibungen oder mithilfe einer Cache-Anweisung festgelegt werden, sind optimistisch. Inhalte, auf die selten zugegriffen wird oder die nicht beliebt sind, werden möglicherweise vor dem Ablaufen der TTL aus dem Cache entfernt.

In der folgenden Tabelle sind drei TTL-Einstellungen aufgeführt.

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 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, 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 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.

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 das negative Caching deaktiviert. Die folgende Tabelle zeigt die Standardwerte für jeden Statuscode, wenn negatives Caching aktiviert und negativeCachingPolicy nicht verwendet wird.

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

• HTTP-Code 414 (URI Too Long) wird nicht für das Caching 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, 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 das negative Caching:

• Wenn Sie das standardmäßige negative Caching-Verhalten deaktivieren möchten, legen Sie cdnPolicy.negativeCaching: false für eine Route fest. Ursprungsantworten mit gültigen Cache-Anweisungen und cachefähigen 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.
• Wenn Sie Ursprungscache-Anweisungen für einen bestimmten Statuscode explizit ignorieren möchten, setzen Sie cdnPolicy.negativeCachingPolicy[].ttl für diesen Statuscode auf 0 (null).

Hinweise:

• Wenn negativeCaching für eine Route aktiviert ist und in einer Antwort gültige Cache-Anweisungen definiert sind, 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 maximale Wert für eine von 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.

Anweisungen zur Cache-Steuerung

Das Verhalten von Media CDN in Bezug auf Cache-Control-Anweisungen wird hier definiert.

Wenn die Anweisung nicht auf eine Anfrage oder Antwort anwendbar ist, z. B. only-if-cached (eine reine Clientanweisung), wird in dieser Spalte „–“ angegeben.

Sofern möglich, ist Media CDN RFC-konform (HTTP RFC 7234). Ziel ist aber primär die Optimierung der Cache-Auslagerung und die Minimierung der möglichen Auswirkungen von Clients auf die Trefferrate und auf die gesamte Ursprungslast.

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 ein Wert von 0 gibt an, dass der Inhalt bereits abgelaufen ist und noch einmal validiert werden muss.
• Media CDN ignoriert den Expires-Header, wenn die Antwort einen Cache-Control-Header enthält.

Der HTTP/1.0-Header Pragma wird, wenn er in einer Antwort enthalten ist, ignoriert und unverändert an den Client weitergegeben.

Cache-Schlüssel

Sie können die Anzahl der Zugriffe von Media CDN auf Ihren Ursprungsserver reduzieren, indem Sie überlegen, 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 beschrieben, wie Sie Cache-Schlü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.

Wichtige Hinweise:

• Cache-Schlüssel sind nicht mit einem konfigurierten Ursprung verknüpft, 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).
• 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. Wenn Sie einen EdgeCacheService löschen, werden alle im Cache gespeicherten Objekte für diesen Dienst ungültig.
• 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 URL-Umschreibungskonfiguration. Ein Cache-Schlüssel basiert beispielsweise auf der nutzerseitigen Anfrage und 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.

Abfrageparameter 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 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. Setzen Sie dazu excludeQueryString auf true:

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

Wenn Signierte Anfragen für eine Route aktiviert sind, werden Abfrageparameter, die zum Signieren verwendet werden, nicht in den Abfragestring aufgenommen und 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 beispielsweise 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
• accept-encoding
• accept
• authorization
• 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 einbeziehen

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, deren konfigurierte TTL erreicht ist, 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 HEAD-Anfrage an den Ursprung gesendet, um zu bestätigen, dass sich die Header nicht geändert haben.
• Antworten, die eine Cache-Anweisung max-age oder s-maxage festlegen oder eine TTL-Überschreibung verwenden, 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 es selten aufgerufen 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 in Bezug auf 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, im Header wird einer der Header angegeben, die als Cache-Schlüsseleinstellung konfiguriert sind, oder einer der folgenden Werte:

• Accept:Gibt an, 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 anzugeben.
• Origin/X-Origin:wird in der Regel für Cross-Origin Resource Sharing verwendet
• X-Goog-Allowed-Resources: unterstützt die Einschränkung für Google Cloud-Organisationen
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::Wird verwendet, um Header für Metadatenanfragen abzurufen.

Media CDN speichert Antworten mit einem Vary-Header in der Antwort im Cache. Dabei wird der Wert des Headers als Teil des Cache-Schlüssels verwendet. 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 Sie den Cache für eine bestimmte URL oder ein bestimmtes Cache-Tag explizit entwerten, werden alle Varianten entwertet.

Cache-Umgehung

Sie können den Cache-Modus BYPASS_CACHE für eine Route konfigurieren, um den Cache bei übereinstimmenden Anfragen absichtlich zu umgehen. Das kann nützlich sein, wenn Sie den Cache für einen kleinen Teil des nicht kritischen Traffics umgehen oder die Verbindung zum Ursprungsserver 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 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

Weitere Informationen finden Sie unter Cache-Entwertung.

Anfragen zum Byte-Bereich

Media CDN unterstützt HTTP-Bereichsanforderungen gemäß RFC 9110.

Außerdem verwendet Media CDN Bereichsanfragen, um größere Antworten vom Ursprung abzurufen. So kann Media CDN einzelne Bytebereiche im Cache speichern und muss nicht das gesamte Objekt auf einmal abrufen, um es im Cache zu speichern.

• Objekte, die größer als 1 MiB sind, werden als Bytebereichsanfragen von jeweils bis zu 2 MiB abgerufen.
• Antworten mit einer Größe von bis zu 1 MiB können ohne Unterstützung von Bytebereichen am Ursprung abgerufen werden.
• Antworten, die größer als 1 MiB sind, werden nicht bereitgestellt, wenn Bytebereiche am Ursprung nicht unterstützt werden.

Die Unterstützung von Bytebereichsanfragen durch den Ursprungsserver wird durch Folgendes bestimmt:

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

Individuelle Ursprungs-Füllungsanfragen für jeden Bytebereich werden als separate Logeinträge protokolliert und ihrer übergeordneten Clientanfrage zugeordnet. Sie können diese Anfragen gruppieren, indem Sie den Wert von jsonPayload.cacheKeyFingerprint für jede Anfrage abgleichen.

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

Mehrteilige Bereichsanfragen

Media CDN unterstützt mehrteilige Bereichsanfragen, mit denen Nutzer mehrere nicht zusammenhängende Segmente einer Datei in einer einzelnen HTTP-Anfrage anfordern können, z. B. Range: bytes=0-499, 1000-1499.

Um die Clientleistung zu maximieren und den Ursprungsserver zu entlasten, kann Media CDN die angeforderten einzelnen Bytebereiche aus seinem Cache bereitstellen und sie in einer einzigen Antwort mit dem HTTP-Statuscode 206 Partial Response an den Client mit dem auf multipart/byteranges gesetzten Content-Type zusammenfassen.

Wenn ein Client einen Multipart-Bereich anfordert, optimiert Media CDN den Prozess für im Cache speicherbare Antworten, indem die Anfrage in eine Reihe von Singlepart-Bereichsanfragen umgewandelt wird. Jede Anfrage hat eine Größe von 2 MB, um alle Teile der vom Client angeforderten Bytebereiche abzudecken. Media CDN verwendet die Antworten dann, um am Edge eine einzelne Multipart-Antwort zu generieren. Dieser Ansatz ermöglicht eine effiziente Nutzung des Cache, reduziert redundante Ursprungsabrufe und unterstützt Anwendungsfälle mit hohem Volumen, z. B. App-Store-Downloads und Betriebssystem-Updates.

Bei nicht im Cache speicherbaren Inhalten leitet Media CDN die Anfrage direkt an den Ursprung weiter.

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

Mit dem Konfigurationswert EdgeCacheOrigin.timeouts.readTimeout können Sie festlegen, wie lange Media CDN zwischen den Lesevorgängen wartet. Dieser Wert sollte in der Regel auf ein Vielfaches (z. B. das Doppelte) der Zieldauer festgelegt werden.

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.
• Weitere Informationen zum Konfigurieren von EdgeCacheService-Ressourcen mit Terraform finden Sie in der Terraform-Registry-Dokumentation.