Caching

Eine im Cache speicherbare Antwort ist eine HTTP-Antwort, die von Cloud CDN gespeichert und schnell abgerufen werden kann. Dies ermöglicht schnellere Ladezeiten. Nicht alle HTTP-Antworten können im Cache gespeichert werden.

Cache-Modi

Mit Cache-Modi können Sie die Faktoren steuern, die bestimmen, ob Cloud CDN Ihre Inhalte im Cache speichert.

Cloud CDN bietet drei Cache-Modi, mit denen definiert wird, wie Antworten im Cache gespeichert werden, ob Cloud CDN die vom Ursprung gesendeten Cache-Anweisungen berücksichtigt und wie Cache-TTLs angewendet werden.

Die verfügbaren Cache-Modi sind in der folgenden Tabelle aufgeführt:

Cache-Modus Verhalten
CACHE_ALL_STATIC Speichert erfolgreiche Antworten automatisch im Cache mit statischen Inhalten, die andernfalls nicht im Cache speicherbar sind. Ursprungantworten, die gültige Caching-Anweisungen festlegen, werden ebenfalls im Cache gespeichert.

Dies ist das Standardverhalten für Cloud CDN-fähige Back-Ends, die mit der Google Cloud CLI oder der REST API erstellt wurden.
USE_ORIGIN_HEADERS Erfordert erfolgreiche Ursprungsantworten, um gültige Cache-Anweisungen und gültige Caching-Header festzulegen. Erfolgreiche Antworten ohne diese Anweisungen werden vom Ursprung weitergeleitet.
FORCE_CACHE_ALL Erfolgreiche Antworten werden bedingungslos gespeichert, wodurch die vom Ursprung festgelegten Cache-Anweisungen überschrieben werden. Dieser Modus ist nicht geeignet, wenn das Back-End private, personenbezogene Inhalte wie dynamische HTML- oder API-Antworten bereitstellt.

Fehlerantworten können im Cache gespeichert werden, auch wenn keine gültigen Cache-Anweisungen vorhanden sind.

Bevor Sie den Cache-Modus auf FORCE_CACHE_ALL setzen, sollten Sie Folgendes beachten:

  • Für signierte URLs oder signierte Cookies überschreibt FORCE_CACHE_ALL das Höchstalter, das in der Google Cloud Console über die Einstellung Höchstalter der Cache-Einträge oder die Option gcloud --signed-url-cache-max-age angegeben wurde.

  • FORCE_CACHE_ALL ändert die Gültigkeitsdauer (TTL) aller zuvor im Cache gespeicherten Inhalte. Diese Änderung kann dazu führen, dass einige Einträge, die zuvor als aktuell betrachtet wurden (da sie längere TTLs aus Ursprungsheadern haben), als veraltet gelten und einige Einträge, die zuvor als veraltet betrachtet wurden, als aktuell angesehen werden.

  • FORCE_CACHE_ALL überschreibt Cache-Anweisungen (Cache-Control und Expires), jedoch nicht die anderen Ursprungsantwortheader. Insbesondere kann ein Vary-Header das Caching unterdrücken, auch wenn der Cache-Modus FORCE_CACHE_ALL ist. Weitere Informationen finden Sie unter Vary-Header.

Eine Anleitung zum Einrichten finden Sie unter Cache-Modus festlegen.

Statischer Inhalt

Statische Inhalte sind immer identisch, selbst wenn von unterschiedlichen Nutzern darauf zugegriffen wird. Die CSS, mit der Sie das Design Ihrer Website gestalten, sowie die JavaScript, um die Interaktivität sowie Video- und Bildinhalte bereitzustellen, ändern sich üblicherweise nicht für jeden Nutzer für eine bestimmte URL (Cache-Schlüssel) und daher lohnt es sich, dass diese an verschiedenen Orten im globalen Edge-Netzwerk von Cloud CDN gespeichert werden.

Wenn Sie den Cache-Modus auf CACHE_ALL_STATIC setzen und eine Antwort keine expliziten Caching-Anweisungen in Cache-Control- oder Expires-Headern enthält, speichert Cloud CDN diese Antwort automatisch für Folgendes im Cache:

  • Web-Assets, einschließlich CSS (text/css), JavaScript (application/javascript) und alle Webschriftarten, einschließlich WOFF2 (font/woff2).
  • Bilder, einschließlich JPEG (image/jpg) und PNG (image/png).
  • Videos, einschließlich H.264, H.265 und MP4 (video/mp4)
  • Audiodateien, darunter MP3 (audio/mpeg) und MP4 (audio/mp4)
  • Formatierte Dokumente, einschließlich PDF (application/pdf).

Die folgende Tabelle enthält eine Zusammenfassung.

