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 le contenu statique qui ne comporte pas l'instruction no-store ou private. 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 des backends compatibles avec Cloud CDN créés à l'aide de l'outil de ligne de commande gcloud 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. Les réponses sans ces instructions sont transmises à partir de l'origine.
FORCE_CACHE_ALL Met en cache les réponses sans condition, en ignorant les instructions de cache définies par l'origine. Assurez-vous de ne pas mettre en cache du contenu privé et spécifique à l'utilisateur (tel que les réponses HTML dynamiques ou d'API) si vous utilisez un backend partagé sur lequel ce mode est configuré.

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 cache de sorte qu'il mette en cache l'ensemble du contenu statique, Cloud CDN met automatiquement en cache les réponses des é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 les formats H.264, H.265 et MP4 (video/mp4), ainsi que les fichiers audio, y compris MP3 (image/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 lors de l'importation lorsque vous utilisez Cloud Console ou l'outil gsutil pour importer des contenus.

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

La mise en œuvre actuelle de Cloud CDN stocke les réponses dans le cache si toutes les conditions suivantes sont remplies.

Attribute Exigence
Diffusée par Un service de backend, un bucket backend ou une origine personnalisée 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
Instruction de cache

Avec le mode de cache CACHE_ALL_STATIC, une réponse avec une instruction Cache-Control: public, un en-tête Expires ou un type de contenu statique.

Avec le mode de cache USE_ORIGIN_HEADERS, une réponse avec une instruction Cache-Control: public ou un en-tête Expires.

Avec le mode de cache FORCE_CACHE_ALL, la réponse est toujours éligible à la mise en cache.

Actualisation

Lorsque le mode de cache CACHE_ALL_STATIC est défini, la réponse comporte un en-tête Cache-Control avec une instruction max-age ou s-maxage, un en-tête Expires avec un horodatage dans le futur, ou un type de contenu statique.

Avec le mode de cache USE_ORIGIN_HEADERS, 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.

Avec le mode de cache FORCE_CACHE_ALL, toutes les réponses de backend sont considérées comme à jour.

Contenu

Contient un en-tête Content-Length, Content-Range ou Transfer-Encoding: chunked valide.

Par exemple, un en-tête Content-Length qui correspond à la taille de la réponse.

Taille Inférieure ou égale à la taille maximale.

Pour les réponses dont la taille est comprise entre 10 Mo et 5 To, 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, lorsque le bucket est public ou que les objets individuels sont publics et que les objets individuels ne spécifient pas de métadonnées Cache-Control, Cloud Storage attribue un en-tête Cache-Control: public, max-age=3600 à l'objet. Vous pouvez définir différentes valeurs à l'aide des métadonnées Cache-Control.

Pour obtenir un exemple de configuration d'un équilibreur de charge HTTP(S) externe avec un bucket de backend, consultez la page Configurer Cloud CDN avec un bucket de backend.

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
5 To (5 497 558 138 880 octets) 10 Mo (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.

La mise en œuvre actuelle de 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.

Attribute Exigence
Diffusée par Service de backend ou origine personnalisée où Cloud CDN n'est pas activé
Cookie Comporte un en-tête Set-Cookie
En-tête Vary Comporte une valeur autre que Accept, Accept-Encoding ou Origin.
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 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 être stockées dans aucun cache, pas même le cache d'un navigateur Web.
  3. Ne signez pas d'URL donnant accès à des informations privées. 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 évite la mise en cache accidentelle des contenus par utilisateur et/ou des contenus nécessitant une authentification. Le mode de cache FORCE_CACHE_ALL ne présente pas cette restriction.

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

Les en-têtes de réponse personnalisés vous permettent de spécifier des en-têtes ajoutés par l'équilibreur de charge HTTP(S) externe aux réponses acheminées via le 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.

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.

Pour les buckets backend, la clé de cache comprend l'URI sans le protocole, l'hôte ou la chaîne de requête.

Ainsi, pour un bucket de 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

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.

Les URL ayant un ordre différent pour les mêmes paramètres de requête génèrent des clés de cache différentes. Les deux URL suivantes possèdent des clés de cache différentes, bien qu'elles aient les mêmes paramètres de requête :

  • https://example.com/images/cat.jpg?user=user1&color=red
  • https://example.com/images/cat.jpg?color=red&user=user1

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.

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 de la route à 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 de la route à l'aide du mode de cache FORCE_CACHE_ALL.

public ND

Une réponse avec l'instruction public est mise en cache si la réponse est considérée comme pouvant être mise en cache dans son ensemble et si elle contient une instruction max-age ou s-maxage.

Lorsque vous utilisez les modes de cache CACHE_ALL_STATIC ou FORCE_CACHE_ALL, cette instruction n'est pas obligatoire.

private ND

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 de la route à 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 tous deux présents, s‑maxage est utilisé par le serveur.

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.

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

must-revalidate ND

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

Dans la mesure du possible, Cloud CDN s'efforce de respecter la norme RFC (HTTP RFC 7234), mais préfère optimiser le déchargement du cache et minimiser l'impact que les clients peuvent avoir sur le taux de succès et/ou la charge d'origine globale.

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 ni la décompression des réponses, 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.

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

Avec le mode de cache USE_ORIGIN_HEADERS, chaque entrée de cache d'un cache Cloud CDN présente 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 RFC 7234. 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.

Avec le mode de cache CACHE_ALL_STATIC, les en-têtes d'origine sont consultés par défaut pour déterminer l'actualisation. S'ils ne sont pas présents, tout contenu statique est considéré comme récent.

Avec le mode cache FORCE_CACHE_ALL, toutes les réponses de backend sont considérées comme à jour.

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

Cloud CDN revalide les objets mis en cache datant de plus de 30 jours. Cela permet d'invalider et d'expulser automatiquement le contenu obsolète mis en cache généré par l'utilisateur. Lorsqu'une valeur max-age ou s-maxage 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.

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 requête de validation distincte incluant les en-têtes If-Modified-Since et/ou If-None-Match.
  • Sinon, Cloud CDN ajoute les en-têtes If-Modified-Since et/ou If-None-Match à la requête du client et transfère la requête modifiée au 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.

Le délai d'expiration d'une entrée de cache correspond à la limite supérieure de la durée de validité de l'entrée de cache. La conservation d'une entrée dans le cache jusqu'à son expiration n'est pas garantie. Les entrées de cache d'un contenu peu populaire peuvent être supprimées pour libérer de la place pour un nouveau contenu. Indépendamment du délai d'expiration spécifié, les entrées en cache qui ne font l'objet d'aucun accès pendant 30 jours sont automatiquement supprimées.

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

Remplacements et paramètres TTL

Vous pouvez ajuster le comportement de Cloud CDN concernant son temps d'attente avant qu'il revalide le contenu.

Pour en savoir plus, consultez la page Utiliser les remplacements et les paramètres TTL.

Compatibilité avec 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/ou Content-Range
  • En-tête : ETag avec un validateur fort
  • En-tête : Last-Modified

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 la documentation de votre logiciel serveur Web pour plus d'informations sur l'activation de cette fonctionnalité. Pour en savoir plus 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 HTTP(S). 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.

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 de requêtes activée (cliquez pour agrandir)
Cloud CDN avec réduction de requêtes activée (cliquez pour agrandir)

En comparaison, avec la réduction de requêtes désactivée ou pour les requêtes qui ne peuvent pas faire l'objet d'une réduction, le nombre de requêtes d'origine et de réponses peut être égal au nombre de clients tentant de récupérer un objet qui n'est pas actuellement mis en cache.

Cloud CDN sans réduction de requêtes (cliquez pour agrandir)
Cloud CDN sans réduction de requêtes (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 du SDK Cloud 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 du SDK Cloud, 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 du SDK Cloud pour un service de backend, y compris les groupes de VM et les origines personnalisées, 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 du SDK Cloud :

    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 Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page Équilibrage de charge

  2. Cliquez sur le nom de votre équilibreur de charge HTTP(S) 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