Partage via

Mise en cache avec Azure Front Door

  • Article

Important

Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium au plus en mars 2027. Pour plus d’informations, consultez Mise hors service d’Azure Front Door (classique).

Azure Front Door est un réseau de distribution de contenu (CDN) moderne qui prend en charge les fonctionnalités d’accélération de site dynamique et l’équilibrage de charge. Lorsque la mise en cache est configurée sur votre itinéraire, le site de périphérie qui reçoit chaque requête recherche une réponse valide dans son cache. La mise en cache permet de réduire la quantité de trafic envoyé à votre serveur d’origine. Si aucune réponse en cache n’est disponible, la requête est transférée à l’origine.

Chaque site Front Door en périphérie gère son propre cache et les demandes peuvent être traitées par différents sites de périphérie. Par conséquent, vous pouvez toujours voir du trafic atteindre votre origine, même si vous avez fourni des réponses mises en cache.

La mise en cache peut réduire considérablement la latence et réduire la charge sur les serveurs d’origine. Toutefois, tous les types de trafic ne peuvent pas tirer parti de la mise en cache. Les ressources statiques telles que les images, les fichiers CSS et JavaScript sont idéales pour la mise en cache. Bien que les ressources dynamiques, telles que les points de terminaison d’API authentifiés, ne doivent pas être mises en cache pour empêcher la fuite d’informations personnelles. Il est recommandé d’avoir des itinéraires distincts pour les ressources statiques et dynamiques, avec la mise en cache désactivée pour ces dernières.

Avertissement

Avant d’activer la mise en cache, regardez attentivement la documentation publique et testez tous les scénarios possibles avant d’activer la mise en cache. Comme indiqué précédemment, en cas de configuration incorrecte, vous pouvez accidentellement mettre en cache des données spécifiques à l’utilisateur, qui risquent d’être partagées par plusieurs utilisateurs résultant d’incidents de confidentialité.

Méthodes de demande

Seules les requêtes qui utilisent la méthode de requête GET peuvent être mises en cache. Toutes les autres méthodes de demande sont toujours traitées par proxy sur le réseau.

Distribution de fichiers volumineux

Azure Front Door permet de distribuer des fichiers volumineux sans aucune plafond de taille de fichier. Si la mise en cache est activée, Front Door utilise une technique appelée segmentation d’objets. Quand un fichier volumineux est demandé, l’instance Front Door récupère les petits éléments du fichier auprès de l’origine. Après avoir reçu une demande de fichier complet ou de fichier de plage d’octets, l’environnement Azure Front Door demande le fichier de l’origine par blocs de 8 Mo.

Dès qu’un bloc parvient à l’environnement Azure Front Door, il est mis en cache et immédiatement servi à l’utilisateur. L’instance Front Door se prépare ensuite en parallèle à récupérer le bloc suivant. Cette prérécupération garantit que le contenu a un bloc d’avance sur l’utilisateur, ce qui a réduit la latence. Ce processus se poursuit jusqu’à ce que le fichier entier soit téléchargé (si nécessaire) ou que le client ferme la connexion. Pour plus d’informations sur la demande de plage d’octets, consultez RFC 7233.

Front Door met en cache les blocs au fur et à mesure de leur réception, ce qui évite d’avoir à mettre l’intégralité du fichier dans le cache Front Door. Les demandes suivantes concernant le fichier ou les plages d’octets sont traitées à partir du cache. Si certains blocs ne sont pas mis en cache, ils sont demandés à l’origine via une pré-récupération.

Cette optimisation s’appuie sur la capacité de l’origine à prendre en charge les demandes de plages d’octets. Si l’origine ne prend pas en charge les requêtes de plage d’octets ou si elle ne gère pas correctement les requêtes de plage, cette optimisation n’est pas efficace.