Kategorie MIME-Typen
Web-Assets text/css text/ecmascript text/javascript application/javascript
Schriftarten Alle Content-Type, die mit font/* übereinstimmen
Images Alle Content-Type, die mit image/* übereinstimmen
Videos Alle Content-Type, die mit video/* übereinstimmen
Ton Alle Content-Type, die mit audio/* übereinstimmen
Formatierte Dokumenttypen application/pdf und application/postscript

Cloud CDN prüft den HTTP-Antwortheader Content-Type, der den MIME-Typ des bereitgestellten Inhalts widerspiegelt.

Wichtige Hinweise:

  • 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 Content-Type-Header automatisch fest, wenn Sie die Google Cloud Console oder die Google Cloud CLI zum Hochladen von Inhalten verwenden.

  • Cloud Storage stellt Cloud 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 Standardwerten von Cloud Storage im Cache gespeichert, es sei denn, Sie passen die Metadaten zur Cache-Steuerung für Objekte in Cloud Storage explizit an oder überschreiben die von Cloud Storage gesendeten Werte im Modus FORCE_CACHE_ALL.

  • Wenn Sie die Inhaltstypen text/html und application/json im Cache speichern möchten, müssen Sie explizit Cache-Control-Header in der Antwort festlegen und dabei darauf achten, dass Sie nicht unbeabsichtigt die Daten eines Nutzers im Cache speichern und für alle Nutzer bereitstellen.

Wenn eine Antwort aufgrund ihres MIME-Typs im Cache gespeichert werden kann, aber den Cache-Control-Antwortheader private, no-store oder einen Set-Cookie-Header hat, wird sie nicht im Cache gespeichert. Weitere Informationen finden Sie unter Cachebarkeitsregeln.

Andere Inhaltstypen wie HTML (text/html) und JSON (application/json) werden für erfolgreiche Antworten nicht standardmäßig im Cache gespeichert. Diese Antworttypen sind in der Regel dynamisch (nutzerbasiert). Beispiele sind die Daten von Einkaufswagen, Produktseiten mit Nutzerpersonalisierung und authentifizierte API-Antworten. Negatives Caching kann, sofern aktiviert, dazu führen, dass sie für bestimmte Statuscodes dennoch im Cache gespeichert werden.

Cloud CDN verwendet keine Dateierweiterungen im URL-Pfad, um zu bestimmen, ob eine Antwort im Cache gespeichert werden kann, da sich viele gültige, im Cache speicherbaren Antworten nicht in URLs finden lassen.

Im Cache speicherbare Inhalte

Cloud CDN speichert Antworten im Cache, die alle Anforderungen in diesem Abschnitt erfüllen. Einige dieser Anforderungen sind in RFC 7234 spezifiziert, während andere Cloud CDN-spezifisch sind.

Cloud CDN kann den genauen Satz von Bedingungen, unter denen Inhalte im Cache gespeichert werden, regelmäßig ändern. Wenn Sie verhindern möchten, dass Cloud CDN Ihre Inhalte explizit im Cache speichert, befolgen Sie die Richtlinien in RFC 7234, um zu bestimmen, wie eine garantierte, nicht Cache-fähige Antwort angegeben wird. Weitere Informationen finden Sie im Abschnitt Nicht im Cache speicherbare Inhalte, die auf ursprünglichen Headern basieren.

Cloud CDN speichert Antworten im Cache, wenn alle folgenden Bedingungen erfüllt sind:

Attribut Anforderung
Bereitgestellt von Back-End-Dienst, Back-End-Bucket oder ein externes Back-End mit aktiviertem Cloud CDN
Als Antwort auf GET-Anfrage
Statuscode

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451, oder 501.
Aktualität

Die Antwort hat einen Cache-Control-Header mit einer max-age- oder s-maxage-Anweisung oder einen Expires-Header mit einem Zeitstempel in der Zukunft.

Bei cachefähigen Antworten ohne Alter (z. B. mit no-cache) muss die Anweisung public explizit angegeben werden.

Wenn im Cache-Modus CACHE_ALL_STATIC keine Aktualitätsanweisungen vorhanden sind, kommt eine erfolgreiche Antwort mit statischem Inhaltstyp trotzdem zum Caching infrage.

Im Cache-Modus FORCE_CACHE_ALL kann jede erfolgreiche Antwort im Cache gespeichert werden. Dies kann dazu führen, dass private, personenbezogene Inhalte im Cache gespeichert werden. Sie sollten FORCE_CACHE_ALL nur für Back-Ends festlegen, die keine privaten oder dynamischen Inhalte bereitstellen, beispielsweise Cloud Storage-Buckets.

Wenn negatives Caching aktiviert ist und der Statuscode mit einem übereinstimmt, für den das negative Caching eine TTL angibt, kann die Antwort im Cache gespeichert werden, auch wenn keine explizite Cache-Anweisung vorhanden ist.
Inhalt

Bei HTTP/1-Quellen muss die Antwort einen gültigen Content-Length-, Content-Range- oder Transfer-Encoding: chunked-Header enthalten.

Bei Ursprüngen, die erweiterte HTTP-Protokollversionen (HTTP/2 und höher) verwenden, müssen die Antworten keine solchen Header enthalten.
Größe Kleiner oder gleich der maximalen Größe

Bei Antworten mit Größen zwischen 10 MiB und 100 GiB finden Sie unter Bytebereichsanfragen zusätzliche Einschränkungen für die Cache-Fähigkeit.

Beachten Sie bei Cloud Storage-Back-End-Buckets die folgenden zusätzlichen Empfehlungen:

Wenn ein Objekt öffentlich ist und keine Cache-Control-Metadaten angibt, weist Cloud Storage dem Objekt standardmäßig einen Cache-Control: public, max-age=3600-Header zu. Sie können verschiedene Werte mit Cache-Control-Metadaten festlegen.

Ein Beispiel für das Konfigurieren eines externen Application Load Balancers mit einem Back-End-Bucket finden Sie unter Cloud CDN mit einem Back-End-Bucket einrichten.

Maximalgröße

Cloud CDN erzwingt für jede Antwort eine Maximalgröße. Jede Antwort mit einem Text, der die maximale Größe überschreitet, wird nicht im Cache gespeichert, aber trotzdem an den Client gesendet.

Die Maximalgröße hängt davon ab, ob der Ursprungsserver Bytebereichsanfragen unterstützt.

Der Ursprungsserver unterstützt Bytebereichsanfragen Der Ursprungsserver unterstützt keine Bytebereichsanfragen
100 GiB (107.374.182.400 Byte) 10 MiB (10.485.760 Byte)

Fast alle modernen Webserver (einschließlich NGINX, Apache und Varnish) unterstützen Bytebereichsanfragen.

Nicht im Cache speicherbare Inhalte, die auf Ursprungsheadern basieren

Es gibt Prüfungen, die das Caching von Antworten blockieren. Cloud CDN kann den genauen Satz von Bedingungen, mit denen Inhalte im Cache gespeichert werden, regelmäßig ändern. Wenn Sie also verhindern möchten, dass Cloud CDN Ihre Inhalte im Cache speichert, folgen Sie den Richtlinien im Standard (RFC 7234), um festzulegen, wie eine garantierte nicht Cache-fähige Antwort angegeben werden kann.

Cloud CDN speichert eine Antwort nicht im Cache, wenn es die Anforderungen für im Cache speicherbare Inhalte nicht erfüllt oder eine der folgenden Bedingungen zutrifft.

Attribut Anforderung
Bereitgestellt von Back-End-Dienst oder externes Back-End, für das Cloud CDN nicht aktiviert ist
Cookie Hat einen Set-Cookie-Header
Vary-Header Hat einen anderen Wert als Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin oder einen der Header, die so konfiguriert sind, dass sie zu den Cache-Schlüsseleinstellungen gehören.
Anweisung für Antwort Die Antwort hat einen Cache-Control-Header mit der Anweisung no-store oder private, wenn Sie nicht den Cache-Modus FORCE_CACHE_ALL verwenden. In diesem Fall wird der Cache-Control-Header ignoriert.
Anweisung für Anfrage Anfrage hat eine Cache-Control: no-store-Anweisung
Autorisierung anfordern Die Anfrage hat einen Authorization-Header, es sei denn, sie wird von der Antwort Cache-Control überschrieben.
Größe Größer als die Maximalgröße

Wenn Cache-Control: no-store oder private vorhanden ist, der Inhalt aber trotzdem im Cache gespeichert wird, hat dies einen der folgenden Gründe:

  • Die URL-Signierung ist konfiguriert.
  • Der Cache-Modus von Cloud CDN ist so eingestellt, dass das Caching aller Antworten erzwungen wird.

Caching vermeiden

So verhindern Sie, dass vertrauliche Informationen in Cloud-CDN-Caches zwischengespeichert werden:

  1. Achten Sie darauf, dass der Cloud CDN-Cache-Modus nicht auf den Modus FORCE_CACHE_ALL gesetzt ist, in dem alle erfolgreichen Antworten bedingungslos im Cache gespeichert werden.
  2. Fügen Sie einen Cache-Control: private-Header in Antworten ein, die nicht in Cloud CDN-Caches gespeichert werden sollen, oder einen Cache-Control: no-store-Header in Antworten, die nicht in einem Cache, auch nicht im Cache eines Webbrowsers, gespeichert werden sollen.
  3. Signieren Sie keine URLs, die Zugriff auf vertrauliche Informationen ermöglichen. Wenn über eine signierte URL auf Inhalte zugegriffen wird, kommen diese Inhalte ungeachtet der Cache-Control-Anweisungen in der Antwort möglicherweise zum Speichern im Cache infrage.
  4. Bei Ursprungsanfragen (Cache-Füllung) mit dem Anfrageheader Authorization speichert Cloud CDN nur Antworten im Cache, die die Cache-Anweisung public, must-revalidate oder s-maxage enthalten, wenn der Cachemodus auf USE_ORIGIN_HEADERS oder CACHE_ALL_STATIC gesetzt wird. Dadurch wird verhindert, dass versehentlich Inhalte pro Nutzer und Inhalte, die eine Authentifizierung erfordern, gespeichert werden. Der Cache-Modus FORCE_CACHE_ALL hat diese Einschränkung nicht.

Benutzerdefinierte Antwortheader

Mit benutzerdefinierten Antwortheadern können Sie Header angeben, die der klassische Application Load Balancer zu weitergeleiteten Antworten hinzufügt. Mit benutzerdefinierten Antwortheadern können Sie den Cache-Status für Ihre Clients, die geografischen Daten der Clients und Ihre eigenen statischen Antwortheader angeben.

Eine Anleitung finden Sie unter Benutzerdefinierte Antwortheader konfigurieren.

Cache-Schlüssel

Jeder Cache-Eintrag in einem Cloud-CDN-Cache wird durch einen Cache-Schlüssel identifiziert. Wenn eine Anfrage im Cache eingeht, konvertiert der Cache den URI der Anfrage in einen Cache-Schlüssel und vergleicht ihn dann mit den Schlüsseln der im Cache gespeicherten Einträge. Wenn eine Übereinstimmung gefunden wird, gibt der Cache das mit diesem Schlüssel verknüpfte Objekt zurück.

Bei Backend-Diensten verwendet Cloud CDN standardmäßig den vollständigen Anfrage-URI als Cache-Schlüssel. Beispiel: https://example.com/images/cat.jpg ist der vollständige URI für eine bestimmte Anfrage für das Objekt cat.jpg. Dieser String wird als Standard-Cache-Schlüssel verwendet. Nur Anfragen mit genau diesem String stellen eine Übereinstimmung dar. Anfragen für http://example.com/images/cat.jpg oder https://example.com/images/cat.jpg?user=user1 stimmen nicht überein.

Bei Backend-Buckets besteht der Cache-Schlüssel standardmäßig aus dem URI ohne Protokoll oder Host. Standardmäßig werden nur Abfrageparameter, die Cloud Storage bekannt sind, als Teil des Cache-Schlüssels aufgenommen (z. B. "Generation").

Daher werden die folgenden URIs für einen bestimmten Backend-Bucket in dasselbe im Cache gespeicherte Objekt aufgelöst:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

Sie können festlegen, welche Teile des URI im Cache-Schlüssel verwendet werden. Während Dateiname und -pfad immer Teil des Schlüssels sein müssen, können Sie eine beliebige Kombination von Protokoll, Host oder Abfragestring einbeziehen oder weglassen, wenn Sie den Cache-Schlüssel anpassen. In Cache-Schlüssel verwenden wird beschrieben, wie Sie die Cache-Schlüssel anpassen.

URI-Teil Anpassung Beispiel-URLs mit demselben Cache-Schlüssel
Protokoll Das Protokoll im Cache-Schlüssel weglassen.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Den Host im Cache-Schlüssel weglassen.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
Abfragestring

Den Abfragestring im Cache-Schlüssel weglassen.

Teile des Abfragestrings weglassen oder verwenden.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Sie haben nicht nur die Möglichkeit, den ganzen Abfragestring einzubeziehen oder auszulassen, sondern können auch mithilfe von Einschlusslisten und Ausschlusslisten nur Teile des Abfragestrings verwenden.

Abfragestring-Einschlussliste

Sie können selektiv kontrollieren, welche Abfragestringparameter Cloud CDN in Cache-Schlüsseln einbindet. Wenn Sie beispielsweise eine Einschlussliste user erstellen, erstellt https://example.com/images/cat.jpg?user=user1&color=blue einen Cache-Schlüssel https://example.com/images/cat.jpg?user=user1, der auch https://example.com/images/cat.jpg?user=user1&color=red entspricht.

Wenn Sie diese Option verwenden möchten, müssen Sie den Abfragestring einschließen und eine nicht leere Einschlussliste angeben und dürfen keine Ausschlussliste angeben.

Abfragestring-Einschlussliste für Cloud Storage-Cache-Schlüssel

Das Einbinden von URL-Abfrageparametern in Cache-Schlüssel für Cloud Storage-Buckets unterstützt das Cache-Busting. Mit Cache Busting kann ein Nutzer eine neue Version der hochgeladenen Datei abrufen, auch wenn die vorherige Version aufgrund der TTL-Einstellung noch gültig im Cache gespeichert ist.

Sie können eine Einschlussliste mit Abfragestringparametern im Cache-Schlüssel verwenden, der zum Bereitstellen von Antworten aus einem Backend-Bucket verwendet wird. Obwohl Cloud Storage keine unterschiedlichen Inhalte oder Routen auf der Grundlage von Abfrageparametern bereitstellt, können Sie Parameter angeben, die es Ihnen ermöglichen, statische Inhalte, die in Cloud Storage-Buckets gespeichert sind, aus dem Cache zu entfernen.

Sie können beispielsweise den Abfrageparameter ?version=VERSION oder ?hash=HASH anhängen, der auf dem zugrunde liegenden Inhalt basiert. Dies verringert die Notwendigkeit, Inhalte proaktiv ungültig zu machen, und steht im Einklang mit modernen Webentwicklungs-Workflows, bei denen Web-Frameworks und URLs einen Hash des Inhalts verwenden, um zu vermeiden, dass veraltete Objekte über mehrere Implementierungen hinweg bereitgestellt werden.

Da die Aufnahme von Abfrageparametern in den Cache-Schlüssel nur auf freiwilliger Basis erfolgt, unterstützt Cloud CDN nicht den Ausschluss von Abfrageparametern aus einem Cache-Schlüssel für einen Backend-Bucket.

Abfragestring-Ausschlussliste

Mit einer Ausschlussliste können Sie gezielt steuern, welche Abfragestringparameter Cloud CDN ignoriert. Wenn Sie beispielsweise eine Ausschlussliste user erstellen, werden alle Abfragestringparameter außer user im Cache-Schlüssel verwendet.

Wenn die Ausschlussliste konfiguriert und die Eingabe https://example.com/images/cat.jpg?user=user1&color=blue ist, erstellt Cloud CDN den Cache-Schlüssel https://example.com/images/cat.jpg?color=blue, der ebenfalls mit https://example.com/images/cat.jpg?user=user2&color=blue, aber nicht mit https://example.com/images/cat.jpg?user=user1&color=red übereinstimmt.

Wenn Sie diese Option verwenden möchten, müssen Sie den Abfragestring einschließen und eine nicht leere Ausschlussliste angeben und dürfen keine Einschlussliste angeben.

Reihenfolge der Abfrageparameter

Der generierte Cache-Schlüssel hängt nicht von der Reihenfolge der Abfrageparameter ab.

Die folgenden Abfrageparameter generieren beispielsweise denselben Cache-Schlüssel:

  • info=123&variant=13e&geography=US
  • geography=US&variant=13e&info=123

Einstellungen für HTTP-Header und HTTP-Cookies im Cache

Mit den folgenden Konfigurationseinstellungen für den Cache-Schlüssel können Sie die Cache-Trefferraten und die Ursprungsentlastung verbessern.

  • Für Backend-Dienste und -Buckets: Verwenden Sie HTTP-Header als Teil von Cache-Schlüsseln. Nehmen Sie dazu benannte Header in die Cache-Schlüsselkonfiguration auf.
  • Nur für Backend-Dienste: Verwenden Sie benannte HTTP-Cookies als Cache-Schlüssel, z. B. für A/B-Tests (multivariate Tests), Canarying und ähnliche Szenarien.

Cache-Anfragen, die zusätzliche HTTP-Header oder HTTP-Cookies in der Anfrage enthalten, werden bei der dritten Anfrage an einem Cache-Speicherort für diesen Cache-Schlüssel im Cache gespeichert. Dadurch werden die Auswirkungen von Header- oder Cookie-Werten mit hoher Kardinalität auf Ihre Cache-Entfernungsraten reduziert. Unter normalen Umständen und unter den Bedingungen des Nutzertraffics sollte dies nicht auffallen und trägt dazu bei, dass beliebte Inhalte im Cache bleiben.

Anfrageheader einschließen

Wenn Sie zusätzliche Varianten einer Antwort im Cache speichern möchten, können Sie zusätzliche Anfrageheader in den Cache-Schlüssel aufnehmen.

Einige Header sind in Cache-Schlüsseln nicht zulässig, da sie normalerweise eine sehr hohe Kardinalität haben. In den meisten Fällen sind die Werte dieser Header entweder eindeutig pro Nutzer (Cookie, Authorization) oder haben Tausende von wahrscheinlichen Werten (Referer, User-Agent, Accept). Beispielsweise kann der User-Agent-Header angesichts der großen Vielfalt an Browsern, Nutzergeräten und Betriebssystemen über 5000 eindeutige Werte haben. Diese Headertypen haben erhebliche negative Auswirkungen auf die Cache-Trefferquoten.

Nur gültige HTTP-Header-Feldnamen werden gemäß RFC 7230 akzeptiert. Bei Headernamen wird die Groß-/Kleinschreibung nicht berücksichtigt und Duplikate werden abgelehnt.

Optional kannst du deinen Ursprungsserver so konfigurieren, dass konfigurierte Cache-Schlüssel-Anfrage-Header in der Vary-Antwort enthalten sind. Sie ist für Cloud CDN nicht erforderlich, kann aber für Downstream-Caches hilfreich sein. Weitere Informationen finden Sie unter Vary-Header.

In Cloud CDN können die folgenden Header nicht in die Liste der Header aufgenommen werden:

  • Accept
  • Accept-Encoding
  • Authority, da dies durch die Konfiguration gesteuert wird (cdnPolicy.includeHost)
  • Authorization, normalerweise pro Nutzer, wie in OAuth-Bearer-Token
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, häufig pro Client oder Proxy
  • From
  • Host, da dies durch die Konfiguration gesteuert wird (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since oder If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (oder Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken und X-CSRF-Token, wie sie von Django und Ruby on Rails verwendet werden
  • X-Forwarded-For, häufig pro Client oder Proxy
  • X-User-IP
  • Jeder Header, der mit folgendem Text beginnt:
    • Access-Control-, z. B. Access-Control-Request-Headers und Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Gleiche Header mit unterschiedlichen Werten

Angenommen, der Nutzer sendet mehrere Header mit demselben Namen mit unterschiedlichen Header-Werten. Beispiel:

My-Header: Value1
My-Header: Value2

In diesem Fall ändert Cloud CDN die Anfrage unter der Annahme, dass der Header der Standardkonvention entsprechen muss, die es erlaubt, dass einige Header mehrere Werte haben. Cloud CDN fasst sie in einer durch Kommas getrennten Liste zusammen, die an das Backend gesendet wird, sodass es so aussieht, als ob der Client Folgendes senden würde:

My-Header: Value1, Value2

Benannte Cookies einschließen

Ein HTTP-Cookie ist ein name=value-Pairing, und eine Anfrage kann mehrere HTTP-Cookies enthalten, entweder getrennt durch ein Semikolon in derselben Zeile oder als eigenständige Cookie-Anfrageheader mit einem Cookie pro Header.

Sie können eine Liste mit bis zu fünf Cookie-Namen angeben.

User-Agents (z. B. Webbrowser) begrenzen oft die Anzahl der pro Domain gespeicherten Cookies auf 4 KB. Achten Sie darauf, nicht zu viele (oder zu große) Cookies zu senden, da der User-Agent möglicherweise nicht alle Cookies in einer Anfrage sendet. Dies kann sich darauf auswirken, ob ein Nutzer eine bestimmte im Cache gespeicherte Antwort erhält.

Wenn Sie Ihre statischen Inhalte von einem anderen Hostnamen aus bereitstellen, von dem aus Sie Cookies ausgeben, stellen Sie sicher, dass das Domain-Attribut des Cookies (und das Path-Attribut) es zulässt, dass das Cookie zusammen mit Anfragen für statische Inhalte gesendet wird.

Wenn eine Anfrage mehrere Instanzen desselben Cookienamens enthält, wird nur die erste berücksichtigt.

Anweisungen zur Cache-Steuerung

Anweisungen zur HTTP-Cache-Steuerung wirken sich auf das Verhalten von Cloud CDN aus, wie in der folgenden Tabelle dargestellt.

– bedeutet, dass eine Anweisung nicht auf Anfragen oder Antworten anwendbar ist.

Anweisung Anfrage Antwort
no-store Wenn in einer Anfrage vorhanden, wird dies von Cloud CDN berücksichtigt und die Antwort nicht im Cache gespeichert.

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

Dies kann für einzelne Back-Ends mit dem Cache-Modus FORCE_CACHE_ALL überschrieben werden.

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

Eine Antwort mit no-cache wird im Cache gespeichert, muss aber noch einmal mit dem Ursprung validiert werden, bevor sie bereitgestellt wird.

Dies kann für einzelne Back-Ends mit dem Cache-Modus FORCE_CACHE_ALL überschrieben werden.

public –

Diese Anweisung ist für die Cache-Fähigkeit nicht erforderlich. Es empfiehlt sich jedoch, sie für Inhalte aufzunehmen, die von Proxys im Cache gespeichert werden sollen.

private –

Eine Antwort mit der Anweisung private wird von Cloud CDN nicht im Cache gespeichert, auch wenn die Antwort ansonsten als cachefähig gilt. Clients wie Browser können das Ergebnis jedoch weiterhin im Cache speichern.

Dies kann für einzelne Back-Ends mit dem Cache-Modus FORCE_CACHE_ALL überschrieben werden. Verwenden Sie no-store, um das gesamte Caching der Antworten zu verhindern.

max-age=SECONDS Die Anfrageanweisung max-age wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. Eine Antwort mit der Anweisung max-age wird bis zur festgelegten Anzahl an SECONDS im Cache gespeichert.
s-maxage=SECONDS –

Eine Antwort mit der Anweisung s-maxage wird bis zur festgelegten Anzahl an SECONDS im Cache gespeichert.

Wenn sowohl max-age als auch s-maxage vorhanden sind, wird s‑maxage von Cloud CDN verwendet.

Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt.

s-max-age (zwei Bindestriche) ist für das Caching nicht anwendbar.

min-fresh=SECONDS Die Anfrageanweisung min-fresh wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. –
max-stale=SECONDS

Die Anfrageanweisung max-stale gibt die maximale Veralterung in Sekunden an, die der Client akzeptiert.

Cloud CDN berücksichtigt dies und gibt eine veraltete Cache-Antwort nur zurück, wenn die Veralterung der Antwort geringer als der Wert der Anweisung max-stale ist. Andernfalls wird die Anfrage noch einmal validiert, bevor die Anfrage bereitgestellt wird.

 –
stale-while-revalidate=SECONDS –

Eine Antwort mit stale-while-revalidate wird bis zur festgelegten Anzahl an SECONDS für einen Client bereitgestellt, während die nochmalige Validierung asynchron erfolgt.

Dieses Verhalten kann für alle Antworten durch Festlegen von cdnPolicy.serveWhileStale für das Back-End aktiviert werden.

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.

Dieser Antwortheader hat keine Auswirkungen.

must-revalidate –

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

Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt.

proxy-revalidate

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

Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt.

immutable – Keine Auswirkungen. Dies wird in der Antwort an den Client weitergegeben.
no-transform – Cloud CDN wendet keine Transformationen an.
only-if-cached Die Anfrageanweisung only-if-cached wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten. –

Sofern möglich, versucht Cloud CDN RFC-konform zu sein (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/oder 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.
  • Wenn die Antwort einen Cache-Control-Header enthält, ignoriert Cloud CDN den Header Expires.

Wenn in der Antwort ein gültiger Expires-Header für einen Ablauf in der Zukunft vorhanden ist, kann die Antwort im Cache gespeichert werden. Es müssen dann keine anderen Cache-Anweisungen angegeben werden.

Der HTTP/1.0-Header Pragma wird, wenn er in einer Antwort enthalten ist, ignoriert und unverändert an den Client weitergegeben. Clientanfragen mit diesem Header werden an den Ursprung weitergeleitet und haben keinen Einfluss darauf, wie eine Antwort von Cloud CDN bereitgestellt wird.

Vary-Header

Der Vary-Header gibt an, dass die Antwort je nach Anfrageheader des Clients variiert. Zusätzlich zum Anfrage-URI berücksichtigt Cloud CDN Vary-Header, die Ursprungsserver in Antworten aufnehmen. Wenn in einer Antwort zum Beispiel Vary: Accept angegeben wird, verwendet Cloud CDN einen Cache-Eintrag für Anfragen, die Accept: image/webp,image/*,*/*;q=0.8 angeben und eine weitere für Anfragen, die Accept: */* angeben.

Die Tabelle im Abschnitt Nicht im Cache speicherbare Inhalte enthält die Vary-Header, mit denen Inhalte im Cache gespeichert werden können. Andere Vary-Headerwerte verhindern, dass Inhalte im Cache gespeichert werden.

Im Cache-Modus FORCE_CACHE_ALL wird dieses Verhalten nicht überschrieben. Die Vary-Header sind wichtig, um ein Cache-Poisoning zwischen mehreren möglichen Ursprungsserverantworten zu vermeiden. Es wäre für FORCE_CACHE_ALL gefährlich, wenn diese Antworten im Cache gespeichert würden.

Vary-Header werden manchmal verwendet, wenn komprimierter Inhalt bereitgestellt wird. Cloud CDN komprimiert oder dekomprimiert Antworten nicht selbst (es sei denn, die dynamische Komprimierung ist aktiviert), kann aber Antworten bereitstellen, die vom Ursprungsserver komprimiert wurden. Wenn der Ursprungsserver entscheidet, ob er basierend auf dem Wert des Accept-Encoding-Anfrageheaders komprimierte oder unkomprimierte Inhalte bereitstellen soll, muss in der Antwort Vary: Accept-Encoding angegeben sein.

Wenn Sie HTTP-Header im Cache-Schlüssel verwenden, speichert Cloud CDN mehrere Kopien der Antwort basierend auf den Werten der angegebenen Anfrageheader. Das ist ähnlich wie bei der Vary-Unterstützung, aber der Ursprungsserver muss keinen Vary-Antwortheader explizit angeben. Wenn der Ursprung die Cache-Schlüssel-Header in der Vary-Antwort angibt, behandelt Cloud CDN die Antwort korrekt, als wären die Header nicht in der Vary-Antwort erwähnt.

Ablaufzeiten und Validierungsanfragen

Die Ablaufzeit eines Cache-Eintrags definiert, wie lange ein Cache-Eintrag gültig bleibt. Der Wert, der durch den Wert s-maxage (oder max-age oder expires) angegeben wird, ermöglicht die automatische Neuvalidierung von veralteten, nutzergenerierten Cache-Inhalten.

Wenn Cloud CDN eine Anfrage erhält, sucht es nach dem entsprechenden Cache-Eintrag und prüft dessen Alter. Wenn der Cache-Eintrag vorhanden und aktuell genug ist, kann die Antwort vom Cache geliefert werden. Wenn aber die Ablaufzeit verstrichen ist, versucht Cloud CDN, den Cache-Eintrag neu zu validieren und dafür eine Verbindung zu einem Ihrer Back-Ends herzustellen. Dies geschieht vor der Bereitstellung der Antwort, es sei denn, Sie aktivieren serve-while-stale. In diesem Fall erfolgt die erneute Validierung asynchron.

Bei einigen Cache-Modi können Sie TTL-Werte festlegen. Weitere Informationen finden Sie unter TTL-Einstellungen und -Überschreibungen verwenden.

Der Cache-Modus wirkt sich auf die Bestimmung der Aktualität aus.

Cache-Modus Validierungsverhalten
CACHE_ALL_STATIC Die Ursprungsheader (Cache-Control: s-maxage-, Cache-Control: max-age- oder Expires-Header) werden zur Bestimmung der Aktualität geprüft. Bei statischen Inhalten bestimmt die konfigurierte default_ttl die Aktualität, wenn keine Ursprungsheader vorhanden sind. Wenn der statische Inhalt älter als default_ttl ist, wird er von Cloud CDN neu validiert.
USE_ORIGIN_HEADERS Jeder Cache-Eintrag in einem Cloud CDN-Cache hat eine von den Cache-Control: s-maxage-, Cache-Control: max-age und/oder Expires-Headern gemäß RFC 7234 definierte Ablaufzeit.
FORCE_CACHE_ALL Anstelle von Ursprungsheadern bestimmt die konfigurierte Wert für default_ttl die Aktualität. Wenn der Inhalt älter als default_ttl ist, wird er von Cloud CDN neu validiert.

Wenn mehr als ein Header vorhanden ist, hat Cache-Control: s-maxage Vorrang gegenüber Cache-Control: max-age und Cache-Control: max-age hat Vorrang gegenüber Expires.

Standardmäßig wenn der Ablaufzeitwert 30 Tage (2.592.000 Sekunden) überschreitet, behandelt Cloud CDN den Ablaufwert so, als würde er 2.592.000 Sekunden betragen. Downstream-Clients sehen die genauen Werte von max-age und s-maxage auch dann, wenn sie über 30 Tage hinausgehen.

Bereinigung

Es gibt keine Garantie, dass ein Cache-Eintrag bis zum Ablauf im Cache verbleibt, da seltene Einträge vor dem Ablauf jederzeit entfernt werden können um Platz für neue Inhalte zu schaffen. Cache-Einträge, die 30 Tage lang nicht aufgerufen wurden, automatisch entfernt.

Weitere Informationen finden Sie unter Bereinigung und Ablauf.

Bedingte Anfragen zur Validierung verwenden

Cloud CDN kann versuchen, die Informationen in den im Cache gespeicherten Antwortheadern zu verwenden, um den Cache-Eintrag mit dem Backend zu validieren. Dies ist möglich, wenn Folgendes zutrifft:

  • Die zuvor im Cache gespeicherte Antwort hat einen Last-Modified- oder ETag-Header.
  • Die Clientanfrage ist eine GET-Anfrage, die keine If-Modified-Since- oder If-None-Match-Header enthält.

Diese Validierung durch Cloud CDN variiert geringfügig, je nachdem, ob die Antwort mit Bytebereichsanfragen im Cache gespeichert wurde:

  • Wenn die Antwort mit Bytebereichsanfragen im Cache gespeichert wurde, initiiert Cloud CDN eine separate Validierungsanfrage mit den If-Modified-Since- und If-None-Match-Headern.
  • Andernfalls fügt Cloud CDN der Clientanfrage die If-Modified-Since- und If-None-Match-Header hinzu und leitet die geänderte Anfrage an das Back-End weiter.

Wenn die im Cache gespeicherte Kopie noch aktuell ist, kann das Back-End den vorhandenen Cache-Eintrag durch Senden einer 304 Not Modified-Antwort validieren. In diesem Fall sendet das Back-End nur die Antwortheader, nicht aber den Antworttext. Cloud CDN fügt neue Antwortheader im Cache ein, aktualisiert die Ablaufzeit und sendet dem Client die neuen Antwortheader und den im Cache gespeicherten Antworttext.

Wenn die zuvor im Cache gespeicherte Antwortvorlage keinen Last-Modified- oder ETag-Header enthält, ignoriert Cloud CDN den abgelaufenen Cache-Eintrag und leitet die Clientanfrage unverändert an das Backend weiter.

Unterstützung für Bytebereichsanfragen

Durch eine Antwort, die die folgenden Kriterien erfüllt, wird angegeben, dass der Ursprungsserver Bytebereichsanfragen unterstützt:

  • Statuscode: 200 OK oder 206 Partial Content
  • Header: Accept-Ranges: bytes
  • Header: Content-Length und bei einer 206 Partial Content-Antwort ein Content-Range-Wert, der die vollständige Länge des Ursprungsobjekts angibt. Beispiel: Content-length: 0-100/999 kann im Cache gespeichert werden, Content-length: 0-100/* jedoch nicht.
  • Header: Last-Modified und ETag mit einem starken Validator

Cloud Storage unterstützt Bytebereichsanfragen für die meisten Objekte. Cloud Storage unterstützt jedoch keine Bytebereichsanfragen für Objekte mit Content-Encoding: gzip-Metadaten, es sei denn, die Clientanfrage enthält einen Accept- Encoding: gzip-Header. Wenn Sie Cloud Storage-Objekte mit über 10 MB haben, achten Sie darauf, dass sie keine Content-Encoding: gzip-Metadaten enthalten. Informationen zum Bearbeiten von Objektmetadaten finden Sie unter Objektmetadaten ansehen und bearbeiten.

Beliebte Webserver-Software unterstützt ebenfalls Bytebereichsanfragen. Wie Sie die Unterstützung aktivieren können, erfahren Sie in der Dokumentation zu Ihrem Webserver. Weitere Informationen zu Bytebereichsanfragen finden Sie in der HTTP-Spezifikation.

Wenn ein Ursprungsserver Bytebereichsanfragen unterstützt, lehnt ein Cloud CDN-Cache das Speichern einer ansonsten im Cache speicherbaren Antwort bei der ersten Anfrage ab, wenn eine der folgenden Bedingungen erfüllt ist:

  • Der Antworttext ist unvollständig, da der Client nur einen Teil des Inhalts abgefragt hat
  • Der Antworttext ist größer als 1 MB (1.048.576 Byte).

Wenn dies der Fall ist und die Antwort ansonsten die normalen Cache-Anforderungen erfüllen würde, registriert der Cache, ob der Ursprungsserver Bytebereichsanfragen für diesen Cache-Schlüssel unterstützt, und leitet die Antwort des Ursprungsservers an den Client weiter.

Bei einem Cachefehler prüft der Cache, ob der Ursprungsserver bekanntermaßen Bytebereichsanfragen unterstützt. Wenn das für den Cache-Schlüssel der Fall ist, leitet der Cache die Clientanfrage nicht an den externen Application Load Balancer weiter. Stattdessen initiiert der Cache eigene Bytebereichsanfragen zur Cachefüllung für die fehlenden Teile des Inhalts.

Der Ursprungsserver gibt eine 206 Partial Content-Antwort zurück, wenn Cloud CDN eine eigene Cache-Füllanfrage für den Bytebereich initiiert. Damit eine 206 Partial Content-Antwort beim Caching berücksichtigt wird, muss sie einen Content-Range-Header mit einer complete-length-Anweisung ohne Sternchen enthalten, z. B. 0-100/999. Cloud CDN speichert dann die zurückgegebene 206 Partial Content-Antwort im Cache und verwendet sie, um zukünftige Clientanfragen für diese Inhalte zu beantworten.

In einem Cache wird eine 206 Partial Content-Antwort nur dann gespeichert, wenn sie als Antwort auf eine vom Cache initiierte Bytebereichsanfrage empfangen wird. Da ein Cache eine Bytebereichsanfrage nur dann initiiert, wenn vorher festgestellt wurde, dass der Ursprungsserver für diesen Cache-Schlüssel Bytebereichsanfragen unterstützt, speichert der jeweilige Cache einen Inhalt, der größer als 1 MB ist, erst beim zweiten Zugriff auf diesen.

Aufgrund seiner Verteilung kann Cloud CDN den letzten Teil des Ursprungs manchmal mehr als einmal pro Standort abrufen. Dies betrifft nur die ersten Anfragen pro Cache-Schlüssel.

Minimierungsanfrage senden (Maskierung)

Die Minimierungsanfrage (oder Kollierung) minimiert aktiv mehrere nutzergesteuerte Cache-Füllanfragen für denselben Cache-Schlüssel in einer einzigen Ursprungsanfrage pro Edge-Knoten. Dies kann die Auslastung des Ursprungsorts aktiv verringern und gilt sowohl für die Element-Anfragen (Antworten, die direkt abgerufen werden) und für Chunk-Anfragen, in der Cloud CDN Range-Anfragen verwendet werden, um größere Objekte effizienter abzurufen.

Die Minimierungsanfrage ist standardmäßig aktiviert.

Minimierungsanfragen verhalten sich folgendermaßen:

  • Minimierte Anfragen erfassen sowohl die clientseitige Anfrage als auch die (minimierte) Cache-Füllungsanfrage.
  • Der Leader der minimierten Sitzung wird zum Erstellen der Füllanfrage für den Ursprung verwendet.
  • Anfrageattribute, die nicht Teil des Cache-Schlüssels sind, z. B. der Header User-Agent oder Accept-Encoding, beziehen sich nur auf den Leader der minimierten Sitzung.
  • Anfragen ohne den gleichen Cache-Schlüssel können nicht minimiert werden.

Das folgende Diagramm zeigt, wie Anfragen verkettet werden:

Cloud CDN mit aktivierter Minimierungsanfrage
Cloud CDN mit aktivierter Minimierungsanfrage (zum Vergrößern anklicken)

Im Vergleich dazu kann bei deaktivierten Minimierungsanfragen oder bei Anfragen, die nicht korreliert werden können, die Anzahl der Ursprungsanfragen und -antworten gleich der Anzahl der Clients sein, die versuchen, ein Objekt abzurufen, das derzeit nicht im Cache gespeichert ist.

Cloud CDN ohne aktivierte Minimierungsanfragen
Cloud CDN ohne Minimierungsanfragen (zum Vergrößern klicken)

Für alle Arten von Anfragen ist die Minimierung standardmäßig aktiviert. Bei Elementanfragetypen können Sie die Minimierung deaktivieren. Wir empfehlen, die Minimierung von Artikelanfragen bei sehr latenzempfindlichen Szenarien wie der Anzeigenbereitstellung zu deaktivieren, wenn die Herkunftslast nicht berücksichtigt wird.

In der folgenden Tabelle sind die Standardverhalten und die Konfiguration für verschiedene Anfragetypen zusammengefasst.

Art der Anfrage Standardverhalten Konfigurierbar Vorteile der Minimierung
Chunk-Anfragen Aktiviert Nein Die Ursprungsbandbreite kann deutlich reduziert werden.
Artikelanfragen Aktiviert Ja Kann das Volumen der ursprünglichen Anfrage reduzieren

So deaktivieren Sie das Minimieren von Elementanfragen mithilfe der Google Cloud CLI für einen Backend-Bucket, der auf einen Cloud Storage-Bucket verweist:

gcloud

Verwenden Sie den Befehl gcloud compute backend-services oder backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

So aktivieren Sie das Minimieren von Elementanfragen für einen Backend-Bucket mithilfe der Google Cloud CLI:

gcloud

Führen Sie den Befehl gcloud compute backend-buckets aus:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

So aktivieren Sie das Minimieren von Elementanfragen mithilfe der Google Cloud CLI für einen Backend-Dienst, einschließlich VM-Gruppen und externen Backends:

gcloud

Führen Sie den Befehl gcloud compute backend-services aus:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Von Cloud CDN initiierte Anfragen

Wenn Ihr Ursprungsserver Bytebereichsanfragen unterstützt, kann Cloud CDN als Antwort auf eine einzelne Clientanfrage mehrere Anfragen an Ihren Ursprungsserver senden. Cloud CDN kann zwei Arten von Anfragen initiieren: Validierungsanfragen und Bytebereichsanfragen.

Wenn die Antwort, der zufolge Ihr Ursprungsserver Bytebereichsanfragen unterstützt, für einen bestimmten Cache-Schlüssel abgelaufen ist, initiiert Cloud CDN eine Validierungsanfrage, um zu bestätigen, dass der Inhalt nicht geändert wurde und dass der Ursprungsserver weiterhin Bereichsanfragen für den Inhalt unterstützt. Wenn Ihr Ursprungsserver mit einer 304 Not Modified-Antwort antwortet, setzt Cloud CDN den Inhalt mit Bytebereichen fort. Andernfalls leitet Cloud CDN die Antwort des Ursprungsservers an den Client weiter. Sie können Ablaufzeiten mit den Antwortheadern Cache-Control und Expires steuern.

Bei einem Cache-Fehler initiiert Cloud CDN Cache-Füllungsanfragen für verschiedene Bytebereiche, die sich mit der Clientanfrage überschneiden. Wenn einige Bereiche des vom Client angeforderten Inhalts im Cache vorhanden sind, stellt Cloud CDN Inhalte so weit wie möglich aus dem Cache bereit und sendet nur für die fehlenden Bereiche Bytebereichsanfragen an den Ursprungsserver.

Durch jede von Cloud CDN initiierte Bytebereichsanfrage wird ein Bereich angegeben, der mit einem Offset beginnt, der ein Vielfaches von 2.097.136 Byte beträgt. Jeder Bereich ist ebenfalls 2.097.136 Byte groß. Nur der letzte ist kleiner, wenn der Inhalt kein Vielfaches dieser Größe ist. Die Größe und Offsets, die in Bytebereichsanfragen verwendet werden, können sich in Zukunft ändern.

Angenommen, es liegt eine Clientanfrage für die Byte 1.000.000 bis 3.999.999 eines Inhalts vor, der nicht im Cache vorhanden ist. In diesem Beispiel könnte Cloud CDN zwei GET-Anfragen initiieren: eine für die ersten 2.097.136 Byte des Inhalts und eine weitere für die zweiten 2.097.136 Byte. Dies führt zu einer Cache-Füllung von 4.194.272 Byte, obwohl der Client nur 3.000.000 Byte angefordert hat.

Wenn Sie als Ursprung einen Cloud Storage-Bucket verwenden, wird jede GET-Anfrage als separater Vorgang der Klasse B berechnet. Ihnen werden alle GET-Anfragen in Rechnung gestellt, die von Cloud Storage verarbeitet werden, einschließlich aller von Cloud CDN initiierten Anfragen. Wenn eine Antwort vollständig aus einem Cloud CDN-Cache bereitgestellt wird, werden keine GET-Anfragen an Cloud Storage gesendet und es werden Ihnen keine Cloud Storage-Vorgänge in Rechnung gestellt.

Wenn Cloud CDN eine Validierungsanforderung oder Bytebereichsanforderung initiiert, sind darin keine clientspezifischen Header wie Cookie oder User-Agent enthalten.

Im Feld httpRequest.userAgent von Cloud Logging bedeutet Cloud-CDN-Google, dass Cloud CDN die Anfrage initiiert hat.

Cache umgehen

Mit der Cache-Umgehung können Anfragen mit bestimmten Anfrage-Headern den Cache umgehen, selbst wenn der Inhalt zuvor im Cache gespeichert war.

Dieser Abschnitt enthält Informationen zum Umgehen des Caches mit HTTP-Headern wie Pragma und Authorization. Diese Funktion ist nützlich, wenn Sie sicherstellen möchten, dass Ihre Nutzer oder Kunden immer die neuesten Inhalte vom Ursprungsserver erhalten. Dies ist zum Testen, Einrichten von Staging-Verzeichnissen oder Skripts sinnvoll.

Wenn ein bestimmter Header übereinstimmt, wird der Cache für alle Einstellungen im Cache-Modus umgangen, sogar FORCE_CACHE_ALL. Die Cache-Umgehung führt zu einer großen Anzahl von Cache-Fehlern, wenn die angegebenen Header bei vielen Anfragen gleich sind.

Hinweis

  • Achten Sie darauf, dass Cloud CDN aktiviert ist. Eine Anleitung hierzu finden Sie unter Cloud CDN verwenden.

  • Aktualisieren Sie bei Bedarf auf die neueste Version der Google Cloud CLI:

    gcloud components update

Cache-Umgehung konfigurieren

Sie können bis zu fünf HTTP-Header-Namen angeben. Bei den Werten wird die Groß- und Kleinschreibung berücksichtigt. Der Headername muss ein gültiges HTTP-Headerfeld-Token sein. Ein Headername darf in der Liste der hinzugefügten Header nicht mehr als einmal vorkommen. Regeln für gültige Headernamen finden Sie unter Funktionsweise von benutzerdefinierten Headern.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Zur Seite „Load-Balancing“

  2. Klicken Sie auf den Namen Ihres externen Application Load Balancers.
  3. Klicken Sie auf Bearbeiten .
  4. Wählen Sie unter Back-End-Konfiguration ein Back-End aus und klicken Sie auf Bearbeiten .
  5. Achten Sie darauf, dass Cloud CDN aktivieren ausgewählt ist.
  6. Klicken Sie unten im Fenster auf Erweiterte Konfigurationen.
  7. Klicken Sie unter Cache für Anfrage-Header umgehen auf Header hinzufügen.
  8. Geben Sie einen Header-Namen ein, z. B. Pragma oder Authorization.
  9. Klicken Sie auf Aktualisieren.
  10. Klicken Sie noch einmal auf Aktualisieren.

gcloud

Verwenden Sie für Back-End-Buckets den Befehl gcloud compute backend-buckets create oder gcloud compute backend-buckets update mit dem Flag --bypass-cache-on-request-headers.

Verwenden Sie für Back-End-Dienste den Befehl gcloud compute backend-services create oder gcloud compute backend-services update mit dem Flag --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

Beispiel:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

API

Verwenden Sie für Back-End-Buckets den API-Aufruf Method: backendBuckets.insert, Method: backendBuckets.update oder Method: backendBuckets.patch..

Verwenden Sie für Back-End-Dienste den API-Aufruf Method: backendServices.insert, Method: backendServices.update oder Method: backendServices.patch..

Beispiele:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

Fügen Sie dem JSON-Anfragetext folgendes Snippet hinzu:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Cache-Umgehung deaktivieren

gcloud

Verwenden Sie für Back-End-Buckets den Befehl gcloud compute backend-buckets create oder gcloud compute backend-buckets update mit dem Flag --no-bypass-cache-on-request-headers.

Verwenden Sie für Back-End-Dienste den Befehl gcloud compute backend-services create oder gcloud compute backend-services update mit dem Flag --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

API

Verwenden Sie für Back-End-Buckets den API-Aufruf Method: backendBuckets.insert oder Method: backendBuckets.update.

Verwenden Sie für Back-End-Dienste den API-Aufruf Method: backendServices.insert oder Method: backendServices.update.

Verwenden Sie einen der folgenden API-Aufrufe:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

Fügen Sie dem JSON-Anfragetext folgendes Snippet hinzu:

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

Nächste Schritte

  • Informationen dazu, wie Cache-Modi das Speichern von Inhalten im Cache erleichtern, finden Sie unter Cache-Modi verwenden.
  • Informationen zum Aktivieren von Cloud CDN für Ihre HTTP(S)-Instanz mit Load-Balancing und Storage-Buckets finden Sie unter Cloud CDN verwenden.
  • Weitere Informationen zum Entwerten von Caches finden Sie unter Übersicht zur Cache-Entwertung.
  • Informationen zu GFE-Points-of-Presence finden Sie unter Cache-Speicherorte.