Partage via

Comment la mise en cache fonctionne

  • Article

Important

Azure CDN Standard de Microsoft (classique) sera mis hors service le 30 septembre 2027. Pour éviter toute interruption de service, il est important de migrer vos profils du niveau Azure CDN Standard de Microsoft (classique) vers le niveau Azure Front Door Standard ou Premium au plus tard le 30 septembre 2027. Pour découvrir plus d’informations, consultez Mise hors service d’Azure CDN Standard de Microsoft (classique).

Azure CDN d’Edgio sera mis hors service le 4 novembre 2025. Pour éviter toute interruption de service, vous devez migrer votre charge de travail vers Azure Front Door avant cette date. Pour plus d’informations, consultez FAQ sur la mise hors service d’Azure CDN d’Edgio.

Cet article fournit une vue d’ensemble des concepts généraux de mise en cache et de la manière dont Azure Content Delivery Network utilise la mise en cache pour améliorer les performances. Si vous souhaitez savoir comment personnaliser le comportement de mise en cache sur votre point de terminaison de réseau de distribution de contenu, consultez Contrôler le comportement de mise en cache d’Azure Content Delivery Network au moyen de règles de mise en cache et Contrôler le comportement de mise en cache d’Azure Content Delivery Network à l’aide de chaînes de requête.

Introduction de la mise en cache

La mise en cache est le processus de stockage local des données afin que les requêtes futures relatives à ces dernières soient plus rapidement accessibles. Dans le type le plus courant de mise en cache, la mise en cache du navigateur web, un navigateur web stocke localement des copies des données statiques sur un disque dur local. À l’aide de la mise en cache, le navigateur web peut éviter d’effectuer plusieurs allers-retours au serveur et, au lieu de cela, accéder localement aux mêmes données, ce qui permet d’économiser du temps et des ressources. La mise en cache est bien adaptée à la gestion locale de données statiques de petite taille, telles que les images statiques, les fichiers CSS et les fichiers JavaScript.

De même, la mise en cache est utilisée par un réseau de distribution de contenu sur des serveurs Edge proches de l’utilisateur afin d’éviter le retour de requêtes à leur l’origine et la réduction de la latence de l’utilisateur final. Contrairement à un cache de navigateur web, qui est utilisé uniquement pour un seul utilisateur, le réseau de distribution de contenu utilise un cache partagé. Dans un cache de réseau de distribution de contenu partagé, un fichier demandé par un utilisateur peut être utilisé par un autre utilisateur, ce qui réduit considérablement le nombre de requêtes au serveur d’origine.

Les ressources dynamiques qui changent fréquemment ou qui sont propres à un utilisateur individuel ne peuvent pas être mises en cache. Toutefois, ces types de ressources peuvent bénéficier de l’optimisation de l’accélération de site dynamique (DSA) sur le réseau de distribution de contenu Azure pour améliorer leurs performances.

La mise en cache peut avoir lieu à plusieurs niveaux entre le serveur d’origine et l’utilisateur final :

  • Serveur web : utilise un cache partagé (pour plusieurs utilisateurs).
  • Réseau de distribution de contenu : utilise un cache partagé (pour plusieurs utilisateurs).
  • Fournisseur de services Internet (ISP) : utilise un cache partagé (pour plusieurs utilisateurs).
  • Navigateur web : utilise un cache privé (pour un utilisateur).

En général, chaque cache gère l’actualisation de ses propres ressources et effectue une validation lorsqu’un fichier est périmé. Ce comportement est défini dans la spécification de mise en cache HTTP, RFC 7234.

Actualisation des ressources

Une ressource mise en cache pouvant être obsolète ou périmée (par rapport à la ressource correspondante sur le serveur d’origine), il est important pour tout mécanisme de mise en cache de contrôler quand le contenu est actualisé. Pour gagner du temps et de la bande passante, une ressource mise en cache n’est pas comparée à la version du serveur d’origine à chaque fois qu’elle est utilisée. Tant qu’une ressource mise en cache est considérée comme actualisée, elle est plutôt supposée être la version la plus récente et envoyée directement au client. Une ressource mise en cache est considérée comme actualisée lorsque son âge est inférieur à la période ou à l’âge définis par un paramètre de cache. Par exemple, lorsqu’un navigateur recharge une page web, il vérifie que chaque ressource mise en cache sur votre disque dur est actualisée et la charge. Si la ressource n’est pas actualisée (est périmée), une copie à jour est chargée à partir du serveur.

Validation

Si une ressource est considérée comme périmée, le serveur d’origine est invité à la valider pour déterminer si les données du cache correspondent toujours à celles du serveur d’origine. Si le fichier a été modifié sur le serveur d’origine, le cache met à jour sa version de la ressource. Sinon, si la ressource est actualisée, les données sont fournies directement à partir du cache sans validation préalable.

Mise en cache du réseau de distribution de contenu