Lorsque votre origine répond à une demande avec un en-tête Range, elle doit répondre de l’une des manières suivantes :

  • Retourne une réponse dans une plage. La réponse doit utiliser le code d’état HTTP 206. En outre, l’en-tête de réponse Content-Range doit être présent et doit correspondre à la longueur réelle du contenu retourné par votre origine. Si votre origine n’envoie pas les en-têtes de réponse corrects avec des valeurs valides, Azure Front Door ne met pas en cache la réponse, et vous pouvez voir un comportement incohérent.

    Conseil

    Si votre origine compresse la réponse, assurez-vous que la valeur d’en-tête Content-Range correspond à la longueur de la réponse compressée.

  • Retourne une réponse sans plage. Si votre origine ne peut pas gérer les demandes de plage, elle peut ignorer l’en-tête Range et renvoyer une réponse non limitée. Vérifiez que l’origine retourne un code d’état de réponse autre que 206. Par exemple, l’origine peut renvoyer une réponse 200 OK.

Si l’origine utilise l’encodage de transfert mémorisé en bloc (CTE) pour envoyer des données au POP Azure Front Door, les réponses supérieures à 8 Mo ne sont pas prises en charge.

Compression de fichiers

Reportez-vous à la documentation sur l’amélioration des performances en compressant les fichiers dans Azure Front Door.

Azure Front Door (classique) peut compresser de manière dynamique le contenu en périphérie, ce qui a pour effet de réduire la taille et le délai de la réponse envoyée à vos clients. Pour qu’un fichier soit éligible à la compression, la mise en cache doit être activée et le fichier doit être de type MIME pour être éligible à la compression. À l’heure actuelle, Front Door (classique) n’autorise pas la modification de cette liste. Voici la liste actuelle :

  • "application/eot"
  • "application/font"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Par ailleurs, la taille du fichier doit être comprise entre 1 Ko et 8 Mo (inclus).

Ces profils prennent en charge les encodages de compression suivants :

Si une demande prend en charge la compression gzip et Brotli, la compression Brotli est prioritaire.

Lorsqu’une demande portant sur une ressource spécifie une compression et qu’il en résulte une absence dans le cache, Azure Front Door (classique) compresse la ressource directement sur le serveur POP. Ensuite, le fichier compressé est servi à partir du cache. L’élément résultant est renvoyé avec un en-tête de réponse Transfer-Encoding: chunked.

Si l’origine utilise l’encodage de transfert mémorisé en bloc (CTE) pour envoyer des données au POP Azure Front Door, la compression n’est pas prise en charge.

Remarque

Les demandes de plage peuvent être compressées dans différentes tailles. Azure Front Door requiert que les valeurs Content-Length soient identiques pour toute requête HTTP GET. Si les clients envoient des demandes de plage d’octets avec l’en-tête Accept-Encoding qui amène l’origin à répondre avec des longueurs de contenu différentes, alors Azure Front Door renvoie une erreur 503. Vous pouvez soit désactiver la compression sur l’origine, soit créer une règle Moteur de règles pour supprimer l’en-tête Accept-Encoding des demandes de plage d’octets.

Comportement des chaînes de requête

Avec Azure Front Door, vous pouvez contrôler la manière dont les fichiers sont mis en cache pour une requête web qui contient une chaîne de requête.

Dans une requête web contenant une chaîne de requête, la chaîne de requête représente la partie de la demande qui apparaît après le point d’interrogation (?). Une chaîne de requête peut contenir une ou plusieurs paires clé-valeur où le nom du champ et sa valeur sont séparés par un signe égal (=). Chaque paire clé-valeur est séparée par une esperluette (&).

Par exemple, l’URL http://www.contoso.com/content.mov?field1=value1&field2=value2 contient deux chaînes de requête :

  • field1 avec la valeur value1.
  • field2 avec la valeur value2.

S’il existe plusieurs paires clé-valeur dans la chaîne de requête d’une demande, leur ordre n’a pas d’importance.

