Présentation de la mise en cache

Une réponse pouvant être mise en cache est une réponse HTTP que Cloud CDN peut stocker et récupérer rapidement, accélérant ainsi les temps de chargement. Certaines réponses HTTP ne peuvent pas être mises en cache.

Modes cache

Les modes de cache vous permettent de contrôler les facteurs qui déterminent si Cloud CDN met en cache ou non votre contenu.

Cloud CDN propose trois modes de cache, qui définissent la manière dont les réponses sont mises en cache, si Cloud CDN respecte les instructions de cache envoyées par l'origine et comment les valeurs TTL de cache sont appliquées.

Le tableau suivant décrit les modes de cache disponibles :

Mode de cache Comportement
CACHE_ALL_STATIC Met automatiquement en cache les réponses réussies avec du contenu statique qui ne peuvent pas être mises en cache. Les réponses issues de l'origine qui définissent des instructions de mise en cache valides sont également mises en cache.

Il s'agit du comportement par défaut pour les backends pour lesquels Cloud CDN a été activé et qui ont été créés à l'aide de Google Cloud CLI ou de l'API REST.
USE_ORIGIN_HEADERS Exige que les réponses issues de l'origine définissent des instructions de cache et des en-têtes de mise en cache valides. Sans ces instructions, les réponses réussies sont transférées depuis l'origine.
FORCE_CACHE_ALL Met en cache les réponses réussies sans condition, en ignorant les instructions de cache définies par l'origine. Ce mode n'est pas approprié si le backend diffuse du contenu privé et spécifique à l'utilisateur, par exemple des réponses HTML dynamiques ou d'API.

Les réponses d'erreur peuvent être mises en cache même en l'absence d'instructions de cache valides.

Avant de définir le mode de cache sur FORCE_CACHE_ALL, prenez en compte les comportements suivants :

  • Pour les URL ou les cookies signés : FORCE_CACHE_ALL remplace l'âge maximal spécifié dans le Cache entrée maximum age dans la console Google Cloud ou l'option gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL modifie la valeur TTL (Time To Live) du contenu précédemment mis en cache. En appliquant cette modification, certaines entrées auparavant considérées comme nouvelles (à cause de valeurs TTL plus longues provenant d'en-têtes d'origine) peuvent désormais être considérées comme obsolètes.

  • FORCE_CACHE_ALL remplace les instructions de cache (Cache-Control et Expires), mais ne remplace pas les autres en-têtes de réponse d'origine. En particulier, un en-tête Vary est toujours utilisé et peut supprimer la mise en cache, même en présence de FORCE_CACHE_ALL. Pour en savoir plus, consultez la section En-têtes Vary.

Pour obtenir des instructions de configuration, consultez la section Définir le mode cache.

Contenu statique

Le contenu statique est un contenu toujours identique, même lorsqu'il est accessible par différents utilisateurs. Le code CSS que vous utilisez pour définir les styles de votre site, ainsi que le code JavaScript qui assure son interactivité et gère son contenu vidéo et ses images, ne changent généralement pas pour chaque utilisateur, pour une URL donnée (clé de cache) et peuvent donc tirer profit d'une mise en cache sur le réseau périphérique mondial de Cloud CDN.

Lorsque vous définissez le mode de cache sur CACHE_ALL_STATIC et qu'une réponse ne comporte pas d'instructions de mise en cache explicites dans les en-têtes Cache-Control ou Expires, Cloud CDN met automatiquement en cache cette réponse pour les éléments suivants :

  • Éléments Web, y compris CSS (text/css), JavaScript (application/javascript) et l'ensemble des polices Web, y compris WOFF2 (font/woff2)
  • Images, y compris les formats JPEG (image/jpg) et PNG (image/png)
  • Vidéos, y compris H.264, H.265 et MP4 (video/mp4)
  • Fichiers audio, y compris MP3 (audio/mpeg) et MP4 (audio/mp4)
  • Documents formatés, y compris au format PDF (application/pdf)

Le tableau suivant fait office de récapitulatif :

