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:

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 wird ein Vary-Header weiter berücksichtigt und das Caching kann auch bei Verwendung des Modus FORCE_CACHE_ALL unterdrückt werden. 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.

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 beim Upload fest, wenn Sie die Google Cloud Console oder die Google Cloud CLI zum Hochladen von Inhalten verwenden.

• 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 (vollständige Liste der Regeln), wird sie nicht im Cache gespeichert.

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.

Wenn du die Inhaltstypen text/html und application/json im Cache speichern möchtest, musst du explizite Cache-Control-Header in der Antwort festlegen, wobei Achten Sie darauf, nicht versehentlich die Daten eines Nutzers im Cache zu speichern und sie allen Nutzern bereitzustellen.

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:

Bei Cloud Storage-Back-End-Buckets können Sie diese Anforderungen auf folgende Arten erfüllen:

• Bucket öffentlich lesbar machen Wir empfehlen diesen Ansatz für öffentliche Inhalte. Mit dieser Einstellung kann jeder im Internet Ihre Objekte und ihre Metadaten anzeigen und auflisten. ACLs sind davon ausgenommen. Sie sollten bestimmte Buckets für öffentliche Objekte zuweisen.

• Mit verwalteten Ordnern können Sie einen Teil Ihres Buckets öffentlich lesbar machen.

• Machen Sie einzelne Objekte öffentlich lesbar. Wir empfehlen diesen Ansatz nicht, da dabei ein älteres, Cloud Storage-spezifisches Berechtigungssystem verwendet wird.

• Speichern Sie das Objekt nicht in einem Bucket, für den Anforderer bezahlt aktiviert ist oder sich innerhalb eines Virtual Private Cloud-Dienstperimeters befindet.

• Verschlüsseln Sie das Objekt nicht mit vom Kunden verwalteten Verschlüsselungsschlüsseln oder vom Kunden bereitgestellte Verschlüsselungsschlüssel.

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.

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.

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 hinzufügen

Mit benutzerdefinierten Antwortheadern können Sie Header festlegen, 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 Liste der Header finden Sie unter Variablen, die im Headerwert vorkommen können.

Eine Anleitung finden Sie unter Mit benutzerdefinierten Antwortheadern arbeiten.

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.

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 abrufen, der hochgeladenen Datei, auch wenn die frühere Version noch gültig ist. basierend auf der TTL-Einstellung im Cache gespeichert werden.

Sie können bestimmte Abfrageparameter in den Cache-Schlüssel aufnehmen, 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-Bereinigungsraten. 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.

Sie können Ihren Ursprungsserver optional so konfigurieren, dass der konfigurierte Cache-Schlüssel enthalten ist Anfrageheader in der Vary-Antwort. Sie ist für Cloud CDN nicht erforderlich, kann aber für Downstream-Caches hilfreich sein. Weitere Informationen finden Sie unter Vary-Header (in englischer Sprache).

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.

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 in der Vary-Antwort die Cache-Schlüssel-Header angibt, Cloud CDN behandelt die Antwort genauso wie Header wurden in der Vary-Antwort nicht 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.

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 mithilfe von Bytebereichsanfragen im Cache gespeichert wurde, initiiert eine separate Validierungsanfrage, die If-Modified-Since enthält und If-None-Match-Header.
• 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 für die Antwort 206 Partial Content ein Content-Range-Wert, der die vollständige Länge des Ursprungsobjekts angibt. Zum Beispiel ist Content-length: 0-100/999 im Cache speicherbar, während Content-length: 0-100/* 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. Für 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. Wenn der Ursprungsserver den angeforderten Bytebereich in einer 206 Partial Content-Antwort zurückgibt, kann der Cache diesen Bereich für zukünftige Anfragen speichern.

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, die nicht denselben Cache-Schlüssel haben, können nicht minimiert werden.

Das folgende Diagramm zeigt, wie Anfragen verkettet werden:

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.

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.

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

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

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

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

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

Cache-Umgehung deaktivieren

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

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

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