Edge Security Acceleration:Configurer le TTL du cache

Remarques d'utilisation

• Vous pouvez modifier le temps de cache après l'ajout d'un nom de domaine. La durée de mise en cache influence directement le trafic vers l'origine ainsi que les coûts associés. Le délai d'expiration du cache détermine la fréquence des requêtes vers l'origine. Définissez la durée de mise en cache des ressources selon vos besoins métier.

  Un délai d'expiration trop court entraîne des requêtes fréquentes vers l'origine depuis CDNDCDN, ce qui augmente le trafic sur le serveur d'origine. À l'inverse, un délai trop long retarde la prise en compte des mises à jour de données.

• Une ressource mise en cache sur un POP CDNDCDN mais rarement consultée (c'est-à-dire peu sollicitée par les clients sur ce même POP CDNDCDN) risque d'être écrasée par d'autres ressources plus populaires présentes sur le POP CDNDCDN avant même l'expiration de son cache.

• Lorsqu'un POP DCDN reçoit un fichier statique depuis un serveur d'origine, il met la ressource en cache conformément aux règles et priorités de cache par défaut de DCDN. Pour plus d'informations sur les règles de cache applicables aux fichiers dynamiques, consultez la rubrique Présentation des règles d'accélération pour le contenu dynamique et statique.

• Évitez de mettre à jour le contenu de votre serveur d'origine en conservant le même nom de fichier. Privilégiez plutôt l'utilisation de numéros de version pour la synchronisation.

  Pour distinguer précisément le contenu avant et après une mise à jour, synchronisez votre contenu d'origine à l'aide de numéros de version. Cela implique d'utiliser des noms de fichiers différents lors des mises à jour. Par exemple, utilisez des noms tels que img-v1.0.jpg et img-v2.1.jpg.

Procédure

1. Connectez-vous à la console DCDN.

2. Dans le volet de navigation de gauche, cliquez sur Domain Names.

3. Sur la page Domain Names, localisez le nom de domaine cible et cliquez sur Configure.

4. Dans l'arborescence de navigation du nom de domaine, cliquez sur Caching.

5. Sous l'onglet Cache Duration, cliquez sur Add.

6. Dans la boîte de dialogue Cache Duration, configurez une règle de cache.

   

   Paramètre	Description
   Type	Spécifiez la portée des ressources par Directory ou par Filename Extension. Directory : applique la même règle de cache à toutes les ressources situées dans un chemin spécifié. Filename Extension : applique la même règle de cache aux ressources d'un type de fichier spécifié.
   Content	Répertoire ou extension de fichier auquel s'applique la règle. Si vous définissez Type sur Directory, tenez compte des points suivants : Un seul répertoire peut être ajouté à la fois. Une barre oblique (/) correspond à tous les répertoires. Saisissez le chemin complet du répertoire. Ce chemin doit commencer par une barre oblique (/). Exemple : /directory/aaa. Si vous définissez Type sur Filename Extension, notez les éléments suivants : Saisissez une ou plusieurs extensions de fichier. Séparez les extensions multiples par une virgule (,), par exemple jpg,txt. La saisie respecte la casse. Types de fichiers statiques pris en charge : Images : GIF, PNG, BMP, JPEG et JPG. Pages web : HTML, HTM et SHTML. Fichiers audio et vidéo : MP3, WMA, FLV, MP4, WMV, OGG et AVI. Documents : DOC, DOCX, XLS, XLSX, PPT, PPTX, TXT et PDF. Autres : ZIP, EXE, TAT, ICO, CSS, JS, SWF, APK, M3U8, TS, EJS, SVG, WOFF et OTF. L'utilisation d'un astérisque (*) pour correspondre à tous les types de fichiers n'est pas autorisée.
   Expire In	TTL du cache pour les ressources. La durée maximale est de 3 ans. Nous recommandons les paramètres suivants : Pour les fichiers statiques rarement mis à jour, comme les images et les packages d'applications, définissez un TTL d'un mois ou plus. Pour les fichiers statiques fréquemment mis à jour, tels que les fichiers JS et CSS, définissez un TTL personnalisé selon vos besoins métier. Pour les fichiers dynamiques, comme les fichiers PHP, JSP et ASP, réglez le TTL sur 0s afin d'empêcher leur mise en cache.
   Honor origin cache policy	Si cette option est activée, les en-têtes de politique de cache du serveur d'origine, tels que Cache-Control et Pragma, sont prioritaires.
   Ignore origin no-cache header	Lorsque cette fonctionnalité est activée, les POP DCDN ignorent les en-têtes de politique de cache suivants provenant de la réponse du serveur d'origine. Ces en-têtes indiquent que le contenu ne doit pas être mis en cache. Cache-Control: no-store Cache-Control: no-cache Cache-Control: max-age=0 Pragma: no-cache
   Client follows DCDN cache policy	Lorsque cette fonctionnalité est activée, les POP DCDN répondent au client avec la politique de cache effective.
   Force revalidation	Ce paramètre prend effet uniquement lorsque le TTL du cache est défini sur 0. Les effets sont les suivants : Désactivé (par défaut) : lorsque le TTL du cache pour /DCDN est réglé sur 0, les POP /DCDN ne mettent pas les fichiers en cache et une requête vers l'origine est effectuée pour chaque demande. Activé : lorsque le TTL du cache pour DCDN est réglé sur 0, les fichiers peuvent être mis en cache sur les POP DCDN, mais chaque requête nécessite une validation auprès de l'origine pour vérifier le contenu mis en cache.
   Weight	Priorité de la règle de cache. Les valeurs valides sont des entiers de 1 à 99. Une valeur plus élevée indique une priorité supérieure. La règle ayant la priorité la plus haute est appliquée en premier. Remarque Si vous configurez plusieurs règles de cache, attribuez un poids différent à chacune afin de contrôler leur priorité d'exécution. Lorsque plusieurs règles partagent le même poids, celle créée le plus tôt bénéficie d'une priorité supérieure, quel que soit son type. Si plusieurs politiques de cache sont configurées, DCDN cesse d'évaluer les autres politiques dès qu'une politique prend effet.
   Rule condition	Une condition de règle identifie diverses informations de paramètres dans une requête utilisateur. Cela détermine si une configuration s'applique à cette requête. Important Lorsque vous référencez des conditions de règle, celles-ci sont évaluées selon la priorité des conditions associées, et non selon l'ordre de configuration de la fonctionnalité elle-même. Do not use : n'utilise aucune condition de règle. Pour ajouter ou modifier des conditions de règle, gérez-les dans le Rules Engine.

7. Cliquez sur OK pour enregistrer la configuration.

   Une fois la règle de cache configurée, elle apparaît dans la liste sous l'onglet Cache Duration. Cliquez sur Modify ou Delete pour gérer la règle.

Règles et priorités de cache par défaut d'Alibaba Cloud CDNDCDN

1. Si le serveur d'origine répond avec pragma:no-cache, cache-control:no-cache (ou no-store, ou max-age=0), CDNDCDN ne met pas la ressource en cache.

2. Délai d'expiration du cache ou délai d'expiration du code d'état défini dans la console CDNDCDN.

   Remarque

   Si une requête CDNDCDN correspond à plusieurs règles, une seule règle est appliquée. La priorité est déterminée d'abord par le poids, puis par l'heure de création.

   • En cas de règles de cache multiples, attribuez un poids différent à chaque règle pour contrôler sa priorité d'exécution. Un poids plus élevé indique une priorité supérieure.

   • Pour les règles de même poids, celle créée le plus tôt a une priorité supérieure, indépendamment du type de règle.

3. Autres règles de cache configurées sur le serveur d'origine. L'ordre de priorité, du plus haut au plus bas, est le suivant : cache-control > expires > last-modified > ETag.

   1. Si l'en-tête cache-control dans la réponse du serveur d'origine spécifie une valeur max-age ou s-maxage supérieure à 0, l'en-tête cache-control définit la durée de vie. Par exemple : cache-control:max-age=3600. Si max-age et s-maxage sont tous deux présents, s-maxage prévaut.

   2. Si la réponse de l'origine ne contient pas d'en-tête cache-control mais contient un en-tête Expires, le délai d'expiration du cache est déterminé par l'en-tête Expires. Par exemple : expires:Tue, 25 Nov 2031 17:25:43 GMT.

   3. Si la réponse de l'origine ne contient ni cache-control ni Expires mais contient last-modified, le temps de cache est calculé selon la formule : (Heure actuelle - last-modified) × 0,1. Si le résultat se situe entre 10 secondes et 3600 secondes, cette valeur est retenue. Si le résultat est inférieur à 10 secondes, le temps de cache est fixé à 10 secondes. S'il dépasse 3600 secondes, le temps de cache est plafonné à 3600 secondes.

   4. Si la réponse de l'origine ne contient ni cache-control, ni Expires, ni last-modified mais contient ETag, la ressource est mise en cache pendant 10 secondes.

4. Si les données renvoyées par le serveur d'origine ne contiennent aucun des en-têtes de réponse liés au cache (cache-control, expires, last-modified ou ETag), la ressource n'est pas mise en cache par défaut.

Description des informations de réponse du cache

• Date :

  • Indique l'heure à laquelle le serveur d'origine a envoyé la ressource dans une réponse au POP CDNDCDN.

  • Lorsque le POP CDNDCDN revalide la ressource auprès du serveur d'origine en incluant l'en-tête If-Modified-Since ou If-None-Match dans la requête vers l'origine, les informations Date sont mises à jour si le serveur d'origine renvoie un code d'état 304.

  • Le format est l'heure moyenne de Greenwich (GMT), par exemple : Sat, 19 Apr 2025 08:58:31 GMT.

• X-Cache :

  Indique si la ressource demandée a été trouvée dans le cache du POP CDNDCDN. Le tableau suivant décrit les valeurs possibles.

  État	Description
  HIT	La ressource demandée a été trouvée dans le cache du POP CDNDCDN.
  MISS	La ressource demandée n'a pas été trouvée dans le cache du POP CDNDCDN. Elle a été fournie par le serveur d'origine.

• X-Swift-Cachetime :

  • Indique le temps de cache restant pour la ressource sur le POP CDNDCDN, en secondes.

  • X-Swift-Cachetime = Ali-Swift-Global-Savetime + Délai d'expiration du cache défini pour CDN - X-Swift-SaveTime.

  • X-Swift-Cachetime n'est pas toujours égal au délai d'expiration du cache défini pour CDNDCDN. Trois situations peuvent se présenter :

    • X-Swift-Cachetime = Délai d'expiration du cache défini pour CDNDCDN, par exemple 3600 secondes.

    • X-Swift-Cachetime est légèrement inférieur au délai d'expiration du cache défini pour CDNDCDN. Par exemple, le délai d'expiration du cache pour CDNDCDN est fixé à 300 secondes, mais X-Swift-Cachetime affiche 295 secondes. Cela peut s'expliquer par les raisons suivantes :

      • Une latence élevée survient lorsqu'un POP de niveau 1 récupère des données depuis un POP de niveau 2.

      • Les horloges des POP de niveau 1 et de niveau 2 ne sont pas synchronisées.

    • La valeur de X-Swift-Cachetime est négative. Cela peut résulter d'une modification du délai d'expiration du cache pour CDNDCDN. Lorsque le client envoie une requête, le cache sur le POP de niveau 1 a expiré, mais pas celui du POP de niveau 2. Par exemple, si le délai d'expiration du cache pour CDNDCDN était initialement de 3600 secondes puis a été réduit à 300 secondes, et qu'un client envoie une requête 600 secondes après la première demande, l'en-tête de réponse sera X-Swift-Cachetime:-300. Pour résoudre ce problème, actualisez le cache.

• X-Swift-SaveTime :

  • Indique l'heure à laquelle la ressource a été mise en cache pour la première fois sur le POP CDNDCDN auquel le client s'est connecté directement. Il s'agit généralement d'un POP de niveau 1.

  • Le format est l'heure moyenne de Greenwich (GMT), par exemple : Sat, 19 Apr 2025 08:58:31 GMT.

• Ali-Swift-Global-Savetime :

  • Indique l'heure à laquelle la ressource a été mise en cache pour la première fois sur un POP CDNDCDN. Il peut s'agir d'un POP de niveau 2 ou d'un POP situé à une autre couche de cache, selon l'architecture de cache du site.

  • Le format est un timestamp UNIX, par exemple : 1745053111, ce qui correspond à 2025-04-19 16:58:31.

Vérifier l'état du cache des ressources

Après avoir configuré un TTL de cache, utilisez ces méthodes pour vérifier si une ressource est servie depuis le cache DCDN.

• Méthode 1 : Utiliser la commande curl

  Dans le terminal, exécutez la commande suivante pour interroger l'URL cible à l'aide de curl -I, puis vérifiez le champ X-Cache dans l'en-tête de réponse pour déterminer si le cache a été sollicité.

  curl -I http://<accelerated_domain_name>/<resource_path>

  Dans les en-têtes de réponse, examinez le champ X-Cache :

  • X-Cache: HIT indique que la ressource a été servie depuis le cache DCDN.

  • X-Cache: MISS indique que la ressource n'a pas été trouvée dans le cache DCDN et a été servie directement par le serveur d'origine.

• Méthode 2 : Utiliser les outils de développement du navigateur

  Utilisez les outils de développement de votre navigateur (F12). Dans l'onglet Network, accédez à l'URL de la ressource. Sélectionnez la requête et inspectez l'en-tête X-Cache dans la réponse.

Mécanismes de contrôle du cache HTTP

Le protocole HTTP définit trois types de mécanismes de contrôle du cache :

1. Mécanisme de validation par délai d'expiration

   Lorsqu'un client demande une ressource à un serveur, un délai d'expiration est établi pour cette ressource. Avant cette échéance, la copie mise en cache est considérée comme valide. Passé ce délai, la copie en cache devient invalide.

   Voici les en-têtes HTTP courants qui contrôlent le délai d'expiration du cache :

   Nom de l'en-tête	Version du protocole	Fonction	Valeur d'exemple	Type
   Pragma	HTTP/1.0	Pragma indique si le contenu ne doit pas être mis en cache. La valeur typique est no-cache, signifiant que le fichier n'est pas mis en cache. Cet en-tête est souvent utilisé pour assurer la compatibilité avec les serveurs ne prenant en charge que HTTP/1.0.	Pragma:no-cache	Requête/Réponse
   Expires	HTTP/1.0	L'en-tête de réponse Expires contient une date et une heure après lesquelles le contenu mis en cache expirera. Si une date invalide est utilisée, telle que 0, cela signifie que la ressource a déjà expiré.	Expires: Wed, 21 Oct 2022 07:28:00 GMT	Réponse
   Cache-Control	HTTP/1.1	L'en-tête de réponse Cache-Control peut être défini avec différentes directives pour obtenir un contrôle flexible du cache. C'est l'en-tête principal utilisé par les clients modernes, tels que les navigateurs, pour gérer la mise en cache.	Les trois exemples suivants indiquent que le fichier ne doit pas être mis en cache : Cache-Control:no-cache Cache-Control:no-store Cache-Control:max-age=0 Exemple indiquant une période de validité du cache d'une heure : Cache-Control:max-age=3600	Requête/Réponse

2. Mécanisme de validation par tag de ressource

   Lorsqu'un client demande une ressource à un serveur pour la première fois, le serveur inclut un tag de ressource dans l'en-tête de réponse. Ce tag sert d'identifiant de validation pour les requêtes ultérieures concernant la même ressource. Lorsque le client redemande la ressource, il inclut ce tag dans l'en-tête de requête. Si le serveur valide le tag et constate que la ressource n'a pas été mise à jour, il répond avec un code d'état HTTP 304. Cela indique au client qu'il peut continuer à utiliser sa copie locale en cache. En cas de divergence détectée par le serveur, cela signifie que la ressource a été modifiée et le client doit récupérer à nouveau le contenu de la ressource.

   Voici les en-têtes HTTP courants qui contrôlent les versions de cache :

   Nom de l'en-tête	Version du protocole	Fonction	Valeur d'exemple	Type
   Last-Modified	HTTP/1.0	Last-Modified indique la date de dernière modification de la ressource.	Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT	Réponse
   ETag	HTTP/1.1	ETag fournit un identifiant unique pour une version spécifique d'une ressource. La comparaison des ETags permet de déterminer si une ressource a changé. Si elle n'a pas changé, le serveur d'origine n'a pas besoin d'envoyer une réponse complète.	ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"	Réponse

3. Mécanisme de négociation de copies multiples

   Les logiciels de mise en cache utilisent un mot-clé pour indexer les objets stockés sur un disque. Dans HTTP/1.0, l'URL de la ressource sert de mot-clé. Cependant, différentes ressources peuvent partager la même URL. Pour les distinguer, le client doit fournir des informations supplémentaires, telles que les en-têtes Accept-Language et Accept-Charset. Afin de prendre en charge ce mécanisme de négociation de contenu, HTTP/1.1 a introduit l'en-tête Vary dans le message de réponse. Cet en-tête spécifie quels en-têtes du message de requête sont utilisés pour la négociation de contenu.

   Le mécanisme de négociation de copies multiples utilise généralement l'en-tête HTTP Vary pour distinguer les différentes copies mises en cache. Cela permet à différents clients demandant la même ressource de recevoir des versions distinctes de celle-ci :

   Nom de l'en-tête	Version du protocole	Description	Valeur d'exemple	Type
   Vary	HTTP/1.1	Exemples courants : Le serveur spécifie Vary: Accept-Encoding pour informer le destinataire (tel qu'un POP DCDN) que deux versions de la ressource (compressée et non compressée) doivent être mises en cache. Lorsqu'un client demande la même ressource via DCDN, les anciens navigateurs reçoivent la ressource non compressée (pour éviter les problèmes de compatibilité), tandis que les navigateurs récents obtiennent la ressource compressée (afin de réduire le trafic de données). Le serveur spécifie Vary: User-Agent pour identifier le type de navigateur envoyant la requête, informant ainsi le destinataire (tel qu'un POP DCDN) de mettre en cache la version correspondante de la ressource selon le type de navigateur.	Vary: Accept-Encoding Vary: Accept-Encoding,User-Agent	Réponse

Exemples de configuration

Exemple 1 : Pour mettre en cache des fichiers .txt pendant 7 jours, ajoutez une règle de cache dans la console DCDN pour l'extension de fichier .txt et définissez le TTL du cache sur 7 jours.



Exemple 2 : Les politiques de cache suivantes sont configurées pour le nom de domaine accéléré demo.aliyun.com. Lorsqu'un POP DCDN récupère la ressource http://demo.aliyun.com/image/example.png depuis l'origine, deux règles correspondent. Comme les deux règles ont le même poids, le système privilégie celle créée en premier. La règle pour le répertoire /image ayant été créée plus tôt, c'est donc la règle basée sur le répertoire qui prend effet.

Référence API

BatchSetDcdnDomainConfigs