En configurant des règles d'expiration du cache, vous contrôlez la durée de conservation des ressources sur les points de présence (POP) CDNDCDN, afin d'équilibrer l'actualité du contenu, les performances d'accès et les coûts de récupération depuis le serveur d'origine. Cette rubrique explique comment configurer et valider les règles de cache, fournit des conseils de dépannage et présente les bonnes pratiques.
Fonctionnement
Lorsqu'une requête atteint un point de présence (POP) CDNDCDN, le système suit le processus priorisé suivant pour décider s'il doit servir une copie mise en cache ou récupérer le dernier contenu depuis le serveur d'origine.
CDNDCDN ne met pas en cache les ressources si le serveur d'origine répond avec
pragma:no-cache,cache-control:no-cache(ouno-store, oumax-age=0).-
Les règles de cache configurées dans la console CDNDCDN sont prioritaires, sauf si le serveur d'origine envoie explicitement une directive no-cache comme décrit ci-dessus.
-
Logique de priorité lorsque plusieurs règles de cache de la console correspondent à une requête :
Scénario
Logique de priorité
Exemple
Poids différents
La règle au poids le plus élevé (1-99) est prioritaire.
La règle A (répertoire
/image/, poids 50) et la règle B (extension de fichier.jpg, poids 90) correspondent toutes deux àimage/a.jpg. La règle B s'applique car son poids est supérieur.Même poids
La règle créée en premier est prioritaire.
Vous configurez une règle de répertoire (
/static/) et une règle d'extension de fichier (.js) pour un nom de domaine, toutes deux avec un poids de 60. Si la règle de répertoire a été créée avant celle d'extension, une requête pour/static/app.jscorrespond à la règle de répertoire. Dès qu'une requête correspond à une règle de cache, le système n'évalue aucune autre règle.
Par défaut, si le serveur d'origine répond avec
Pragma: no-cacheouCache-Control: no-cache/no-store/max-age=0, le POP CDNDCDN ne met pas la ressource en cache. Pour forcer la mise en cache, sélectionnez Ignore Origin No-Cache Header lors de la configuration de la règle d'expiration du cache.
-
-
CDNDCDN respecte les en-têtes de réponse HTTP du serveur d'origine si une requête ne correspond à aucune règle de la console CDNDCDN, ou si la règle correspondante a l'option Honor Origin TTL activée. La priorité des en-têtes, de la plus élevée à la plus faible, est la suivante :
cache-control>expires>last-modified>ETag.En-tête de réponse
CDN gestion
Remarques et exemples
Cache-Control
Utilise d'abord
s-maxage(durée du cache CDN), puismax-age.Exemple :
s-maxage=86400, max-age=3600Expires
Spécifie l'heure d'expiration. Cet en-tête n'est utilisé qu'en l'absence d'en-tête
Cache-Control.Exemple :
Expires: Wed, 21 Oct 2025 07:28:00 GMTLast-Modified
L'en-tête
Last-Modifiedest un horodatage indiquant la date de dernière modification de la ressource.La durée de mise en cache se calcule comme suit :
(Heure actuelle -
last-modified) × 0,1. La durée calculée est ensuite plafonnée entre un minimum de 10 secondes et un maximum de 3 600 secondes.Exemple :
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMTETag
Un
ETagest un identifiant unique généré par le serveur pour une version spécifique d'une ressource, généralement un hachage ou un numéro de version.Par défaut, une ressource dotée d'un
ETagest mise en cache pendant 10 secondes.Exemple :
ETag: "abc123" Politique no-cache CDNDCDN : Si une requête ne correspond à aucune règle de cache dans la console CDNDCDN et que le serveur d'origine ne renvoie pas d'en-têtes de réponse de cache tels que
Cache-Control, alors CDNDCDN applique une politique no-cache.
CDNDCDN applique les politiques de cache uniquement aux requêtes pour lesquelles le serveur d'origine renvoie un code d'état 200, 203, 206, 300, 301, 308 ou 410. Pour mettre en cache des requêtes avec d'autres codes d'état, tels que 404, vous devez configurer ce comportement sous Cache Configuration > Status Code Expiration.
Procédure
Console (recommandé)
Dans la console CDN, accédez à la page Domain Names et cliquez sur Manage à côté du nom de domaine cible.
-
Sur la page Cache > Cache Expiration , cliquez sur Create Rule pour configurer une règle de cache.
Paramètre
Description
Valeur par défaut/exemple
Type
Spécifiez la portée de la règle par Directory ou File Extension.• Directory : définit une règle de cache uniforme pour toutes les ressources sous un chemin.• File Extension : définit une règle de cache uniforme pour les fichiers d'un type spécifique.
Directory, File Extension
Object
Saisissez une valeur en fonction du type sélectionné :• Directory : doit commencer par une barre oblique (
/), par exemple/static/. Une seule barre oblique (/) correspond à tous les chemins. Vous ne pouvez ajouter qu'un seul répertoire à la fois.• File Extension : saisissez une ou plusieurs extensions de fichier, séparées par des virgules, par exemplejpg,png,css. Les entrées sont sensibles à la casse et ne prennent pas en charge la barre verticale () ni d'autres symboles.
/static/,jpg,png,cssExpire In
Durée de mise en cache des ressources sur les POP. La durée maximale est de trois ans.• Pour les ressources statiques rarement mises à jour (par exemple, images, programmes d'installation), définissez une durée ≥ 1 mois.• Pour les ressources statiques fréquemment mises à jour (par exemple, fichiers JS/CSS), définissez une durée plus courte, telle que 1 à 7 jours.• Pour le contenu dynamique (par exemple, pages PHP/JSP), définissez la durée sur 0 seconde (pas de cache).
0 seconde à 3 ans
Honor Origin TTL
Cette option est désactivée par défaut. Si elle est activée, la politique de cache du serveur d'origine est prioritaire et remplace cette règle.
Off
Ignore Origin No-Cache Header
Si cette option est activée, CDN ignore les directives no-cache suivantes du serveur d'origine :
Cache-Control: no-store,no-cache, oumax-age=0, etPragma: no-cache. Les ressources sont mises en cache selon la règle de la console.Off
Follow POP Cache Policy
Si cette option est activée, CDN renvoie sa politique de cache effective, telle que
max-age=3600, au client dans l'en-tête de réponse.Off
Force Revalidation
Ce paramètre n'est effectif que lorsque la durée d'expiration est définie sur 0 seconde.• Désactivé (par défaut, équivalent à la politique de cache
no-store) : le POP ne met pas le fichier en cache et chaque requête doit être transférée au serveur d'origine pour récupérer le contenu.• Activé (équivalent à la politique de cacheno-cache) : le POP met le fichier en cache, mais chaque requête doit être revalidée auprès du serveur d'origine en utilisant le mécanisme 304. Cela s'avère utile pour les scénarios nécessitant une validation en temps réel tout en réduisant la pression sur la bande passante du serveur d'origine.Off
Weight
Priorité de la règle. La valeur peut aller de 1 à 99, une valeur plus élevée indiquant une priorité plus grande. Lorsque plusieurs règles correspondent à la même ressource, la règle au poids le plus élevé est prioritaire. Si les poids sont identiques, la règle créée en premier est prioritaire. Nous vous recommandons de définir un poids élevé pour les chemins ou extensions de fichier spécifiques et un poids faible pour le répertoire racine (
/) afin d'obtenir un contrôle granulaire.1 à 99
Rule Condition
Affinez davantage la portée de la règle en fonction des paramètres de requête tels que les en-têtes et les paramètres URL. Cette option n'est pas utilisée par défaut. Pour configurer des conditions, utilisez le Rule Engine. Lorsque des conditions de règle sont référencées, elles sont mises en correspondance en fonction de la priorité des conditions associées, et non de l'ordre de configuration de la fonctionnalité elle-même.
Do not use
Logique de correspondance des règles de cache
Les règles d'expiration du cache CDN prennent en charge deux types de règles avec des comportements de correspondance différents :
Directory : utilise la correspondance par préfixe de chemin. Par exemple, la configuration de
/static/correspond à toutes les ressources sous ce répertoire (telles que/static/image/1.jpget/static/css/style.css). La configuration de/correspond à tous les chemins. Le chemin du répertoire doit commencer par une barre oblique (/). Chaque règle ne prend en charge qu'un seul répertoire.-
File Extension : utilise la correspondance exacte de l'extension. Saisissez les extensions sans points et séparez plusieurs extensions par des virgules (par exemple,
jpg,css,js). Les extensions ne prennent en charge que les caractères alphanumériques, sans restriction sur les types d'extensions spécifiques. Les types suivants peuvent tous être configurés :Extensions de ressources statiques courantes :
jpg,png,gif,css,js,htmlExtensions de fichiers de police :
ttf,otf,woff,woff2,eotExtensions de pages dynamiques :
php,aspx,jspToute autre extension alphanumérique
Prenez note des points suivants concernant la correspondance des règles de cache :
Lorsque plusieurs règles de cache correspondent à la même requête (par exemple, une règle de répertoire et une règle d'extension de fichier), la règle au Weight le plus élevé est prioritaire. Les règles ayant des poids égaux sont départagées par ordre de création (la règle la plus ancienne gagne). Pour plus de détails, consultez la section « Fonctionnement » ci-dessus.
Si vous associez une condition de règle (configurée dans le Rule Engine) à une règle de cache, plusieurs conditions utilisent la logique ET — la requête doit satisfaire à toutes les conditions pour correspondre.
Si vous définissez une règle no-cache globale pour toutes les extensions dynamiques (telles que
aspx), assurez-vous qu'elle n'affecte pas les ressources statiques que vous souhaitez mettre en cache. Pour mettre en cache les fichiers de police, ajoutez une règle dédiée avec des extensions telles quettf,otf,woff,woff2,eot.
API
Appelez l'opération d'API BatchSetCdnDomainConfig pour configurer plusieurs noms de domaine par lots. Pour plus d'informations sur la configuration des paramètres pour d'autres fonctionnalités, consultez Domain name configuration functions.
Appliquer immédiatement les modifications de règles
Les nouvelles règles ou les règles modifiées s'appliquent uniquement aux ressources nouvellement mises en cache. Les ressources précédemment mises en cache continuent d'utiliser l'ancienne politique de cache jusqu'à leur expiration.
Pour appliquer immédiatement de nouvelles règles à l'ensemble du réseau, vous devez vider manuellement le cache existant. Si vous modifiez une règle, effectuez une opération de purge en utilisant la fonctionnalité Purge and Prefetch resources. Si vous ajoutez une nouvelle règle, effectuez une opération de préchargement en utilisant la fonctionnalité prefetch resource.
Vérification
Une fois la configuration terminée, vous pouvez utiliser la commande curl ou les outils de développement du navigateur pour inspecter les en-têtes de réponse HTTP d'une ressource et vérifier que la mise en cache fonctionne comme prévu.
1. Exécuter la commande de vérification
Exécutez la commande suivante dans votre terminal pour tester la configuration.
curl -I "https://your.domain.com/path/to/file.jpg"2. Interpréter les principaux en-têtes de réponse
|
En-tête de réponse |
Description |
|
|
Indique si la requête a atteint le cache CDNDCDN.- |
|
|
Après avoir activé « Client Follows CDNDCDN Cache Policy », cet en-tête affiche la directive de mise en cache que CDNDCDN transmet au navigateur, telle que |
|
|
Durée totale configurée de mise en cache de la ressource sur le POP, en secondes. |
Bonnes pratiques
Utilisez des noms de fichiers versionnés (recommandé) : lorsque vous mettez à jour une ressource statique comme
style.css, utilisez un nouveau nom de fichier avec une version ou un hachage, tel questyle-v2.cssoustyle-a1b2c3d.css, et mettez à jour la référence dans votre HTML. Cette méthode garantit que les utilisateurs reçoivent immédiatement le dernier contenu sans nécessiter de purge manuelle du cache CDNDCDN et constitue la méthode recommandée pour mettre à jour le contenu mis en cache.Mettez en œuvre la séparation du contenu dynamique et statique : utilisez des noms de domaine ou des chemins de répertoire différents pour les ressources dynamiques et statiques. Configurez des règles de cache distinctes à poids élevé pour chacune afin d'éviter les conflits de politique. Par exemple, définissez une longue durée de mise en cache pour toutes les ressources du répertoire
/static/et aucune mise en cache pour les ressources du répertoire/api/.Utilisez efficacement le cache du navigateur : activez « Client follows CDNDCDN cache policy » pour réduire les requêtes répétées vers CDNDCDN, améliorer la vitesse de chargement et économiser le trafic CDNDCDN.
Évitez les durées de cache excessivement courtes : une durée de cache courte amène CDNDCDN à effectuer de fréquentes récupérations depuis l'origine, ce qui annule les avantages de l'accélération et augmente le trafic et les coûts de votre serveur d'origine.
Soyez prudent avec les longues durées de cache : une longue durée de cache peut empêcher les clients de recevoir rapidement les mises à jour de contenu. Pour le contenu nécessitant des mises à jour fréquentes, assurez-vous de purger le cache ou d'utiliser des noms de fichiers versionnés.
Scénarios de petits fichiers : pour les ressources de petits fichiers dans l'industrie du jeu (telles que les fichiers de configuration et les packages d'actifs) qui sont mises à jour peu fréquemment (par exemple, hebdomadairement ou bimensuellement), définissez la durée d'expiration du cache sur 15 jours ou adaptez-la au cycle réel de mise à jour des ressources. Cela permet d'équilibrer la vitesse de mise à jour et les performances d'accélération. Une durée de cache trop courte entraîne de fréquentes récupérations depuis l'origine et réduit les avantages de l'accélération ; une durée trop longue risque de diffuser du contenu obsolète aux joueurs. Nous vous recommandons d'utiliser la fonctionnalité purge and prefetch pour actualiser proactivement le cache lorsque le contenu est mis à jour.
Mécanismes de contrôle de cache HTTP
Le protocole HTTP utilise trois types d'en-têtes pour le contrôle du cache :