La mise en cache fait partie intégrante de la façon dont un réseau de distribution de contenu fonctionne pour accélérer la distribution et réduire la charge d’origine des ressources statiques, telles que des images, des polices et des vidéos. Dans la mise en cache du réseau de distribution de contenu, les ressources statiques sont stockées de manière sélective sur des serveurs placés stratégiquement plus près de l’utilisateur, et présentent les avantages suivants :

  • Étant donné que la majorité du trafic web est statique (par exemple, les images, les polices et les vidéos), la mise en cache du réseau de distribution de contenu réduit la latence du réseau en déplaçant le contenu plus près de l’utilisateur, ce qui réduit la distance de déplacement des données.

  • En déchargeant le travail sur un réseau de distribution de contenu, elle peut réduire le trafic réseau et la charge sur le serveur d’origine. Cela réduit les coûts et les ressources requises pour l’application, même en présence d’un grand nombre d’utilisateurs.

Comme dans un navigateur web, vous pouvez contrôler comment la mise en cache est effectuée dans un réseau de distribution de contenu en envoyant des en-têtes de la directive du cache. Les en-têtes de la directive du cache sont des en-têtes HTTP qui sont généralement ajoutés par le serveur d’origine. Bien que la plupart de ces en-têtes aient été initialement conçus pour traiter la mise en cache dans des navigateurs clients, ils sont aussi maintenant utilisés par tous les caches intermédiaires tels que les réseaux de distribution de contenu.

Deux en-têtes peuvent être utilisés pour définir l’actualisation du cache : Cache-Control et Expires. Cache-Control est plus récent et est prioritaire sur Expires, le cas échéant. Il existe également deux types d’en-tête utilisés pour la validation (appelés validateurs) : ETag et Last-Modified. ETag est plus récent et est prioritaire sur Last-Modified si les deux sont définis.

En-têtes de la directive du cache

Important

Par défaut, un point de terminaison Azure Content Delivery Network optimisé pour DSA ignore les en-têtes de la directive du cache et contourne la mise en cache. En ce qui concerne les profils Azure CDN Standard d’Edgio, vous pouvez ajuster la manière dont un point de terminaison Azure Content Delivery Network traite ces en-têtes en utilisant des règles de mise en cache de réseau de distribution de contenu pour activer la mise en cache. Dans le cas des profils Azure CDN Premium d’Edgio, vous utiliserez le moteur de règles pour activer la mise en cache.

Azure Content Delivery Network prend en charge les en-têtes de la directive de cache HTTP suivants, qui définissent la durée et le partage du cache.

Cache-Control :

  • Introduit dans HTTP 1.1 pour permettre aux éditeurs web de mieux contrôler leur contenu et de traiter les limitations de l’en-tête Expires.
  • Remplace l’en-tête Expires si lui et Cache-Control sont définis.
  • Lorsqu’elle est utilisée dans une requête HTTP du client sur le point de présence (POP) du réseau de distribution de contenu, la directive Cache-Control est ignorée par l’ensemble des profils Azure Content Delivery Network, par défaut.
  • Quand elle est utilisée dans une réponse HTTP du serveur d’origine sur le point de présence du réseau de distribution de contenu :
    • Azure CDN Standard/Premium d’Edgio et Azure CDN Standard de Microsoft prennent en charge l’ensemble des directives Cache-Control.
    • Azure CDN standard/Premium d’Edgio et Azure CDN Standard de Microsoft respectent les comportements de mise en cache pour les directives Cache-Control dans RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching (ietf.org).

Expires :

  • En-tête hérité introduit dans HTTP 1.0 ; pris en charge pour la compatibilité descendante.
  • Utilise une heure d’expiration basés sur une date avec une précision à la seconde.
  • Semblable à Cache-Control: max-age.
  • Utilisé lorsque Cache-Control n’existe pas.

Pragma :

  • Non honoré par Azure Content Delivery Network, par défaut.
  • En-tête hérité introduit dans HTTP 1.0 ; pris en charge pour la compatibilité descendante.
  • Utilisé comme en-tête de requête client avec la directive suivante : no-cache. Cette directive indique au serveur de fournir une version actualisée de la ressource.
  • Pragma: no-cache équivaut à Cache-Control: no-cache.

Validateurs

Lorsque le cache est périmé, les validateurs de cache HTTP sont utilisés pour comparer la version mise en cache d’un fichier avec la version sur le serveur d’origine. Azure CDN Standard/Premium d’Edgio prend en charge les validateurs ETag et Last-Modified par défaut, tandis qu’Azure CDN Standard de Microsoft prend en charge uniquement Last-Modified.

