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 :

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

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

• Pour les URL et les cookies signés, FORCE_CACHE_ALL remplace l'âge maximal spécifié via le paramètre Âge maximal de l'entrée de cache 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, et inversement.

• 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 peut supprimer la mise en cache, même si le mode de cache est FORCE_CACHE_ALL. Pour en savoir plus, consultez En-têtes Vary.

Pour obtenir des instructions de configuration, consultez Définir le mode de 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 de directives de mise en cache explicites dans l'en-tête Cache-Control ou Expires, Cloud CDN met automatiquement cette réponse en cache 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 les formats 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 :

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 lorsque vous utilisez la console Google Cloud ou la Google Cloud CLI pour importer des contenus.

• Cloud Storage fournit toujours un en-tête Cache-Control à Cloud CDN. Si aucune valeur n'est explicitement choisie, une valeur par défaut est envoyée. Par conséquent, toutes les réponses Cloud Storage réussies sont mises en cache selon les valeurs par défaut de Cloud Storage, sauf si vous ajustez explicitement les métadonnées de contrôle du cache pour les objets dans Cloud Storage ou si vous utilisez le mode FORCE_CACHE_ALL pour remplacer les valeurs envoyées par Cloud Storage.

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

Si une réponse peut être mise en cache sur la base de son type MIME, mais qu'elle comporte un en-tête de réponse Cache-Control égal à private ou no-store, ou un en-tête Set-Cookie, elle n'est pas mise en cache. Pour en savoir plus, consultez les règles de mise en cache.

Les autres types de contenu, tels que HTML (text/html) et JSON (application/json), ne sont pas mis en cache par défaut pour les réponses réussies. Ces types de réponses sont généralement dynamiques (par utilisateur). Il peut s'agir, par exemple, de paniers d'achat, de pages de produits avec personnalisation par utilisateur ou de réponses d'API authentifiées. Si le cache négatif est activé, il peut tout de même entraîner la mise en cache de ces éléments pour certains codes d'état.

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.

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.

Pour les buckets backend Cloud Storage, suivez ces suggestions supplémentaires :

• Rendez votre bucket lisible publiquement. Il s'agit de l'approche que nous conseillons pour le contenu public. Avec ce paramètre, tous les internautes peuvent afficher et répertorier vos objets et leurs métadonnées, à l'exception des LCA. Il est recommandé de dédier des buckets spécifiques pour les objets publics.

• Utilisez des dossiers gérés pour rendre une partie de votre bucket lisible publiquement.

• Rendez des objets individuels lisibles publiquement. Nous ne recommandons pas cette approche, car elle utilise un ancien système d'autorisation spécifique à Cloud Storage.

• Ne stockez pas l'objet dans un bucket pour lequel l'option Paiements par le demandeur est activée ou qui se trouve dans un périmètre de service de cloud privé virtuel.

• Ne chiffrez pas l'objet à l'aide de clés de chiffrement gérées par le client ni de clés de chiffrement fournies par le client.

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 obtenir un exemple de configuration d'un équilibreur de charge d'application externe avec un bucket backend, consultez Configurer Cloud CDN avec un bucket 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.

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.

Si Cache-Control: no-store ou private est présent alors que le contenu se trouve toujours 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 directives 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 les directives 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.

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 d'application classique 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 des instructions, consultez Configurer 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.

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 de prendre 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 mise en cache de manière valide selon le paramètre TTL.

Vous pouvez utiliser une liste d'inclusion avec des paramètres de chaîne de requête 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 d'effectuer un cache busting du 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, les frameworks Web 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 en-têtes et des 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 de backend et les 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 (multivariables), 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 de cookie/en-tête à cardinalité élevées sur vos taux d'éviction du cache. Dans des circonstances et des conditions de trafic utilisateur normales, cela ne devrait pas être perceptible et garantit que le contenu populaire reste en cache.

Inclure les en-têtes de requête

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 de succès de 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 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-, tel que Access-Control-Request-Headers et Access-Control-Request-Method
  • Sec-Fetch-
  • Sec-GFE-
  • Sec-Google-
  • X-Amz-
  • X-GFE-
  • X-Goog-
  • X-Google-

Utiliser des variables personnalisées avec des en-têtes de requête

Les clés de cache sont utiles lorsque vous devez diffuser du contenu différemment en fonction de l'appareil et de la position de chaque utilisateur. Par exemple, vous pouvez permettre à un site Web responsif de diffuser les images appropriées pour les utilisateurs qui consultent du contenu en fonction du type d'appareil qu'ils utilisent, ou définir une langue par défaut utile en fonction de leur position. Vous pouvez définir des clés de cache à l'aide d'en-têtes de requête et de variables personnalisés.

Pour utiliser des variables personnalisées avec des en-têtes de requête, procédez comme suit :

1. Définissez un en-tête de requête personnalisé pour votre service de backend. Incluez une ou plusieurs variables pour la valeur de l'en-tête de requête personnalisé.
2. Mettez à jour la clé de cache pour utiliser l'en-tête de requête personnalisé.

Pour Cloud CDN, vous ne pouvez utiliser que les variables suivantes lorsque vous définissez des en-têtes qui sont à la fois des en-têtes de requête personnalisés et des en-têtes de clé de cache :

• device_request_type
• user_agent_family
• client_region
• client_region_subdivision

Cloud CDN limite les variables pour maintenir les performances du cache. Cela ressemble aux limites imposées aux en-têtes pouvant être utilisés comme clés de cache.

Par exemple, si vous pouviez spécifier X-Lat-Long:{client_city_lat_long} comme en-tête de requête personnalisé, puis ajouter X-Lat-Long à votre ensemble d'en-têtes de clé de cache, Cloud CDN tenterait de mettre en cache une copie de la réponse pour chaque valeur de client_city_lat_long. Cela entraînerait une surutilisation du cache, un vidage inutile du contenu et une réduction des opportunités de renvoyer des succès de cache.

Pour ces raisons, les variables à cardinalité élevée ne sont pas incluses dans la liste des variables utilisées pour définir les en-têtes de requête personnalisés et, par conséquent, les clés de cache.

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

Directives pour le contrôle du cache

Les directives 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 directive n'est pas applicable à une requête ou à une réponse.