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 |
Erfolgreiche Antworten werden automatisch mit
statischen Inhalten, die nicht
andernfalls nicht im Cache speicherbar.
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 Backend private, nutzerspezifische 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 Optiongcloud --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
undExpires
), jedoch nicht die anderen Ursprungsantwortheader. Insbesondere wird einVary
-Header weiter berücksichtigt und das Caching kann auch bei Verwendung des ModusFORCE_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
festlegen und eine Antwort angezeigt wird,
hat keine expliziten Caching-Anweisungen in Cache-Control
oder Expires
Header, speichert Cloud CDN automatisch diese Antwort für den
Folgendes:
- 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
entspricht dem MIME-
Typ
der bereitgestellten Inhalte.
Wichtige Hinweise:
Die Webserversoftware Ihres Ursprungs muss den
Content-Type
für jede Antwort festlegen. Viele Webserver legen automatisch den HeaderContent-Type
fest, einschließlich NGINX, Varnish und Apache.Cloud Storage legt den
Content-Type
-Header automatisch auf hochladen, wenn Sie den Google Cloud Console oder die Google Cloud CLI, um Inhalte hochzuladen.Wenn eine Antwort aufgrund ihres MIME-Typs im Cache gespeichert werden kann, aber den
Cache-Control
-Antwortheaderprivate
,no-store
oder einenSet-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 für alle Nutzer 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:
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 |
|
Aktualität | Die Antwort hat einen Bei cachefähigen Antworten ohne Alter (z. B. mit Wenn im Cache-Modus Im Cache-Modus 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-Ursprüngen muss die Antwort ein gültiges
Für Ursprünge, die erweiterte HTTP-Protokollversionen (HTTP/2 und später), muss die Antwort solche Header nicht enthalten. |
Größe | Kleiner oder gleich der maximalen Größe
Antworten mit einer Größe zwischen 10 MB und 100 GB finden Sie in der zusätzliche Einschränkungen bei der Cache-Fähigkeit, die in Bytebereichsanfragen. |
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 Folgendes tun: einen Teil Ihres Buckets öffentlich lesbar machen.
Einzelne Objekte öffentlich lesbar machen. Dieser Ansatz wird nicht empfohlen, da er eine Legacy-, Cloud Storage-spezifisches Berechtigungssystem.
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.
Standardmäßig, wenn ein Objekt öffentlich ist und Cache-Control
nicht angibt
Metadaten weist Cloud Storage ein Cache-Control: public, max-age=3600
-Element zu
zum Objekt hinzu. Sie können verschiedene Werte mit Cache-Control
-Metadaten festlegen.
Beispiel für die Konfiguration eines externen Application Load Balancers mit einem Backend Bucket finden Sie unter Cloud CDN mit einem Back-End einrichten Bucket
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 GB (107.374.182.400 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. 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 einer der Header, die so konfiguriert sind,
der Einstellungen für Cache-Schlüssel.
|
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:
- 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. - Fügen Sie in Antworten, die nicht vertrauenswürdig sind, einen
Cache-Control: private
-Header ein. die in Cloud CDN-Caches gespeichert sind, oder einCache-Control: no-store
in Antworten, die in keinem Cache, auch nicht in einem Web-Header, den Cache des Browsers. - Signieren Sie keine URLs, die Zugriff auf private URLs ermöglichen.
Informationen. 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. - Bei Ursprungsanfragen (Cache-Füllung) mit dem Anfrageheader
Authorization
speichert Cloud CDN nur Antworten im Cache, die die Cache-Anweisungpublic
,must-revalidate
oders-maxage
enthalten, wenn der Cachemodus aufUSE_ORIGIN_HEADERS
oderCACHE_ALL_STATIC
gesetzt wird. Dadurch wird verhindert, im Cache gespeicherter Inhalte und anderer Inhalte, Authentifizierung. Der Cache-ModusFORCE_CACHE_ALL
hat diese Einschränkung nicht.
Benutzerdefinierte Antwortheader hinzufügen
Mit benutzerdefinierten Antwortheadern können Sie Header angeben, klassischen Application Load Balancer zu weitergeleiteten Antworten. 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.
URI-Teil | Anpassung | Beispiel-URLs mit demselben Cache-Schlüssel |
---|---|---|
Protokoll | Das Protokoll im Cache-Schlüssel weglassen. |
|
Host | Den Host im Cache-Schlüssel weglassen. |
|
Abfragestring | Den Abfragestring im Cache-Schlüssel weglassen. Teile des Abfragestrings weglassen oder verwenden. |
|
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 sollte das nicht auffallen, damit beliebte Inhalte im Cache gespeichert.
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. Es ist nicht erforderlich für
Cloud CDN, kann aber für nachgelagerte 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
-TokenCDN-Loop
Connection
Content-MD5
Content-Type
Cookie
Date
Forwarded
, häufig pro Client oder ProxyFrom
Host
, da dies durch die Konfiguration gesteuert wird (cdnPolicy.includeHost
)If-Match
,If-Modified-Since
oderIf-None-Match
Origin
Proxy-Authorization
Range
Referer
(oderReferrer
)User-Agent
Want-Digest
X-CSRFToken
undX-CSRF-Token
, wie sie von Django und Ruby on Rails verwendet werdenX-Forwarded-For
, häufig pro Client oder ProxyX-User-IP
- Jeder Header, der mit folgendem Text beginnt:
Access-Control-
, z. B.Access-Control-Request-Headers
undAccess-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 Cookienamen 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
Dies kann für einzelne Back-Ends mit dem Cache-Modus |
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
Dies kann für einzelne Back-Ends mit dem Cache-Modus |
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
Dies kann für einzelne Back-Ends mit dem Cache-Modus |
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
Wenn sowohl Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt.
|
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 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 |
– |
stale-while-revalidate=SECONDS
|
– |
Eine Antwort mit
Dieses Verhalten kann für alle Antworten durch Festlegen von |
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 Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt. |
proxy-revalidate |
Eine Antwort mit 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, ist Cloud CDN bestrebt, RFC-konform (HTTP RFC 7234), bevorzugt jedoch die Optimierung der Cache-Auslagerung und die Minimierung der Auswirkungen auf die Trefferrate und die Gesamtlast des Ursprungsservers auswirken können.
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 HeaderExpires
.
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 sind
an den Ursprung übergeben werden, und haben keinen Einfluss darauf, wie eine Antwort vom
Cloud CDN
Vary
-Header
Die Vary
-Header zeigt an, dass die Antwort abhängig vom Client
Anfrageheadern. 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,
dynamische Komprimierung,
aktiviert), kann aber Antworten bereitstellen, die vom Ursprungsserver komprimiert wurden. Wenn Ihr
Der Ursprungsserver legt fest, ob komprimierter oder unkomprimierter Inhalt bereitgestellt werden soll
für den Wert des Accept-Encoding
-Anfrageheaders,
Antwort gibt Vary: Accept-Encoding
an.
Wenn Sie HTTP-Header im Cache-Schlüssel verwenden,
Cloud CDN speichert mehrere Kopien der Antwort basierend auf den Werten im Cache
der angegebenen Anfrageheader, ähnlich wie Vary
-Unterstützung, aber ohne den
muss der Ursprungsserver explizit einen Vary
-Antwortheader 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.
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
- oderETag
-Header. - Die Clientanfrage ist eine
GET
-Anfrage, die keineIf-Modified-Since
- oderIf-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 undIf-None-Match
-Header. - Andernfalls fügt Cloud CDN
If-Modified-Since
undIf-None-Match
-Headers an die Clientanfrage und leitet die geänderte Anfrage weiter. zum Back-End.
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
oder206 Partial Content
- Header:
Accept-Ranges: bytes
- Header:
Content-Length
und für die Antwort206 Partial Content
einContent-Range
-Wert, der die vollständige Länge des Ursprungsobjekts angibt. Zum Beispiel istContent-length: 0-100/999
im Cache speicherbar, währendContent-length: 0-100/*
nicht. - Header:
Last-Modified
undETag
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 haben, die größer als
10 MB. Achten Sie darauf, dass Content-Encoding: gzip
nicht vorhanden ist.
Metadaten. Informationen zum Bearbeiten von Objektmetadaten finden Sie unter Objektmetadaten ansehen und bearbeiten.
Beliebte Webserver-Software unterstützt ebenfalls Bytebereichsanfragen. Informationen hierzu finden Sie in der Dokumentation für Ihren Webserver finden Sie Details zur Aktivierung der Unterstützung. 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 Bytebereichsanfragen bekanntermaßen für den
Cache-Schlüssel enthält, 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
oderAccept-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:
<ph type="x-smartling-placeholder">Im Gegensatz dazu können Sie bei deaktivierter Anfrageminimierung oder bei Anfragen, die nicht zusammengeführt werden, kann die Anzahl der Ursprungsanfragen und Antworten gleich dem Anzahl der Clients, die versuchen, ein nicht im Cache gespeichertes Objekt abzurufen.
<ph type="x-smartling-placeholder">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
- Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
- Klicken Sie auf den Namen Ihres externen Application Load Balancers.
- Klicken Sie auf Bearbeiten .
- Wählen Sie unter Back-End-Konfiguration ein Back-End aus und klicken Sie auf Bearbeiten .
- Achten Sie darauf, dass Cloud CDN aktivieren ausgewählt ist.
- Klicken Sie unten im Fenster auf Erweiterte Konfigurationen.
- Klicken Sie unter Cache für Anfrage-Header umgehen auf Header hinzufügen.
- Geben Sie einen Header-Namen ein, z. B.
Pragma
oderAuthorization
. - Klicken Sie auf Aktualisieren.
- 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.