ETag :

  • Azure CDN Standard/Premium d’Edgio prend en charge ETag par défaut, ce qui n’est pas le cas d’Azure CDN Standard de Microsoft.
  • ETag définit une chaîne unique pour chaque fichier et chaque version d’un fichier. Par exemple : ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Introduit dans HTTP 1.1 et plus actuel que Last-Modified. Utile lorsque la date de dernière modification est difficile à déterminer.
  • Prend en charge à la fois la validation forte et la validation faible ; toutefois, Azure Content Delivery Network prend en charge uniquement la validation forte. Pour la validation forte, les deux représentations de la ressource doivent être identiques à l’octet près.
  • Un cache valide un fichier qui utilise ETag en envoyant un en-tête If-None-Match dont la requête contient un ou plusieurs validateurs ETag. Par exemple : If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Si la version du serveur correspond à un validateur ETag dans la liste, celui-ci envoie le code d’état 304 (Non modifié) dans sa réponse. Si la version est différente, le serveur répond avec le code d’état 200 (OK) et la ressource mise à jour.

Last-Modified :

  • Pour Azure CDN Standard/Premium d’Edgio uniquement, la directive Last-Modified est utilisée si ETag ne fait pas partie de la réponse HTTP.
  • Spécifie la date et l’heure auxquelles le serveur d’origine a déterminé la dernière modification de la ressource. Par exemple : Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • Pour du contenu d’une taille supérieure à 8 Mo, les serveurs back-ends d’origine doivent conserver des horodatages Last-Modified cohérents par ressource. Le fait de retourner des dates/heures Last-Modified incohérentes depuis des serveurs back-ends entraîne des erreurs de non-correspondance des validateurs et des échecs HTTP 5XX. Stockage Azure peut ne pas prendre en charge des horodatages Last-Modified cohérents entre les réplicas, ce qui peut entraîner des erreurs similaires de non-correspondance des validateurs.
  • Un cache valide un fichier en utilisant Last-Modified en envoyant un en-tête If-Modified-Since dont la requête contient une date et une heure. Le serveur d’origine compare la date avec l’en-tête Last-Modified de la ressource la plus récente. Si la ressource n’a pas été modifiée depuis l’heure spécifiée, le serveur renvoie le code d’état 304 (non modifié) dans sa réponse. Si la ressource a été modifiée, le serveur retourne le code d’état 200 (OK) et la ressource mise à jour.

Déterminer quels fichiers peuvent être mis en cache

Toutes les ressources ne peuvent pas être mises en cache. Le tableau suivant montre quelles ressources peuvent être mises en cache, en fonction du type de réponse HTTP. Les ressources fournies avec des réponses HTTP ne remplissant pas toutes ces conditions ne peuvent pas être mises en cache. Pour Azure CDN Premium d’Edgio uniquement, il est possible d’utiliser le moteur de règles pour personnaliser certaines de ces conditions.

Azure Content Delivery Network de Microsoft Azure Content Delivery Network d’Edgio
Codes d’état HTTP 200, 203, 206, 300, 301, 410, 416 200
Méthodes HTTP GET, HEAD GET
Limites de taille de fichiers 300 Go 300 Go

Pour permettre l’activation de la mise en cache d’Azure CDN Standard de Microsoft sur une ressource, le serveur d’origine doit prendre en charge les requêtes HTTP HEAD et GET et les valeurs content-length doivent être identiques pour l’ensemble des réponses HTTP HEAD et GET associées à la ressource. Dans le cas d’une requête HEAD, le serveur d’origine doit prendre en charge la requête HEAD et répondre avec les en-têtes qu’il aurait utilisés s’il avait reçu une requête GET.

Remarque

Les demandes qui contiennent l’en-tête d’autorisation ne seront pas mises en cache.

Comportement de mise en cache par défaut

Le tableau suivant décrit le comportement de mise en cache par défaut des produits Azure Content Delivery Network et de leurs optimisations.

Microsoft : Livraison web générale Edgio : livraison web générale Edgio: DSA
Honorer l’origine Oui Oui Non
Durée du cache du réseau de distribution de contenu Deux jours Sept jours Aucun

Honorer l’origine : indique s’il faut honorer les en-têtes de la directive du cache pris en charge s’il y en a dans la réponse HTTP du serveur d’origine.

Durée du cache du réseau de distribution de contenu : indique le temps pendant lequel une ressource est mise en cache sur le réseau de distribution de contenu Azure. Toutefois, si Honorer l’origine est Oui et que la réponse HTTP du serveur d’origine inclut l’en-tête de la directive de cache Expires ou Cache-Control: max-age, Azure Content Delivery Network utilise la valeur de la durée spécifiée par l’en-tête à la place.

Remarque

Azure Content Delivery Network n’offre aucune garantie quant à la durée minimale pendant laquelle l’objet sera stocké dans le cache. Le contenu mis en cache risque d’être supprimé du cache du réseau de distribution de contenu avant son expiration s’il n’est pas demandé aussi fréquemment, afin de faire de la place pour le contenu plus fréquemment demandé.

Étapes suivantes