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
USE_ORIGIN_HEADERS Erfordert Ursprungsantworten, um gültige Cache-Anweisungen und gültige Caching-Header festzulegen. Antworten ohne diese Anweisungen werden vom Ursprung weitergeleitet.

Dies ist das Standardverhalten für Cloud CDN-fähige Back-Ends, die mit dem gcloud-Befehlszeilentool oder der REST API erstellt wurden.

CACHE_ALL_STATIC Statische Inhalte, die die Anweisung no-store, private oder no-cache nicht enthalten, werden automatisch im Cache gespeichert. Ursprungantworten, die gültige Caching-Anweisungen festlegen, werden ebenfalls im Cache gespeichert.
FORCE_CACHE_ALL Antworten werden bedingungslos gespeichert, wodurch die vom Ursprung festgelegten Cache-Anweisungen überschrieben werden. Speichern Sie private, nutzerspezifische Inhalte (wie dynamische HTML- oder API-Antworten) auf keinen Fall im Cache, wenn ein freigegebenes Back-End mit diesem Modus konfiguriert ist.

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 so festlegen, dass alle statischen Inhalte im Cache gespeichert werden, speichert Cloud CDN Antworten für Folgendes automatisch 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 (image/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 beim Upload fest, wenn Sie die Cloud Console oder das gsutil-Tool 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 no-cache 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 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.

Im Cache speicherbare Inhalte

Cloud CDN speichert nur 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.

Eine Antwort kann nur dann in Cloud CDN-Caches gespeichert werden, wenn alle folgenden Bedingungen erfüllt sind:

Attribut Anforderung
Bereitgestellt von Back-End-Dienst, Back-End-Bucket oder ein benutzerdefinierter Ursprung 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
Cache-Anweisung

Im Cache-Modus USE_ORIGIN_HEADERS muss die Antwort einen Cache-Control-Header mit einer public-Anweisung haben.

Im Cache-Modus CACHE_ALL_STATIC muss die Antwort entweder einen Cache-Control-Header mit einer public-Anweisung oder einen statischen Inhaltstyp haben.

Im Cache-Modus FORCE_CACHE_ALL ist die Antwort immer für das Caching zulässig.

Aktualität

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

Im Cache-Modus CACHE_ALL_STATIC wird jede Back-End-Antwort mit statischem Inhalt als aktuell angesehen bzw. wird die Aktualität bei nicht statischen Inhalten anhand von Ursprungsheadern festgestellt.

Mit dem Cache-Modus FORCE_CACHE_ALL werden alle Back-End-Antworten als aktuell betrachtet.

Inhalt

Enthält einen gültigen Content-Length-, Content-Range- oder Transfer-Encoding: chunked-Header.

Beispielsweise einen Content-Length-Header, der genau der Größe der Antwort entspricht.

Größe Kleiner oder gleich der maximalen Größe

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

  • Machen Sie Ihren Bucket öffentlich lesbar. 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. Weitere Informationen finden Sie unter Empfohlene Bucket-Architektur.

  • Machen Sie die einzelnen Objekte öffentlich lesbar. Dieser Ansatz wird nicht empfohlen.

Wenn der gesamte Bucket öffentlich ist oder die einzelnen Objekte öffentlich sind und die einzelnen Objekte nicht die Metadaten vonCache-Control angeben, weist Cloud Storage dem OBjekt 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 HTTP(S)-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
5 TB (5.497.558.138.880 Byte) 10 MB (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.

Eine Antwort wird nicht im Cache gespeichert, wenn sie die Anforderungen für im Cache speicherbare Inhalte nicht erfüllt oder eine der folgenden Bedingungen zutrifft.

Attribut Anforderung
Bereitgestellt von Back-End-Dienst, Back-End-Bucket oder ein benutzerdefinierter Ursprung, für den Cloud CDN nicht aktiviert ist
Cookie Hat einen Set-Cookie-Header
Vary-Header Hat einen anderen Wert als Accept, Accept-Encoding oder Origin.
Anweisung für Antwort Die Antwort hat einen Cache-Control-Header mit der Anweisung no-store, no-cache 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 Die Anfrage hat einen Cache-Control: no-store-Header
Größe Größer als die Maximalgröße

Möglicherweise werden diese Anforderungen in Zukunft gelockert. Dann kann Cloud CDN zusätzliche Antworten im Cache speichern.

Wenn Cache-Control: no-store, no-cache 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 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.

Benutzerdefinierte Antwortheader hinzufügen

Mit benutzerdefinierten Antwortheadern können Sie Header festlegen, die der externe HTTP(S)-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 Back-End-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.

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.

Bei Back-End-Buckets besteht der Cache-Schlüssel aus dem URI ohne dem Protokoll, Host oder Abfragestring.

Daher werden die folgenden URIs für einen bestimmten Back-End-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

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

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 die Antworten nicht selbst, kann aber Antworten bereitstellen, die vom Ursprungsserver komprimiert wurden. Wenn der Ursprungsserver entscheidet, ob er auf Basis des Werts des Accept-Encoding-Anfrageheaders komprimierten oder unkomprimierten Inhalt bereitstellen soll, muss in der Antwort Vary: Accept-Encoding angegeben sein.

Ablaufzeiten und Validierungsanfragen

Im Cache-Modus USE_ORIGIN_HEADERS hat jeder Cache-Eintrag in einem Cloud CDN-Cache eine von den Headern Cache-Control: s-maxage, Cache-Control: max-age und/oder Expires definierte Ablaufzeit gemäß RFC 7234. 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.

Im Cache-Modus CACHE_ALL_STATIC wird jede Back-End-Antwort mit statischem Inhalt als aktuell angesehen bzw. wird die Aktualität bei nicht statischen Inhalten anhand von Ursprungsheadern festgestellt.

Mit dem Cache-Modus FORCE_CACHE_ALL werden alle Back-End-Antworten als aktuell betrachtet.

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 erfolgt vor der Bereitstellung der Antwort, es sei denn, Sie aktivieren das Betafeature „Bereitstellen, obwohl veraltet“. In diesem Fall wird die nochmalige Überprüfung asynchron ausgeführt.

Cloud CDN validiert im Cache gespeicherte Objekte noch einmal, die älter als 30 Tage sind. Dies ermöglicht die automatische Entwertung und Bereinigung veralteter, nutzergenerierter Cache-Inhalte. Wenn ein max-age- oder s-maxage-Wert 30 Tage (2.592.000 Sekunden) überschreitet, behandelt Cloud CDN den Wert wie 2.592.000 Sekunden. Downstream-Kunden sehen die genauen Werte von max-age und s- maxage auch dann, wenn sie über 30 Tage hinausgehen.

Cloud CDN kann versuchen, die Informationen in den im Cache gespeicherten Antwortheadern zu verwenden, um den Cache-Eintrag mit dem Back-End 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/oder If-None-Match-Headern.
  • Andernfalls fügt Cloud CDN der Clientanfrage die If-Modified-Since- und/oder 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 Back-End weiter.

Die Ablaufzeit stellt eine Obergrenze für die Gültigkeitsdauer eines Cache-Eintrags dar. Es gibt keine Garantie, dass ein Cache-Eintrag im Cache verbleibt, bis er abläuft. Cache-Einträge für selten genutzte Inhalte können gelöscht werden, um Platz für neue Inhalte zu schaffen. Unabhängig von der angegebenen Ablaufzeit werden Cache-Einträge, die 30 Tage lang nicht aufgerufen wurden, automatisch entfernt.

Weitere Informationen finden Sie unter Bereinigung und Ablauf.

TTL-Einstellungen und -Überschreibungen

Sie können das Verhalten von Cloud CDN im Hinblick darauf optimieren, wie lange Cloud CDN wartet, bevor Inhalte neu validiert werden.

Weitere Informationen finden Sie unter TTL-Einstellungen und -Überschreibungen verwenden.

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/oder Content-Range
  • Header: ETag mit einem starken Validator
  • Header: Last-Modified

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. In der Dokumentation zu Ihrer Webserver-Software erfahren Sie, wie Sie die Unterstützung aktivieren können. 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 HTTP(S)-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.

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.

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 das Cloud SDK auf die neueste Version:

    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 HTTP(S)-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 beta compute backend-buckets create oder gcloud beta compute backend-buckets update mit dem Flag --bypass-cache-on-request-headers.

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

gcloud beta compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADERS
gcloud beta compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADERS

Beispiele:

gcloud beta compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma,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/beta/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 beta compute backend-buckets create oder gcloud beta compute backend-buckets update mit dem Flag --no-bypass-cache-on-request-headers.

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

gcloud beta 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/beta/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/beta/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.