Lorsque vous configurez la mise en cache, vous spécifiez comment le cache doit gérer les chaînes de requête. Les comportements suivants sont pris en charge :

  • Ignorer la chaîne de requête : dans ce mode, Azure Front Door passe les chaînes de requête du client à l’origine à la première demande et met en cache la ressource. Les futures demandes portant sur la ressource, qui sont traitées par l’environnement Front Door, ignorent les chaînes de requête tant que la ressource mise en cache n’est pas arrivée à expiration.

  • Utiliser la chaîne de requête : dans ce mode, chaque demande contenant une URL unique, y compris la chaîne de requête, est traitée comme une ressource unique avec son propre cache. Par exemple, la réponse de l’origine à une demande pour www.example.ashx?q=test1 est mise en cache dans l’environnement Front Door et retournée pour les mises en cache subséquentes avec la même chaîne de requête. Une demande pour www.example.ashx?q=test2 est mise en cache en tant que ressource distincte avec son propre paramètre de durée de vie.

    L’ordre des paramètres de la chaîne de requête n’a pas d’importance. Par exemple, si l’environnement Azure Front Door inclut une réponse mise en cache pour l’URL www.example.ashx?q=test1&r=test2, une demande de www.example.ashx?r=test2&q=test1 est également traitée à partir du cache.

  • Ignorer les chaînes de requête spécifiées et Inclure les chaînes de requête spécifiées : dans ce mode, vous pouvez configurer Azure Front Door pour inclure ou exclure des paramètres spécifiés quand la clé de cache est générée.

    Par exemple, supposons que la clé de cache par défaut soit /foo/image/asset.html, et qu’une requête soit effectuée à l’URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. S’il existe une règle de moteur de règles pour exclure le paramètre de chaîne de requête userid, la clé de cache de chaîne de requête est /foo/image/asset.html?language=EN&sessionid=200.

Configurez le comportement de chaîne de requête sur l’itinéraire Front Door.

Vidage du cache

Consultez Vider le cache dans Azure Front Door pour savoir comment configurer le vidage du cache.

Azure Front Door met en cache les ressources tant que leur durée de vie (TTL) n’est pas arrivée à expiration. Chaque fois qu’un client demande un élément multimédia dont la durée de vie a expiré, l’environnement Front Door récupère une nouvelle copie mise à jour de l’élément multimédia pour servir la demande, puis stocke le cache actualisé.

La bonne pratique pour vous assurer que vos utilisateurs obtiennent toujours la dernière copie de vos éléments multimédia consiste à établir une version de vos ressources pour chaque mise à jour et à les publier en tant que nouvelles URL. Front Door récupère immédiatement les nouveaux éléments multimédias pour les demandes suivantes des clients. Il est parfois souhaitable de vider le contenu mis en cache sur tous les nœuds de périmètre et de tous les forcer à récupérer de nouveaux éléments multimédias mis à jour. Cela peut être dû à des mises à jour de votre application web, ou à la nécessité de mettre à jour rapidement les éléments multimédias contenant des informations incorrectes.

Capture d’écran du bouton et de la page de vidage du cache.

Sélectionnez les ressources que vous souhaitez supprimer définitivement des nœuds de périphérie. Pour effacer toutes les ressources, sélectionnez Vider tout. Dans le cas contraire, dans Chemin d’accès, entrez le chemin d’accès de chaque ressource que vous souhaitez supprimer définitivement.

