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.

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, 206, 300, 301, 302, 307 oder 410
Cache-Anweisung Hat einen Cache-Control-Header mit einer public-Anweisung
Aktualität Hat einen Cache-Control-Header mit einer max-age- oder s-maxage-Anweisung oder einen Expires-Header mit einem Zeitstempel in der Zukunft
Inhalt

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

Beispielsweise einen Content-Length-Header, der die Größe der Antwort korrekt anpasst

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 den 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 keine Metadaten zur Cache-Steuerung angeben, wird den Objekten standardmäßig von Cloud Storage ein Cache-Control: public, max-age=3600-Header zugewiesen. Mit Cache-Control-Metadaten können Sie verschiedene Werte festlegen.

Ein Beispiel für die Konfiguration 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

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
Anweisung für Antwort Die Antwort hat einen Cache-Control-Header mit den Anweisungen no-store, no-cache oder private
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, wurde die URL-Signierung konfiguriert. Im nächsten Abschnitt erfahren Sie, wie Sie das Caching von Antworten verhindern.

Caching vermeiden

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

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

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 können nicht nur den ganzen Abfragestring einbeziehen oder weglassen, sondern auch Teile des Abfragestrings mithilfe von Include-Listen und Ausschlusslisten 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 von user erstellen, erstellt https://example.com/images/cat.jpg?user=user1&color=blue einen Cache-Schlüssel von https://example.com/images/cat.jpg?user=user1, der auch https://example.com/images/cat.jpg?user=user1&color=red entspricht.

Um diese Option zu verwenden, müssen Sie den Abfragestring einschließen, eine nicht leere Einschlussliste und keine Ausschlussliste angeben.

Abfragestring-Ausschlussliste

Mit einer Ausschlussliste können Sie gezielt steuern, welche Abfragestringparameter Cloud CDN ignoriert. Wenn Sie beispielsweise eine Ausschlussliste von 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.

Um diese Option zu verwenden, müssen Sie den Abfragestring einschließen, eine nicht leere Ausschlussliste und keine Einschlussliste angeben.

Vary-Header

Zusätzlich zum Anfrage-URI berücksichtigt Cloud CDN alle Vary-Header, die Ursprungsserver in Antworten aufnehmen. Der Vary-Header gibt an, dass die Antwort je nach Anfrageheader des Clients variiert. Wenn zum Beispiel eine Antwort Vary: Accept spezifiziert, 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.

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 basierend auf dem Wert des Accept-Encoding-Anfrageheaders komprimierten oder unkomprimierten Inhalt bereitstellen soll, muss in der Antwort Vary: Accept-Encoding angegeben sein.

Antworten mit Vary-Headern werden nur dann im Cache gespeichert, wenn der Header einen der unter im Cache speicherbare Inhalte aufgeführten Werte enthält.

Ablaufzeiten und Validationsanfragen

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

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 die Ablaufzeit jedoch verstrichen ist, kann Cloud CDN eine Antwort erst bereitstellen, nachdem eines Ihrer Back-Ends kontaktiert wurde.

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.

Wenn die zuvor im Cache gespeicherte Antwort Last-Modified- und/oder ETag-Header hat, kann Cloud CDN versuchen, die Informationen in diesen Headern zu verwenden, um den Cache-Eintrag mit dem Back-End zu validieren. Diese Validierung durch Cloud CDN variiert geringfügig, abhängig davon, 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.

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.

Weitere Informationen