Catégorie Types MIME
Éléments Web text/css text/ecmascript text/javascript application/javascript
Polices Tout Content-Type correspondant à font/*
Images Tout Content-Type correspondant à image/*
Vidéos Tout Content-Type correspondant à video/*
Audio Tout Content-Type correspondant à audio/*
Types de documents formatés application/pdf et application/postscript

Cloud CDN inspecte l'en-tête de réponse HTTP Content-Type, qui reflète le type MIME du contenu diffusé.

Veuillez noter les points suivants :

  • Le logiciel serveur Web d'origine doit définir le paramètre Content-Type pour chaque réponse. De nombreux serveurs Web définissent automatiquement l'en-tête Content-Type, y compris NGINX, Varnish et Apache.

  • Cloud Storage définit l'en-tête Content-Type automatiquement d'importation lorsque vous utilisez le la console Google Cloud ou la Google Cloud CLI pour importer du contenu.

  • Si une réponse peut être mise en cache sur la base de son type MIME, alors que son en-tête de réponse Cache-Control est private ou no-store, ou un en-tête Set-Cookie (consultez la liste complète des règles), elle n'est pas mise en cache.

Cloud CDN ne recourt pas aux extensions de fichier dans le chemin de l'URL pour déterminer si une réponse peut être mise en cache, car de nombreuses réponses pouvant être mises en cache ne sont pas reflétées dans les URL.

Si vous souhaitez mettre en cache les types de contenu text/html et application/json, vous devez définir des en-têtes Cache-Control explicites dans la réponse, afin de prévenir une mise en cache accidentelle des données d'un utilisateur et leur diffusion à l'ensemble des utilisateurs.

Contenu pouvant être mis en cache

Cloud CDN met en cache les réponses qui répondent à toutes les exigences de cette section. Certaines exigences sont spécifiées dans la norme RFC 7234, d'autres sont spécifiques à Cloud CDN.

Cloud CDN peut régulièrement modifier l'ensemble exact des conditions sous lesquelles il met en cache le contenu. Si vous souhaitez empêcher explicitement Cloud CDN de mettre en cache votre contenu, suivez les instructions du document RFC 7234 pour déterminer comment spécifier une réponse qui sera garantie de ne pas pouvoir être mise en cache. Consultez également la section sur le contenu ne pouvant pas être mis en cache en fonction des en-têtes d'origine.

Cloud CDN stocke les réponses dans le cache si toutes les conditions suivantes sont remplies.

Attribut Exigence
Diffusée par Un service de backend, un bucket backend ou un backend externe avec Cloud CDN activé
En réponse à Une requête GET
Code d'état

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 ou 501.
Actualisation

La réponse comporte un en-tête Cache-Control avec une instruction max-age ou s-maxage, ou un en-tête Expires avec un horodatage futur.

Pour les réponses pouvant être mises en cache sans âge (par exemple, avec no-cache), la directive public doit être explicitement fournie.

Avec le mode de cache CACHE_ALL_STATIC, si aucune instruction d'actualisation n'est présente, une réponse réussie avec un type de contenu statique peut toujours être mise en cache.

Avec le mode de cache FORCE_CACHE_ALL, toute réponse réussie est éligible pour la mise en cache. Cela peut entraîner une mise en cache du contenu privé propre à l'utilisateur (informations personnelles de l'utilisateur). Vous ne devez définir FORCE_CACHE_ALL que sur les backends qui ne diffusent pas de contenus privés ou dynamiques, tels que des buckets Cloud Storage.

Si le cache négatif est activé et que le code d'état correspond à un code pour lequel le cache négatif spécifie une valeur TTL, la réponse est éligible à la mise en cache, même sans instruction d'actualisation explicite.
Contenu

Pour les origines HTTP/1, la réponse doit contenir un identifiant Content-Length, Content-Range ou Transfer-Encoding: chunked.

Pour les origines utilisant des versions du protocole HTTP plus avancées (HTTP/2 et par la suite), il n'est pas nécessaire que la réponse contienne ces en-têtes.
Taille Inférieure ou égale à la taille maximale.

Pour les réponses dont la taille est comprise entre 10 Mo et 100 Gio, reportez-vous aux contraintes supplémentaires de mise en cache décrites dans la section Requêtes de plage d'octets.

Pour les buckets backend Cloud Storage, il existe plusieurs façons de satisfaire ces exigences :

Par défaut, lorsqu'un objet est public et ne spécifie pas de métadonnées Cache-Control, Cloud Storage lui attribue un en-tête Cache-Control: public, max-age=3600. Vous pouvez définir différentes valeurs à l'aide des métadonnées Cache-Control.

Pour voir un exemple montrant comment configurer un équilibreur de charge d'application externe avec un backend, consultez la section Configurer Cloud CDN avec un backend bucket.

Taille maximale

Cloud CDN applique une taille maximale pour chaque réponse. Toute réponse dont le corps est supérieur à la taille maximale n'est pas mise en cache, mais elle est tout de même transmise au client.

La taille maximale varie selon que le serveur d'origine accepte les requêtes de plage d'octets ou non.

Le serveur d'origine accepte les requêtes de plage d'octets Le serveur d'origine n'accepte pas les requêtes de plage d'octets
100 Gio (107 374 182 400 octets) 10 Mio (10 485 760 octets)

Presque tous les serveurs Web modernes (tels que NGINX, Apache et Varnish) acceptent les requêtes de plage d'octets.

Contenu ne pouvant pas être mis en cache d'après les en-têtes d'origine

Certaines vérifications bloquent la mise en cache des réponses. Cloud CDN peut régulièrement modifier l'ensemble exact des conditions sous lesquelles il met le contenu en cache. Par conséquent, si vous souhaitez empêcher explicitement Cloud CDN de mettre en cache votre contenu, suivez les consignes de la norme (RFC 7234) pour déterminer comment spécifier une réponse qui sera garantie de ne pas pouvoir être mise en cache.

Cloud CDN ne met pas en cache une réponse si elle ne répond pas aux exigences liées au contenu pouvant être mis en cache ou si l'une des conditions suivantes est remplie..

Attribut Exigence
Diffusée par Un service de backend ou un backend externe où Cloud CDN n'est pas activé
Cookie Comporte un en-tête Set-Cookie
En-tête Vary a une valeur autre que 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, ou l'un des en-têtes configurés pour être des paramètres de la clé de cache.
Instruction de réponse La réponse comporte un en-tête Cache-Control avec une instruction no-store ou private (à moins que vous utilisiez le mode de cache FORCE_CACHE_ALL, auquel cas l'en-tête Cache-Control est ignoré).
Instruction de requête La requête contient une instruction Cache-Control: no-store.
Autorisation de requête La requête comporte un en-tête Authorization, sauf si elle est ignorée par le contrôle du cache de la réponse.
Taille Supérieure à la taille maximale

Si Cache-Control: no-store ou private sont présents alors que le contenu est toujours mis en cache, cela est dû à l'une des raisons suivantes :

  • La signature d'URL est configurée.
  • Le mode cache Cloud CDN est configuré pour forcer la mise en cache de toutes les réponses.

Empêcher la mise en cache

Pour empêcher la mise en cache d'informations privées dans les caches Cloud CDN, procédez comme suit :

  1. Assurez-vous que le mode cache Cloud CDN n'est pas défini sur le mode FORCE_CACHE_ALL, qui met en cache l'ensemble des réponses réussies de manière inconditionnelle.
  2. Incluez un en-tête Cache-Control: private dans les réponses qui ne doivent pas être stockées dans des caches Cloud CDN, ou un en-tête Cache-Control: no-store dans les réponses qui ne doivent pas être stockées dans un cache, même le cache d'un navigateur Web.
  3. Ne signez pas d'URL qui donnent accès à des des informations. Lorsque du contenu est consulté à l'aide d'une URL signée, il est potentiellement éligible pour la mise en cache, quelles que soient les instructions Cache-Control de la réponse.
  4. Pour les requêtes d'origine (remplissage de cache) incluant l'en-tête de requête Authorization, Cloud CDN ne met en cache que les réponses qui incluent l'instruction de contrôle du cache public, must-revalidate ou s-maxage lorsque le mode de cache est défini sur USE_ORIGIN_HEADERS ou CACHE_ALL_STATIC. Cela permet d'éviter met accidentellement en cache du contenu utilisateur l'authentification unique. Le mode de cache FORCE_CACHE_ALL ne présente pas cette restriction.

Ajouter des en-têtes de réponse personnalisés

Avec les en-têtes de réponse personnalisés, vous pouvez spécifier les en-têtes que le l'équilibreur de charge d'application classique s'ajoute aux réponses transmises par proxy. Les en-têtes de réponse personnalisés vous permettent de refléter l'état du cache à vos clients, les données géographiques des clients et vos propres en-têtes de réponse statiques.

Pour obtenir la liste des en-têtes, consultez la section Variables pouvant apparaître dans la valeur d'en-tête.

Pour obtenir des instructions, consultez la section Utiliser des en-têtes de réponse personnalisés.

Clés de cache

Dans un cache Cloud CDN, chaque entrée de cache est identifiée par une clé de cache. Lorsqu'une requête arrive dans le cache, celui-ci convertit l'URI de la requête en clé de cache, puis le compare aux clés des entrées mises en cache. S'il trouve une correspondance, il renvoie l'objet associé à la clé.

Pour les services de backend, Cloud CDN utilise par défaut l'URI complet de la requête comme clé de cache. Par exemple, https://example.com/images/cat.jpg est l'URI complet d'une requête sur l'objet cat.jpg. Cette chaîne est utilisée comme clé de cache par défaut. Seules les requêtes comportant exactement cette chaîne concordent. Les requêtes sur http://example.com/images/cat.jpg ou https://example.com/images/cat.jpg?user=user1 ne correspondent pas.

Pour les buckets backend, la clé de cache comprend par défaut l'URI sans le protocole ou l'hôte. Par défaut, seuls les paramètres de requête connus de Cloud Storage sont inclus dans la clé de cache (par exemple, "génération").

Ainsi, pour un bucket backend donné, les URI suivants sont associés au même objet mis en cache :

  • 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

Vous pouvez modifier les parties de l'URI utilisées dans la clé de cache. Bien que le nom de fichier et le chemin doivent toujours faire partie de la clé, vous pouvez inclure ou omettre toute combinaison du protocole, de l'hôte ou de la chaîne de requête lors de la personnalisation de la clé de cache. La section Utiliser des clés de cache explique comment personnaliser les clés de cache.

Partie de l'URI Personnalisation Exemples d'URL ayant la même clé de cache
Protocole Omettez le protocole de la clé de cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Hôte Omettez l'hôte de la clé de cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
Chaîne de requête

Omettez la chaîne de requête de la clé de cache.

Omettez ou incluez de manière sélective des parties de la chaîne de requête.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Outre l'inclusion ou l'omission de la chaîne de requête entière, vous pouvez utiliser des parties de la chaîne à l'aide de listes d'inclusion et de listes d'exclusion.

Liste d'inclusion de chaîne de requête

Vous pouvez contrôler de manière sélective les paramètres de chaîne de requête que Cloud CDN intègre dans les clés de cache. Par exemple, si vous créez une liste d'inclusion de user, https://example.com/images/cat.jpg?user=user1&color=blue crée une clé de cache de https://example.com/images/cat.jpg?user=user1 qui correspond également à https://example.com/images/cat.jpg?user=user1&color=red.

Pour utiliser cette option, vous devez inclure la chaîne de requête et spécifier une liste d'inclusion non vide, sans spécifier de liste d'exclusion.

Liste d'inclusion de chaîne de requête pour les clés de cache Cloud Storage

L'inclusion de paramètres de requête d'URL dans les clés de cache pour les buckets Cloud Storage permet en charge le cache busting. Le cache busting permet à un utilisateur de récupérer une nouvelle version du fichier importé, même si l'ancienne version est toujours valide mis en cache en fonction du paramètre TTL.

Vous pouvez inclure des paramètres de requête spécifiques dans la clé de cache utilisée pour diffuser les réponses à partir d'un bucket backend. Bien que Cloud Storage ne diffuse pas de contenu ou de route différents en fonction des paramètres de requête, vous pouvez choisir d'inclure des paramètres qui vous permettent de mettre en cache le contenu statique stocké dans les buckets Cloud Storage.

Par exemple, vous pouvez ajouter un paramètre de requête ?version=VERSION ou ?hash=HASH basé sur le contenu sous-jacent. Cela limite de manière proactive la nécessité d'invalider le contenu et assure la cohérence avec les workflows de développement Web modernes. En effet, ceux-ci, comme les URL, utilisent un hachage du contenu pour éviter de diffuser des objets obsolètes entre les déploiements.

Étant donné que l'inclusion des paramètres de requête dans la clé de cache est activée uniquement sur option, Cloud CDN ne permet pas d'exclure les paramètres de requête d'une clé de cache vers un bucket backend.

Liste d'exclusion de chaîne de requête

Vous pouvez contrôler de manière sélective les paramètres de chaîne de requête que Cloud CDN ignore à l'aide d'une liste d'exclusion. Par exemple, si vous créez une liste d'exclusion de user, tous les paramètres de chaîne de requête, excepté user, sont utilisés dans la clé de cache.

Avec la liste d'exclusion configurée et l'entrée https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN crée une clé de cache https://example.com/images/cat.jpg?color=blue correspondant également à https://example.com/images/cat.jpg?user=user2&color=blue, mais pas à https://example.com/images/cat.jpg?user=user1&color=red.

Pour utiliser cette option, vous devez inclure la chaîne de requête et spécifier une liste d'exclusion non vide, sans spécifier de liste d'inclusion.

Ordre des paramètres de requête

La clé de cache générée ne dépend pas de l'ordre des paramètres de requête.

Par exemple, les paramètres de requête suivants génèrent la même clé de cache :

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

Paramètres des clés de cache pour les en-têtes HTTP et les cookies HTTP

Vous pouvez améliorer les taux de succès de cache (hits) et le déchargement de l'origine avec les paramètres de configuration de clé de cache suivants.

  • Pour les services et buckets backend : utilisez les en-têtes HTTP dans les clés de cache en incluant des en-têtes nommés dans la configuration des clés de cache.
  • Pour les services de backend uniquement : utilisez des cookies HTTP nommés comme clés de cache, comme pour les tests A/B (multivariés), la version Canary et d'autres scénarios similaires.

Les requêtes de cache qui incluent des en-têtes HTTP ou des cookies HTTP supplémentaires dans la requête sont mises en cache lors de la troisième requête, dans un emplacement de cache pour cette clé de cache. Cela réduit l'impact des valeurs d'en-tête ou de cookie à cardinalité élevée sur vos taux d'éviction du cache. Dans des circonstances et des conditions de circulation des utilisateurs normales, cela ne devrait pas être perceptible et garantit que le contenu populaire reste en cache.

Inclure des en-têtes de requêtes

Pour mettre en cache des variantes supplémentaires d'une réponse, vous pouvez inclure des en-têtes de requête supplémentaires dans la clé de cache.

Certains en-têtes ne sont pas autorisés dans les clés de cache, car ils présentent généralement une cardinalité très élevée. Dans la plupart des cas, les valeurs de ces en-têtes sont uniques par utilisateur (Cookie ,Authorization) ou comportent des milliers de valeurs probables (Referer, User-Agent, Accept). Par exemple, l'en-tête User-Agent peut contenir plus de 5 000 valeurs uniques compte tenu de la grande variété des navigateurs, des appareils utilisateur et des systèmes d'exploitation. Ces types d'en-têtes pourraient avoir un impact important sur les taux d'accès au cache.

Seuls les noms de champs d'en-tête HTTP valides sont acceptés conformément à la RFC 7230. Les noms de champs d'en-tête ne sont pas sensibles à la casse, et les doublons sont rejetés.

Vous pouvez éventuellement configurer votre serveur d'origine pour qu'il inclue les en-têtes de requête de clé de cache configurés dans la réponse Vary. Il n'est pas obligatoire pour Cloud CDN, mais peut être utile pour les caches en aval. Pour en savoir plus, consultez la section En-têtes Vary.

Cloud CDN ne permet pas d'inclure les en-têtes suivants dans la liste des en-têtes :

  • Accept
  • Accept-Encoding
  • Authority, car cet état est contrôlé par la configuration (cdnPolicy.includeHost)
  • Authorization, généralement par utilisateur, comme dans les jetons OAuth Bearer
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, souvent par client ou par proxy
  • From
  • Host, car cet état est contrôlé par la configuration (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since, ou If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (ou Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken et X-CSRF-Token, tels qu'ils sont utilisés par Django et Ruby on Rails
  • X-Forwarded-For, souvent par client ou par proxy
  • X-User-IP
  • Tout en-tête commençant par ce qui suit :
    • Access-Control-, tels que Access-Control-Request-Headers et Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

En-têtes identiques avec des valeurs différentes

Supposons que l'utilisateur envoie plusieurs en-têtes portant le même nom avec des valeurs d'en-tête différentes, par exemple :

My-Header: Value1
My-Header: Value2

Dans ce cas, Cloud CDN modifie la requête en supposant que l'en-tête doit respecter la convention standard qui autorise certains en-têtes à avoir plusieurs valeurs. Cloud CDN les réduit dans une liste d'éléments séparés par une virgule à envoyer au backend, comme si le client avait envoyé les éléments suivants :

My-Header: Value1, Value2

Inclure des cookies nommés

Un cookie HTTP est une association name=value. Une requête peut inclure plusieurs cookies HTTP, séparés par un point-virgule sur la même ligne, ou sous forme d'en-têtes de requête Cookie discrets contenant un cookie par en-tête.

Vous pouvez fournir une liste de cinq noms de cookies au maximum.

Les user-agents (tels que les navigateurs Web) limitent souvent le nombre de cookies stockés par domaine à 4 Ko. Veillez à ne pas envoyer trop de cookies (ou trop volumineux) car l'user-agent peut ne pas envoyer tous les cookies dans une requête. Cela peut avoir un impact sur la capacité d'un utilisateur à recevoir une réponse spécifique mise en cache.

Si vous diffusez votre contenu statique à partir d'un nom d'hôte différent depuis lequel vous émettez des cookies, assurez-vous que l'attribut Domain du cookie et le Path permettent d'envoyer le cookie avec les requêtes de contenu statique.

Si une requête inclut plusieurs instances du même nom de cookie, seule la première est honorée.

Instructions pour le contrôle du cache

Les instructions pour le contrôle du cache HTTP affectent le comportement de Cloud CDN, comme décrit dans le tableau suivant.

N/A signifie qu'une instruction n'est pas applicable à une requête ou à une réponse.

Instruction Requête Réponse
no-store Lorsqu'elle est présente dans une requête, Cloud CDN la respecte et ne stocke pas la réponse dans le cache.

Une réponse avec no-store n'est pas mise en cache.

Cette instruction peut être ignorée en fonction du backend à l'aide du mode de cache FORCE_CACHE_ALL.

no-cache L'instruction de requête no-cache est ignorée pour empêcher les clients de lancer ou de forcer la revalidation dans l'origine.

Une réponse avec no-cache est mise en cache, mais doit être revalidée avec l'origine avant d'être diffusée.

Cette instruction peut être ignorée en fonction du backend à l'aide du mode de cache FORCE_CACHE_ALL.

public Non disponible

Cette directive n'est pas obligatoire pour la mise en cache, mais il est recommandé de l'inclure pour le contenu qui doit être mis en cache par les proxys.

private Non disponible

Une réponse avec l'instruction private n'est pas mise en cache par Cloud CDN, même si elle est considérée comme pouvant être mise en cache. Il est toujours possible que les clients (tels que les navigateurs) mette en cache le résultat.

Cette instruction peut être ignorée en fonction du backend à l'aide du mode de cache FORCE_CACHE_ALL. Utilisez no-store pour empêcher toute mise en cache des réponses.

max-age=SECONDS L'instruction de requête max-age est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. Une réponse avec l'instruction max-age est mise en cache jusqu'à la valeur SECONDS définie.
s-maxage=SECONDS ND

Une réponse avec l'instruction s-maxage est mise en cache jusqu'à la valeur SECONDS définie.

Si max-age et s-maxage sont présents, s‑maxage est utilisé par Cloud CDN.

Les réponses comportant cette instruction ne sont pas diffusées lorsqu'elles sont obsolètes.

La valeur s-max-age (deux traits d'union) n'est pas valide pour la mise en cache.

min-fresh=SECONDS L'instruction de requête min-fresh est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. ND
max-stale=SECONDS

L'instruction de requête max-stale définit l'obsolescence maximale (en secondes) que le client est prêt à accepter.

Cloud CDN respecte ce principe et ne renvoie une réponse mise en cache obsolète que si l'obsolescence de la réponse est inférieure à l'instruction max-stale. Sinon, il revalide avant de diffuser la requête.

 ND
stale-while-revalidate=SECONDS ND

Une réponse avec stale-while-revalidate est diffusée à un client pendant une durée maximale de SECONDS, tandis que la revalidation a lieu de manière asynchrone.

Ce comportement peut être activé pour toutes les réponses en définissant cdnPolicy.serveWhileStale sur le backend.

stale-if-error=SECONDS L'instruction de requête stale-if-error est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête.

Cet en-tête de réponse n'a aucun effet.

must-revalidate Non disponible

Une réponse avec must-revalidate est revalidée avec le serveur d'origine après son expiration.

Les réponses comportant cette instruction ne sont pas diffusées lorsqu'elles sont obsolètes.

proxy-revalidate

Une réponse avec proxy-revalidate est revalidée avec le serveur d'origine après son expiration.

Les réponses comportant cette instruction ne sont pas diffusées lorsqu'elles sont obsolètes.

immutable ND Aucun effet. Cette instruction est transmise au client dans la réponse.
no-transform ND Aucune transformation n'est appliquée par Cloud CDN.
only-if-cached L'instruction de requête only-if-cached est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête. N/A

Dans la mesure du possible, Cloud CDN s'efforce d'être conforme à la norme RFC (HTTP RFC 7234), mais favorise l'optimisation pour le déchargement du cache et la réduction de l'impact sur le taux d'appels et le chargement global de l'origine.

Pour les réponses qui utilisent l'en-tête HTTP/1.1 Expires, les éléments suivants s'appliquent :

  • La valeur de l'en-tête Expires doit être une date HTTP valide telle que définie dans le document RFC 7231.
  • Une date passée, une date non valide ou une valeur 0 indique que le contenu a déjà expiré et qu'il nécessite une nouvelle validation.
  • Si un en-tête Cache-Control est présent dans la réponse, Cloud CDN ignore l'en-tête Expires.

La présence d'un en-tête Expires futur valide dans la réponse permet la mise en cache de la réponse et ne nécessite pas d'autres instructions de cache.

L'en-tête HTTP/1.0 Pragma, s'il est présent dans une réponse, est ignoré et transmis au client en l'état. Les requêtes client comportant cet en-tête sont transmises à l'origine et n'ont pas d'incidence sur la manière dont une réponse est diffusée par Cloud CDN.

En-têtes Vary

L'en-tête Vary indique que la réponse varie en fonction des en-têtes de requête du client. Outre l'URI de la requête, Cloud CDN respecte les en-têtes Vary inclus dans les réponses par les serveurs d'origine. Par exemple, si une réponse spécifie Vary: Accept, Cloud CDN utilise une entrée de cache pour les requêtes spécifiant Accept: image/webp,image/*,*/*;q=0.8 et une autre pour les requêtes spécifiant Accept: */*.

Le tableau de la section Contenu ne pouvant pas être mis en cache répertorie les en-têtes Vary qui autorisent la mise en cache du contenu. D'autres valeurs d'en-tête Vary empêchent la mise en cache du contenu.

Le mode cache FORCE_CACHE_ALL ne remplace pas ce comportement. Les en-têtes Vary sont importants pour éviter la contamination du cache entre plusieurs réponses possibles du serveur d'origine. Le mode FORCE_CACHE_ALL de mise en cache des réponses pourrait présenter un danger.

Les en-têtes Vary sont parfois utilisés lors de la diffusion de contenu compressé. Cloud CDN n'effectue pas lui-même la compression et la décompression des réponses (sauf si la compression dynamique mais il peut diffuser des réponses compressées par le serveur d'origine. Si le serveur d'origine diffuse du contenu compressé ou non compressé en fonction de la valeur de l'en-tête de requête Accept-Encoding, assurez-vous que la réponse spécifie Vary: Accept-Encoding.

Lorsque vous utilisez des en-têtes HTTP dans la clé de cache, Cloud CDN met en cache plusieurs copies de la réponse en fonction des valeurs des en-têtes de requête spécifiés. Cette méthode est semblable à la prise en charge Vary, mais sans le le serveur d'origine doit spécifier explicitement un en-tête de réponse Vary. Si l'origine spécifie les en-têtes de clé de cache dans la réponse Vary, Cloud CDN traite la réponse correctement, comme si la les en-têtes n'ont pas été mentionnés dans la réponse Vary.

Délais d'expiration et requêtes de validation

Le délai d'expiration d'une entrée de cache définit la durée pendant laquelle une entrée de cache reste valide. La valeur fournie par la valeur s-maxage (ou max-age ou expires) permet la revalidation automatique du contenu mis en cache généré par l'utilisateur lorsqu'il est obsolète.

Lorsque Cloud CDN reçoit une requête, il recherche l'entrée de cache correspondante et vérifie son ancienneté. S'il s'agit d'une entrée de cache existante et suffisamment récente, la réponse peut être diffusée à partir du cache. Si le délai d'expiration est passé, Cloud CDN tente de revalider l'entrée du cache en contactant l'un de vos backends. Cette opération est exécutée avant de diffuser la réponse, sauf si vous activez l'option serve-while-stale (diffusion si obsolète), auquel cas la revalidation est effectuée de manière asynchrone.

Pour certains modes de cache, vous pouvez définir des valeurs TTL. Pour en savoir plus, consultez la page Utiliser les remplacements et les paramètres TTL.

Le mode de cache affecte la façon dont l'actualisation est déterminée.

Mode cache Comportement de validation
CACHE_ALL_STATIC Les en-têtes d'origine (Cache-Control: s-maxage, Cache-Control: max-age ou Expires) sont consultés pour déterminer l'actualisation. Pour le contenu statique, en l'absence d'en-têtes d'origine, la valeur default_ttl configurée détermine la fraîcheur. Une fois que le contenu statique est antérieur à default_ttl, Cloud CDN le revalide.
USE_ORIGIN_HEADERS Dans un cache Cloud CDN, chaque entrée de cache est associée à un délai d'expiration défini par les en-têtes Cache-Control: s-maxage, Cache-Control: max-age et/ou Expires, conformément à la norme RFC 7234.
FORCE_CACHE_ALL Au lieu d'en-têtes d'origine, la valeur default_ttl configurée détermine l'actualisation. Une fois que le contenu est antérieur à default_ttl, Cloud CDN le revalide.

S'il existe plusieurs en-têtes, Cache-Control: s-maxage est prioritaire sur Cache-Control: max-age, et Cache-Control: max-age est prioritaire sur Expires.

Par défaut, lorsque la valeur d'expiration dépasse 30 jours (2 592 000 secondes), Cloud CDN la traite comme s'il s'agissait de 2 592 000 secondes. Les clients en aval continuent de voir les valeurs exactes de max-age et s-maxage, même si elles dépassent 30 jours.

Éviction

Rien ne garantit qu'une entrée de cache reste dans le cache jusqu'à son expiration, car les entrées peu consultées peuvent être supprimées avant leur expiration à tout moment pour faire de la place au nouveau contenu. En tant que limite supérieure, les entrées de cache qui ne font l'objet d'aucun accès pendant 30 jours sont automatiquement évincées.

Pour en savoir plus, consultez la section Éviction et expiration.

Utiliser des requêtes conditionnelles pour la validation

Cloud CDN peut tenter d'utiliser les informations des en-têtes de réponse mis en cache pour valider l'entrée de cache auprès du backend. Ce scénario se produit lorsque les deux conditions suivantes sont remplies :

  • La réponse précédemment mise en cache comporte un en-tête Last-Modified ou ETag.
  • La requête du client est une requête GET qui ne comporte pas d'en-têtes If-Modified-Since ou If-None-Match.

Cloud CDN effectue cette validation légèrement différemment selon que la réponse a été mise en cache à l'aide de requêtes de plage d'octets ou non :

  • Si la réponse a été mise en cache à l'aide de requêtes de plage d'octets, Cloud CDN lance une demande de validation distincte qui inclut If-Modified-Since et If-None-Match.
  • Sinon, Cloud CDN ajoute If-Modified-Since et If-None-Match à la requête du client et transfère la requête modifiée vers le backend.

Si la copie en cache est à jour, le backend peut valider l'entrée de cache existante en envoyant une réponse 304 Not Modified. Dans ce cas, le backend envoie uniquement les en-têtes de réponse, pas le corps de réponse. Cloud CDN introduit les nouveaux en-têtes de réponse dans le cache, met à jour le délai d'expiration, puis diffuse au client les nouveaux en-têtes de réponse et le corps de réponse mis en cache.

Si la réponse précédemment mise en cache ne comporte pas l'en-tête Last-Modified ou ETag, Cloud CDN ignore l'entrée de cache arrivée à expiration et transfère la requête du client non modifiée au backend.

Compatibilité pour les requêtes de plage d'octets

Une réponse répondant aux critères suivants indique que le serveur d'origine accepte les requêtes de plage d'octets :

  • Code d'état : 200 OK ou 206 Partial Content
  • En-tête : Accept-Ranges: bytes
  • En-tête : Content-Length et, pour une réponse 206 Partial Content, une valeur Content-Range qui indique la longueur complète de l'objet d'origine. Par exemple, Content-length: 0-100/999 peut être mis en cache, tandis que Content-length: 0-100/* ne l'est pas.
  • En-tête: Last-Modified et ETag avec un programme de validation performant.

Cloud Storage accepte les requêtes de plage d'octets pour la plupart des objets. Cependant, Cloud Storage n'accepte pas les requêtes de plage d'octets pour les objets associés à des métadonnées Content-Encoding: gzip, sauf si la requête du client inclut un en-tête Accept- Encoding: gzip. Si vous disposez d'objets Cloud Storage dont la taille est supérieure à 10 Mo, assurez-vous qu'ils ne comportent pas de métadonnées Content-Encoding: gzip. Pour découvrir comment modifier des métadonnées d'objet, consultez la page Afficher et modifier des métadonnées d'objets.

Les logiciels serveur Web populaires acceptent également les requêtes de plage d'octets. Consultez le documentation de votre serveur Web pour savoir comment activer l'assistance. Pour plus d'informations sur les requêtes de plage d'octets, consultez la Spécification HTTP :

Lorsqu'un serveur d'origine accepte les requêtes de plage d'octets, un cache Cloud CDN refuse de stocker une réponse pouvant être mise en cache la première fois que la mise en cache est demandée si l'une des conditions suivantes est remplie :

  • Le corps de la réponse est incomplet car le client n'a demandé qu'une partie du contenu.
  • Le corps de la réponse a une taille supérieure à 1 Mo (1 048 576 octets).

Lorsque cela se produit et que la réponse peut satisfaire aux exigences de mise en cache standards, le cache enregistre que le serveur d'origine accepte les requêtes de plage d'octets pour cette clé de cache et transfère au client la réponse du serveur d'origine.

En cas de défaut de cache, l'acceptation des requêtes de plage d'octets par le serveur d'origine est vérifiée. Si l'on sait que les requêtes de plage d'octets sont acceptées pour la clé de cache, le cache ne transfère pas la requête du client à l'équilibreur de charge d'application externe. Il lance plutôt ses propres requêtes de remplissage du cache de plage d'octets pour les parties manquantes du contenu. Si le serveur d'origine renvoie la plage d'octets demandée dans une réponse 206 Partial Content, le cache peut stocker cette plage pour les futures requêtes.

La réponse 206 Partial Content n'est stockée que lorsqu'elle est reçue en réponse à une requête de plage d'octets lancée par le cache. Un cache ne lance pas de requête de plage d'octets sans avoir préalablement enregistré que le serveur d'origine accepte les requêtes de plage d'octets pour la clé de cache. Par conséquent, un contenu dont la taille dépasse 1 Mo ne peut être stocké qu'après avoir fait l'objet d'un deuxième accès.

En raison de sa nature distribuée, Cloud CDN peut parfois récupérer le fragment final de l'origine plusieurs fois par emplacement. Cela ne concerne que les premières requêtes par clé de cache.

Demande de réduction (coalescence)

La demande de réduction (ou coalescence) consiste à réduire activement plusieurs requêtes de remplissage de cache pilotés par l'utilisateur pour la même clé de cache en une seule requête d'origine par nœud périphérique. Cela peut réduire activement la charge sur l'origine, et s'applique aux requêtes d'éléments (réponses récupérées directement) et aux requêtes fragmentées, dans lesquelles Cloud CDN utilise des requêtes Range pour récupérer les objets plus volumineux de manière plus efficace.

La demande de réduction est activée par défaut.

Les requêtes réduites se comportent de la manière suivante :

  • Les requêtes réduites consignent à la fois la requête côté client et la requête de remplissage de cache (réduite).
  • Le leader de la session réduite permet d'effectuer la requête de remplissage d'origine.
  • Les attributs de requête qui ne font pas partie de la clé de cache, tels que l'en-tête User-Agent ou Accept-Encoding, ne représentent que le leader de la session réduite.
  • Les requêtes ne partageant pas la même clé de cache ne peuvent pas faire l'objet d'une réduction.

Le schéma suivant montre comment les requêtes sont gérées :

Cloud CDN avec réduction des requêtes activée.
Cloud CDN avec réduction de requêtes activée (cliquez pour agrandir)

En revanche, lorsque le réduction des requêtes est désactivée ou que les requêtes ne peuvent pas le nombre de requêtes et de réponses d'origine peut être égal au Nombre de clients qui tentent de récupérer un objet non mis en cache

Cloud CDN sans réduction de requêtes activée
Cloud CDN sans réduction de requêtes activée (cliquez pour agrandir)

Pour tous les types de requêtes, la réduction est activée par défaut. Pour les types de requêtes d'éléments, vous pouvez désactiver la réduction. Nous vous recommandons de désactiver la réduction pour les requêtes d'éléments dans des cas sensibles à latence élevée, tels que la diffusion d'annonces, pour lesquels la charge d'origine n'est pas prise en compte.

Le tableau suivant récapitule le comportement et la configuration par défaut pour différents types de requêtes.

Type de demande Comportement par défaut Configurable Avantages de la réduction
Requêtes fragmentées Activé Non Peut réduire considérablement la bande passante d'origine.
Requêtes d'éléments Activé Oui Peut réduire le volume des requêtes d'origine.

Pour désactiver la réduction des requêtes d'éléments à l'aide de Google Cloud CLI sur un bucket de backend qui fait référence à un bucket Cloud Storage, procédez comme suit :

gcloud

Utilisez la commande gcloud compute backend-services ou backend-buckets :

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

Pour activer la réduction des requêtes d'éléments sur un bucket de backend à l'aide de Google Cloud CLI, procédez comme suit :

gcloud

Exécutez la commande gcloud compute backend-buckets :

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

Pour activer la réduction de requêtes d'éléments à l'aide de Google Cloud CLI pour un service de backend, y compris les groupes de VM et les backends externes, procédez comme suit :

gcloud

Exécutez la commande gcloud compute backend-services :

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

Requêtes initiées par Cloud CDN

Lorsque le serveur d'origine accepte les requêtes de plage d'octets, Cloud CDN peut lui envoyer plusieurs requêtes en réponse à une requête client unique. Comme décrit ci-dessous, Cloud CDN peut initier deux types de requêtes : les requêtes de validation et les requêtes de plage d'octets.

Si la réponse indiquant que le serveur d'origine accepte les requêtes de plage d'octets pour une clé de cache particulière a expiré, Cloud CDN lance une requête de validation pour confirmer que le contenu n'a pas changé et que le serveur d'origine accepte toujours les requêtes de plage pour le contenu. Si le serveur d'origine envoie une réponse 304 Not Modified en retour, Cloud CDN diffuse le contenu avec des plages d'octets. Sinon, CDN Cloud transfère la réponse du serveur d'origine au client. Vous contrôlez les délais d'expiration à l'aide des en-têtes de réponse Cache-Control et Expires.

En cas de défaut de cache, Cloud CDN lance des requêtes de remplissage de cache pour un ensemble de plages d'octets chevauchant la requête du client. Si certaines plages du contenu demandé par le client sont présentes dans le cache, Cloud CDN diffuse le contenu possible à partir du cache et n'envoie de requête au serveur d'origine que pour les plages manquantes.

Chaque requête de plage d'octets lancée par Cloud CDN spécifie une plage qui commence par un décalage correspondant à un multiple de 2 097 136 octets. À l'exception possible de la plage finale, chaque plage a également une taille de 2 097 136 octets. Si le contenu n'est pas un multiple de cette taille, la plage finale sera plus petite. La taille et les décalages utilisés dans les requêtes de plage d'octets peuvent changer à l'avenir.

À titre d'exemple, considérons une requête client pour les octets 1 000 000 à 3 999 999 d'un contenu absent du cache. Dans cet exemple, Cloud CDN peut lancer deux requêtes GET, une pour les 2 097 136 premiers octets du contenu et une autre pour les 2 097 136 octets suivants. Cela se traduit par 4 194 272 octets de remplissage du cache, même si le client n'a demandé que 3 000 000 octets.

Lorsque vous utilisez un bucket Cloud Storage comme origine, chaque requête GET est facturée en tant qu'opération de classe B distincte. Des frais vous sont facturés pour toutes les requêtes GET traitées par Cloud Storage, y compris les requêtes initiées par Cloud CDN. Lorsqu'une réponse est entièrement traitée à partir d'un cache Cloud CDN, aucune requête GET n'est envoyée à Cloud Storage et aucune opération Cloud Storage n'est facturée.

Lorsque Cloud CDN initie une requête de validation ou une requête de plage d'octets, il n'inclut pas les en-têtes spécifiques au client tels que Cookie ou User-Agent.

Dans le champ httpRequest.userAgent de Cloud Logging, Cloud-CDN-Google signifie que Cloud CDN a lancé la requête.

Contourner le cache

Le contournement du cache permet aux requêtes contenant des en-têtes de requête spécifiques de contourner le cache, même si le contenu a déjà été mis en cache.

Cette section fournit des informations sur le contournement du cache avec des en-têtes HTTP, tels que Pragma et Authorization. Cette fonctionnalité est utile lorsque vous souhaitez vous assurer que vos utilisateurs ou vos clients disposent toujours du contenu le plus récent et à jour récupéré depuis le serveur d'origine. Cela peut s'avérer utile pour tester, configurer des répertoires de préproduction ou des scripts.

Si un en-tête spécifié correspond, le cache est ignoré pour tous les paramètres du mode de cache, même FORCE_CACHE_ALL. Le contournement du cache entraîne un grand nombre de défauts de cache (miss) si les en-têtes spécifiés sont communs à de nombreuses requêtes.

Avant de commencer

  • Assurez-vous que Cloud CDN est activé. Pour obtenir des instructions, consultez la page Utiliser Cloud CDN.

  • Si nécessaire, installez la dernière version de Google Cloud CLI :

    gcloud components update

Configurer le contournement du cache

Vous pouvez indiquer jusqu'à cinq noms d'en-tête HTTP. Les valeurs ne sont pas sensibles à la casse. Le nom d'en-tête doit être un jeton de champ d'en-tête HTTP valide. Un nom d'en-tête ne doit pas apparaître plus d'une fois dans la liste des en-têtes ajoutés. Pour connaître les règles concernant les noms d'en-tête valides, consultez la section Fonctionnement des en-têtes personnalisés.

Console

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page Équilibrage de charge

  2. Cliquez sur le nom de votre équilibreur de charge d'application externe.
  3. Cliquez sur Modifier .
  4. Dans Configuration du backend, sélectionnez un backend, puis cliquez sur Modifier .
  5. Assurez-vous que l'option Activer Cloud CDN est sélectionnée.
  6. En bas de la fenêtre, cliquez sur Configurations avancées.
  7. Sous Contournement du cache sur l'en-tête de requête, cliquez sur Ajouter un en-tête.
  8. Saisissez un nom d'en-tête, tel que Pragma ou Authorization.
  9. Cliquez sur Mettre à jour.
  10. Cliquez à nouveau sur Mettre à jour.

gcloud

Pour les buckets de backend, exécutez la commande gcloud compute backend-buckets create ou gcloud compute backend-buckets update avec l'option --bypass-cache-on-request-headers.

Pour les services de backend, exécutez la commande gcloud compute backend-services create ou gcloud compute backend-services update avec l'option --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

Exemple :

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

api

Pour les buckets de backend, utilisez l'appel d'API Method: backendBuckets.insert, Method: backendBuckets.update ou Method: backendBuckets.patch..

Pour les services de backend, utilisez l'appel d'API Method: backendServices.insert, Method: backendServices.update ou Method: backendServices.patch..

Exemple :

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

Ajoutez l'extrait suivant au corps de la requête JSON :

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

Désactiver le contournement du cache

gcloud

Pour les buckets de backend, exécutez la commande gcloud compute backend-buckets create ou gcloud compute backend-buckets update avec l'option --no-bypass-cache-on-request-headers.

Pour les services de backend, exécutez la commande gcloud compute backend-services create ou gcloud compute backend-services update avec l'option --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

Pour les buckets de backend, utilisez l'appel d'API Method: backendBuckets.insert ou Method: backendBuckets.update.

Pour les services de backend, utilisez l'appel d'API Method: backendServices.insert ou Method: backendServices.update.

Utilisez l'un des appels d'API suivants :

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

Ajoutez l'extrait suivant au corps de la requête JSON :

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

Étape suivante