Qu’est-ce que la mise en cache CDN ?

La mise en cache sur CDN stocke des copies du contenu sur des sites de périphérie répartis géographiquement. Les requêtes peuvent être traitées près de leurs destinataires sans récupérer à répétition la même représentation depuis le serveur d’origine.

Un CDN associe une requête à un site de périphérie et tente de réutiliser un objet qui y est stocké ou qui se trouve dans un cache de protection intermédiaire. Si l’objet est absent du cache, le réseau récupère la représentation depuis un cache en amont ou le serveur d’origine, puis la stocke selon les règles de fraîcheur et d’admissibilité. Chaque site remplit son propre cache : un objet déjà en cache dans une région peut donc encore être absent du cache dans une autre, et un objet peu demandé peut être évincé avant son expiration. Pour les médias, les segments immuables et les variantes dérivées peuvent recevoir de longues durées de validité, tandis que les manifestes et les réponses dépendant d’une autorisation nécessitent généralement un traitement plus court ou plus sélectif.

Le manifeste d’un flux et ses segments multimédias nécessitent des durées de validité différentes. En HLS, une liste de lecture multimédia en direct est remplacée par une nouvelle version contenant au moins un nouveau segment à des intervalles d’environ une durée cible (la RFC 8216 impose un intervalle compris entre la moitié et une fois et demie cette durée). Un cache de périphérie qui conserve la liste plus longtemps masque donc les nouveaux segments aux lecteurs. Une liste de lecture marquée VOD ne doit pas changer et peut être mise en cache comme un fichier statique. Les segments sont récupérés séparément de la liste de lecture, chacun sous sa propre URL ou sous forme de plage d’octets d’un fichier plus volumineux, et peuvent avoir de longues durées de validité à condition que l’outil de mise en paquet ne modifie jamais les octets accessibles à une URL publiée, ce que la spécification elle-même ne garantit pas. Le projet de deuxième édition de HLS publié par Apple recommande, dans son profil de serveur à faible latence, de mettre en cache les réponses ordinaires de listes de lecture pendant la moitié de la durée cible et d’utiliser Cache-Control pour communiquer cette durée de validité.
La clé de cache détermine quelles requêtes partagent une entrée, et sa valeur par défaut varie selon le CDN. La clé par défaut d’Amazon CloudFront comprend le nom de domaine de la distribution et le chemin de l’URL, sans chaîne de requête, en-têtes ni cookies. Celle de Cloudflare comprend le schéma, l’hôte et le chemin avec la chaîne de requête, ainsi que l’en-tête Origin de la requête. Une même URL récupérée avec et sans Origin est donc stockée séparément. Google Cloud CDN utilise l’URI complète de la requête pour les services backend. Les requêtes partagent une entrée dès que leurs clés sont identiques, ce qui peut déjà se produire avec une configuration par défaut : avec celle de CloudFront, les URL qui ne diffèrent que par la chaîne de requête reçoivent la même réponse en cache. Incluez dans la clé chaque valeur de la requête qui modifie la réponse et excluez les autres, car un composant qui varie entre les requêtes sans modifier la réponse fragmente le cache et réduit le taux de succès du cache.
Pour les fichiers volumineux, renseignez-vous sur la façon dont le CDN traite les requêtes Range, car cela influe sur la charge de l’origine et le comportement de navigation dans le média. CloudFront transmet à l’origine toute plage qu’il ne détient pas, en demandant éventuellement une plage plus grande, puis met en cache la partie renvoyée ; si l’origine ne prend pas en charge les plages, CloudFront reçoit et met en cache l’objet entier. Google Cloud CDN remplit son cache avec ses propres requêtes de plages d’octets une fois qu’il a constaté que l’origine les prend en charge, ce qui nécessite Accept-Ranges: bytes, une longueur totale connue, ainsi que Last-Modified et un ETag fort. Il applique une taille maximale de mise en cache bien inférieure lorsque l’origine ne les prend pas en charge. Fastly ne met les objets volumineux en cache par parties que si Segmented Caching est activé. Une origine qui répond correctement aux requêtes de plages est donc un prérequis à la mise en cache de médias volumineux par parties.
L’admissibilité d’une réponse à la mise en cache est déterminée séparément de sa durée de fraîcheur, et la règle dépend du fournisseur. Par défaut, Cloudflare met les fichiers en cache selon leur extension et ne met pas le HTML ni le JSON en cache sans règle. Le mode par défaut de Google Cloud CDN met en cache les types de contenu statiques selon Content-Type et nécessite des directives explicites pour le HTML et le JSON. Google Cloud CDN ne met pas en cache une réponse qui définit un cookie ; selon sa configuration, Cloudflare laisse cette réponse hors du cache ou supprime le cookie et la met en cache. Lorsqu’une présence attendue en cache ne se confirme pas, consultez l’état du cache signalé par le CDN : sur Cloudflare, l’en-tête de réponse CF-Cache-Status indique MISS lorsque la réponse était admissible mais absente de ce cache, BYPASS lorsque la réponse de l’origine ne pouvait pas être mise en cache, et DYNAMIC lorsque la requête n’a jamais été admissible.

Configurez la mise en cache CDN pour réduire la latence des médias, diminuer la charge de l’origine et absorber les pics de trafic. Des clés de cache ou des règles de fraîcheur inadaptées peuvent entraîner la diffusion de variantes incorrectes ou laisser les utilisateurs avec du contenu périmé.

Le Smart CDN de Transloadit place un cache CDN devant le traitement à la demande. Les requêtes vers une URL tlcdn.com sont prises en charge par le Robot /tlcdn/deliver, qui met les résultats en cache et les sert depuis des sites périphériques. Si le résultat est absent du cache, l’Assembly du Template s’exécute ; s’il est présent, le serveur périphérique répond sans rien exécuter. Les valeurs de Cache-Control envoyées par le Robot /file/serve déterminent la durée pendant laquelle un résultat en cache reste frais.

La première requête pour une URL dont le résultat n’est pas en cache inclut le temps de récupération de la source et de traitement. Les durées par défaut actuelles figurent sur la page /file/serve et ne sont pas répétées ici, car elles peuvent changer.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que la mise en cache CDN ?

Fonctionnement de la mise en cache CDN

Points clés

Quand la mise en cache CDN est utile

Comment Transloadit facilite la mise en cache CDN

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle