Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre la clé de cache

La clé de cache détermine si une demande d'un utilisateur à un emplacement CloudFront périphérique entraîne un accès au cache. La clé de cache est l'identifiant unique d'un objet dans le cache. Chaque objet du cache possède une clé de cache unique.

Un accès au cache se produit lorsqu'une demande d'utilisateur génère la même clé de cache qu'une requête précédente, et que l'objet de cette clé de cache est dans le cache de l'emplacement périphérique et valide. En cas d'accès au cache, l'objet demandé est diffusé au spectateur depuis un emplacement CloudFront périphérique, ce qui présente les avantages suivants :

Vous pouvez obtenir de meilleures performances à partir de votre site Web ou de votre application lorsque vous avez un taux d'accès au cache plus élevé (une proportion plus élevée de requêtes de visionneuse entraînant un accès au cache). Une façon d'améliorer votre taux d'accès du cache est d'inclure uniquement les valeurs minimales nécessaires dans la clé de cache. Pour plus d'informations, consultez les sections suivantes.

Vous pouvez modifier les valeurs (chaînes de requête URL, en-têtes HTTP et cookies) dans la clé de cache à l'aide d'une stratégie de cache. (Vous pouvez également modifier la clé de cache à l'aide d'une fonction Lambda @Edge.) Avant de modifier la clé de cache, il est important de comprendre comment votre application est conçue et quand et comment elle peut servir différentes réponses en fonction des caractéristiques de la requête de la visionneuse. Lorsqu'une valeur dans la demande de visionneuse détermine la réponse renvoyée par votre origine, vous devez inclure cette valeur dans la clé de cache. Mais si vous incluez une valeur dans la clé de cache qui n'affecte pas la réponse renvoyée par votre origine, vous risquez de mettre en cache des objets en double.

Clé de cache par défaut

Par défaut, la clé de cache d'une CloudFront distribution inclut les informations suivantes :

Les autres valeurs de la demande de visionneuse ne sont pas incluses dans la clé de cache, par défaut. Examinez la requête HTTP suivante provenant d'un navigateur Web.

            GET /content/stories/example-story.html?ref=0123abc&split-pages=false HTTP/1.1
            Host: d111111abcdef8.cloudfront.net
            User-Agent: Mozilla/5.0 Gecko/20100101 Firefox/68.0
            Accept: text/html,*/*
            Accept-Language: en-US,en
            Cookie: session_id=01234abcd
            Referer: https://news.example.com/
        

Lorsqu'une requête d'utilisateur comme dans cet exemple arrive à un emplacement CloudFront périphérique, CloudFront utilise la clé de cache pour déterminer s'il y a un accès au cache. Par défaut, seuls les composants suivants de la demande sont inclus dans la clé de cache : /content/stories/example-story.html et d111111abcdef8.cloudfront.net. Si l'objet demandé n'est pas dans le cache (erreur de cache), CloudFront envoie une demande à l'origine pour obtenir l'objet. Après avoir récupéré l'objet, il le CloudFront renvoie au visualiseur et le stocke dans le cache de l'emplacement périphérique.

Lorsqu'il CloudFront reçoit une autre demande pour le même objet, telle que déterminée par la clé de cache CloudFront , envoie immédiatement l'objet mis en cache au spectateur, sans envoyer de demande à l'origine. Prenons l'exemple de la demande HTTP suivante qui vient après la demande précédente.

            GET /content/stories/example-story.html?ref=xyz987&split-pages=true HTTP/1.1
            Host: d111111abcdef8.cloudfront.net
            User-Agent: Mozilla/5.0 AppleWebKit/537.36 Chrome/83.0.4103.116
            Accept: text/html,*/*
            Accept-Language: en-US,en
            Cookie: session_id=wxyz9876
            Referer: https://rss.news.example.net/
        

Cette demande concerne le même objet que la demande précédente, mais elle est différente de la demande précédente. Il a une chaîne de requête URL différente, différents en-têtes User-Agent et Referer et un cookie session_id différent. Cependant, aucune de ces valeurs ne fait partie de la clé de cache par défaut, de sorte que cette deuxième demande entraîne un accès au cache.

Personnaliser la clé de cache

Dans certains cas, vous pouvez inclure plus d'informations dans la clé de cache, même si cela peut entraîner moins de visites de cache. Vous spécifiez les éléments à inclure dans la clé de cache à l'aide d'une stratégie de cache.

Par exemple, si votre serveur d'origine utilise l'en-tête HTTP Accept-Language dans les demandes de l'utilisateur pour renvoyer un contenu différent en fonction de la langue de l'utilisateur, vous pouvez inclure cet en-tête dans la clé de cache. Lorsque vous le faites, CloudFront utilisez cet en-tête pour déterminer les accès au cache et incluez-le dans les demandes d'origine (demandes CloudFront envoyées à l'origine en cas de perte de cache).

L'inclusion de valeurs supplémentaires dans la clé de cache CloudFront peut avoir pour conséquence de mettre en cache des objets dupliqués en raison des variations qui peuvent survenir dans les demandes des utilisateurs. Par exemple, les utilisateurs peuvent envoyer l'une des valeurs suivantes pour l'en-tête Accept-Language :

Toutes ces différentes valeurs indiquent que la langue de l'utilisateur est l'anglais, mais la variation peut CloudFront entraîner la mise en cache du même objet plusieurs fois. Cela peut réduire les accès au cache et augmenter le nombre de demandes d'origine. Vous pouvez éviter cette duplication en n'incluant pas l'en-tête Accept-Language dans la clé de cache et en configurant votre site Web ou votre application de manière à utiliser différentes URL pour le contenu dans différentes langues (par exemple, /en-US/content/stories/example-story.html).

Pour toute valeur donnée que vous avez l'intention d'inclure dans la clé de cache, vous devez vous assurer de comprendre combien de variations différentes de cette valeur peuvent apparaître dans les demandes de l'utilisateur. Pour certaines valeurs de demande, il est rarement logique de les inclure dans la clé de cache. Par exemple, l'en-tête User-Agent peut avoir des milliers de variations uniques, de sorte que ce n'est généralement pas un bon candidat à inclure dans la clé de cache. Les cookies qui ont des valeurs spécifiques à l'utilisateur ou à la session et qui sont uniques sur des milliers (voire des millions) de demandes ne sont pas non plus de bons candidats pour l'inclusion dans la clé de cache. Si vous incluez ces valeurs dans la clé de cache, chaque variation unique entraîne une autre copie de l'objet dans le cache. Si ces copies de l'objet ne sont pas uniques, ou si vous vous retrouvez avec un nombre si important d'objets légèrement différents que chaque objet ne reçoit qu'un petit nombre de visites de cache, vous pouvez envisager une approche différente. Vous pouvez exclure ces valeurs hautement variables de la clé de cache ou marquer des objets comme ne pouvant pas être mis en cache.

Faites preuve de prudence lors de la personnalisation de la clé de cache. Parfois, c'est souhaitable, mais cela peut avoir des conséquences inattendues telles que la mise en cache des objets en double, la réduction du taux d'accès du cache et l'augmentation du nombre de demandes d'origine. Si votre site web ou votre application d'origine doit recevoir certaines valeurs provenant des demandes de l'utilisateur pour l'analyse, la télémétrie ou d'autres utilisations, mais que ces valeurs ne modifient pas l'objet renvoyé par l'origine, utilisez une stratégie de demande d'origine pour inclure ces valeurs dans les demandes d'origine, mais ne pas les inclure dans la clé de cache.