Ces formats sont pris en charge dans les listes de chemins d’accès à vider :

  • Vidage à chemin unique : videz une ou plusieurs ressources individuelles en spécifiant leur chemin complet (sans le protocole ni le domaine) avec l’extension de fichier, par exemple /pictures/strasbourg.png.
  • Vidage de caractères génériques : l’astérisque (*) peut être utilisé comme caractère générique. Videz tous les dossiers, sous-dossiers et fichiers d’un point de terminaison en indiquant /* dans le chemin ou videz tous les sous-dossiers et fichiers d’un certain dossier en spécifiant le dossier suivi de /*, par exemple /pictures/*.
  • Vidage du domaine racine : videz la racine du point de terminaison avec « / » dans le chemin d’accès.

Notes

Vidage des domaines génériques : La spécification des chemins d’accès mis en cache pour le vidage, telle que décrite dans cette section, ne s’applique pas aux domaines génériques associés à Front Door. Actuellement, nous ne prenons pas en charge le vidage direct des domaines génériques. Vous pouvez vider les chemins d’accès de sous-domaines spécifiques en indiquant ce sous-domaine et le chemin de vidage. Par exemple, si Front Door a *.contoso.com, je peux supprimer définitivement les ressources de mon sous-domaine foo.contoso.com en saisissant foo.contoso.com/path/*. Actuellement, la spécification de noms d’hôtes dans le chemin de contenu de vidage est limitée aux sous-domaines des domaines génériques, le cas échéant.

Les vidages du cache dans la porte d’entrée ne respectent pas la casse. En outre, elles sont indépendantes des chaînes de requête, ce qui signifie que la purge d’une URL vide toutes les variantes de chaîne de requête de celle-ci.

Expiration du cache

L’ordre suivant des en-têtes sert à déterminer la durée de stockage d’un élément dans le cache :

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Certaines valeurs d’en-tête de réponse Cache-Control indiquent que la réponse ne peut pas être mise en cache. Ces valeurs incluent private, no-cache et no-store. Front Door respecte ces valeurs d’en-tête et ne met pas en cache les réponses, même si vous remplacez le comportement de mise en cache à l’aide du moteur de règles.

Si l’en-tête Cache-Control n’est pas présente sur la réponse de l’origine, par défaut, Front Door déterminera de manière aléatoire une durée de cache comprise entre un et trois jours.

Notes

L’expiration du cache ne peut pas dépasser 366 jours.

Vous pouvez voir REVALIDATED_HIT dans l’en-tête de réponse Cache-Control. Cela indique que le contenu mis en cache dans Azure Front Door a été revalidé avec le serveur d’origine avant d’être servi au client. Cela peut se produire lorsque le contenu mis en cache a expiré, mais que le serveur d’origine indique que le contenu n’a pas changé. Dans ce cas, le contenu mis en cache est servi au client et l’expiration du cache est réinitialisée.

En-têtes de requête

Les en-têtes de demande suivantes ne sont pas transférés à l’origine lorsque la mise en cache est activée :

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

Remarque

Les demandes qui incluent l’en-tête d’autorisation ne seront pas mises en cache, sauf si la réponse contient une directive Cache-Control qui autorise la mise en cache. Les directives Cache-Control suivantes ont cet effet : must-revalidate, public et s-maxage.

En-têtes de réponse

Si la réponse d’origine peut être mise en cache, l’en-tête Set-Cookie est supprimé avant l’envoi de la réponse au client. Si une réponse d’origine n’est pas mis en cache, Front Door ne supprime pas l’en-tête. Par exemple, si la réponse d’origine inclut une en-tête Cache-Control avec une valeur de max-age, cela indique à Front Door que la réponse peut être mise en cache et que l’en-tête Set-Cookie sera supprimée.

En outre, Front Door attache l’en-tête X-Cache à toutes les réponses. L’en-tête de réponse X-Cache inclut l’une des valeurs suivantes :

  • TCP_HIT ou TCP_REMOTE_HIT : le premier segment de 8 Mo de la réponse est une correspondance dans le cache, et le contenu est servi à partir du cache Front Door.
  • TCP_MISS : le premier segment de 8 Mo de la réponse est une erreur de cache et le contenu est extrait à partir de l’origine.
  • PRIVATE_NOSTORE : la requête ne peut pas être mise en cache, car l’en-tête de réponse Cache-Control est défini sur private (privé) ou sur no-store (sans stockage).
  • CONFIG_NOCACHE : la requête est configurée pour ne pas effectuer de mise en cache dans le profil Front Door.

Journaux d’activité et rapports

Le journal d’accès inclut l’état du cache pour chaque requête. En outre, les rapports incluent des informations sur la façon dont le cache d’Azure Front Door est utilisé dans votre application.

Le journal d’accès inclut l’état du cache pour chaque requête.

Comportement et durée de mise en cache

Le comportement du cache et la durée peuvent être configurés dans le moteur de règles. La configuration de la mise en cache du moteur de règles a toujours la priorité sur la configuration de l’itinéraire.

  • Lorsque la mise en cache est désactivée, Azure Front Door ne met pas en cache le contenu de la réponse, quelles que soient les directives de réponse d’origine.

  • Lorsque la mise en cache est activée, le comportement du cache diffère en fonction de la valeur de comportement de cache appliquée par le moteur de règles :

    • Respect de l’origine : Front Door respecte toujours la directive d’en-tête de réponse d’origine. Si la directive de l’origine est absente, Azure Front Door mettra le contenu en cache entre un et trois jours.
    • Toujours écraser : Azure Front Door écrase toujours la durée de mise en cache, ce qui signifie qu’il met en cache le contenu pendant la durée de mise en cache en ignorant les valeurs des directives de réponse de l’origine. Ce comportement est appliqué uniquement si la réponse est mise en cache.
    • Remplacer si l’origine est manquante : si l’origine ne retourne pas de valeurs de durée de vie de mise en cache, Azure Front Door utilise la durée de cache spécifiée. Ce comportement est appliqué uniquement si la réponse est mise en cache.

Notes

  • Azure Front Door n’offre aucune garantie quant à la durée pendant laquelle le contenu est stocké dans le cache. Le contenu mis en cache peut être supprimé du cache de périphérie avant l’expiration du contenu si le contenu n’est pas fréquemment utilisé. Front Door peut être en mesure de fournir des données à partir du cache, même si les données mises en cache ont expiré. Ce comportement peut aider votre site à rester partiellement disponible lorsque vos origines sont hors connexion.
  • Les origins peuvent spécifier de ne pas mettre en cache des réponses spécifiques à l’aide de l’en-tête Cache-Control avec la valeur no-cache, private ou no-store. Lorsqu’il est utilisé dans une réponse HTTP du serveur d’origine aux points de présence Azure Front Door, Azure Front Door prend en charge les directives de contrôle du cache et respecte les comportements de mise en cache pour les directives Cache-Control dans RFC 7234 - Protocole de transfert hypertexte (HTTP/1.1) : mise en cache (ietf.org).

Le comportement et la durée de la mise en cache peuvent être configurés à la fois dans la règle d’acheminement du concepteur Front Door et dans le moteur de règles. La configuration de la mise en cache du moteur de règles aura toujours la priorité sur la configuration de la règle d’acheminement du concepteur Front Door.

  • Lorsque la mise en cache est désactivée, Azure Front Door (classique) ne met pas en cache le contenu de la réponse, quelles que soient les directives de réponse d’origine.

  • Lorsque la mise en cache est activée, le comportement de mise en cache est différent selon les valeurs de l’option Utiliser la durée de mise en cache par défaut.

    • Lorsque l’option Utiliser la durée de mise en cache par défaut est définie sur Oui, Azure Front Door (classique) respecte toujours la directive d’en-tête de réponse de l’origine. Si la directive de l’origine est absente, Front Door mettra le contenu en cache entre un et trois jours.
    • Lorsque l’option Utiliser la durée de mise en cache par défaut est définie sur Non, Azure Front Door (classique) écrase toujours la durée de mise en cache (champs obligatoires), ce qui signifie qu’il met en cache le contenu pendant la durée de mise en cache en ignorant les valeurs des directives de réponse de l’origine.

Notes

  • Azure Front Door (classique) n’offre aucune garantie quant à la durée pendant laquelle le contenu est stocké dans le cache. Le contenu mis en cache peut être supprimé du cache de périphérie avant l’expiration du contenu si le contenu n’est pas fréquemment utilisé. Azure Front Door (classique) peut être en mesure de fournir des données à partir du cache, même si les données mises en cache ont expiré. Ce comportement peut aider votre site à rester partiellement disponible lorsque vos origines sont hors connexion.
  • La durée de mise en cache définie dans la règle d’acheminement du concepteur Front Door correspond à la durée minimale de mise en cache. Ce remplacement ne fonctionnera pas si l’en-tête de contrôle du cache de l’origin a une durée de vie supérieure à la valeur de remplacement.

Étapes suivantes