Qu’est-ce qu’un serveur périphérique de CDN ?
Un serveur périphérique de CDN est un nœud d’un réseau distribué qui sert du contenu en cache ou relayé par proxy à relative proximité de l’émetteur d’une requête. Il peut aussi appliquer des politiques de routage, d’accès ou de transformation en périphérie.
Fonctionnement des serveurs périphériques de CDN
Un serveur périphérique est le point de traitement des requêtes sélectionné parmi les sites distribués d’un CDN pour un client et un instant donnés. Il termine la connexion, évalue la configuration périphérique, vérifie l’état du cache local ou hiérarchique, puis répond ou contacte un niveau en amont. Comme le routage et les objets en cache sont propres à chaque site, des URL identiques peuvent présenter une latence, un âge ou un comportement en cas de défaillance différents selon les régions.
Points clés
- Le serveur périphérique qui traite une requête est déterminé par le routage, pas par la distance sur une carte. Amazon CloudFront utilise le DNS pour diriger l’utilisateur vers le site le mieux à même de servir la requête, généralement le plus proche en matière de latence. Cloudflare répond aux requêtes DNS avec une adresse anycast. Avec l’anycast, le système de routage d’Internet choisit le nœud selon la topologie du réseau et le point d’entrée de la requête dans le réseau. La sélection fondée sur le DNS voit généralement l’adresse du résolveur récursif de l’utilisateur, dont la RFC 7871 indique qu’il peut être éloigné de l’utilisateur lorsqu’un résolveur centralisé est utilisé. Une requête peut donc aboutir dans une ville ou un pays différent de ce qui était attendu, et deux utilisateurs situés au même endroit sur des réseaux différents peuvent atteindre des serveurs périphériques différents.
- L’absence d’un résultat dans le cache périphérique n’entraîne pas toujours une requête à l’origine. Les sites périphériques de CloudFront interrogent généralement un cache périphérique régional avant l’origine, et Origin Shield ajoute une couche supplémentaire ; Tiered Cache de Cloudflare permet uniquement aux centres de données de niveau supérieur de contacter l’origine ; le mécanisme de cache bouclier de Fastly fait passer les requêtes par un site bouclier désigné. Le recours à ces niveaux dépend de certaines conditions. Origin Shield, Tiered Cache et le mécanisme de cache bouclier doivent être activés. CloudFront fait contourner les caches périphériques régionaux aux requêtes dynamiques et aux méthodes telles que
POST, même si AWS précise qu’Origin Shield, lorsqu’il est activé, reste sur le parcours des requêtes dynamiques. Cloudflare applique Tiered Cache uniquement aux requêtes admissibles à la mise en cache au moment de la requête. Lorsqu’une requête passe effectivement par un niveau supérieur, l’origine voit ce niveau et non le serveur périphérique atteint par l’utilisateur. Les journaux de l’origine ne suffisent donc pas à indiquer quel serveur périphérique a servi un utilisateur. Sur Cloudflare, par exemple, la valeur deCf-Rayenvoyée à l’origine désigne alors le centre de données qui s’est connecté à l’origine. - Les en-têtes de réponse et les journaux peuvent indiquer quel serveur périphérique a répondu et si le résultat était présent en cache, mais les noms dépendent du fournisseur. L’en-tête de réponse
Cf-Rayde Cloudflare se termine par un code de centre de données à trois lettres, etCF-Cache-Statusindique le résultat de la consultation du cache. Chez Fastly,X-Served-Bydésigne les serveurs de cache etX-CacheindiqueHITouMISS. Lorsque le mécanisme de cache bouclier est activé, la réponse habituelle comporte deux entrées, le bouclier en premier et le serveur périphérique côté utilisateur en second. Si le résultat est présent dans le cache périphérique, l’entrée du bouclier date de la première mise en cache de l’objet, et non de la requête actuelle. Les journaux de CloudFront enregistrentx-edge-locationetx-edge-result-type, et son en-tête de réponse facultatifServer-Timingcontientcdn-popet un résultat de consultation du cache :cdn-cache-hit,cdn-cache-missoucdn-cache-refresh(une copie en cache servie après que CloudFront a vérifié auprès de l’origine qu’elle est toujours valide). Les significations diffèrent également : Fastly signale une transmission sans mise en cache parMISS, et Cloudflare précise qu’avec Tiered Cache, la valeur deAged’un résultat présent dans le cache local peut provenir d’un niveau supérieur. La RFC 9211 définit un en-tête communCache-Statusà cette fin, mais chaque cache décide de l’envoyer ou non. Normalisez donc les données pour chaque fournisseur avant de les comparer. - Chaque site possède son propre contenu en cache et, pendant un certain temps après une modification, éventuellement sa propre configuration. Un objet est ajouté au cache du site qui a servi la requête, et un site peut évincer les objets moins populaires plus tôt qu’un autre. La fraîcheur est distincte de la configuration : la mise en cache HTTP permet à un cache de répondre à partir d’une copie stockée encore fraîche sans contacter l’origine. Après la modification d’un fichier à l’origine, un site peut donc continuer à servir l’ancienne copie jusqu’à son expiration ou son invalidation, et le contenu des caches peut différer d’un site à l’autre. Après une mise à jour de configuration, CloudFront précise que les modifications n’atteignent pas tous les sites périphériques en même temps et que, pendant la propagation, il est impossible de déterminer si un site donné utilise l’ancienne ou la nouvelle configuration. Un test depuis un site ne montre donc pas ce qu’un autre site sert.
Quand les serveurs périphériques de CDN sont utiles
Examinez le comportement des serveurs périphériques lorsque les utilisateurs d’une région constatent de la latence, des résultats absents du cache ou des réponses incohérentes. Les résultats peuvent différer selon le site, car le routage, l’état du cache et la propagation de la configuration varient.
Comment Transloadit facilite l’utilisation des serveurs périphériques de CDN
Le Smart CDN de Transloadit sert les résultats en cache depuis des sites périphériques via le Robot /tlcdn/deliver, utilisé implicitement pour les requêtes vers le domaine tlcdn.com. Si le résultat est présent en cache, le serveur périphérique répond sans exécuter le Template ; s’il est absent, l’Assembly du Template s’exécute d’abord. La première requête pour une URL dont le résultat n’est pas en cache inclut donc le temps de récupération de la source et de traitement.
Les pages liées ne répertorient pas les sites périphériques et ne nomment pas les en-têtes de réponse qui identifient le serveur périphérique ayant servi la réponse ou l’état de son cache.
Références
- Amazon CloudFront : diffusion du contenu par CloudFront (sites périphériques et caches périphériques régionaux)
- Amazon CloudFront : utiliser Amazon CloudFront Origin Shield
- Amazon CloudFront : référence de la journalisation standard (x-edge-location, x-edge-result-type)
- Amazon CloudFront : comprendre les politiques d’en-têtes de réponse (en-tête Server-Timing)
- Amazon CloudFront : mettre à jour une distribution (propagation vers les sites périphériques)
- Cloudflare : Tiered Cache
- Cloudflare : en-têtes HTTP (Cf-Ray et codes des centres de données)
- Cloudflare : réponses du cache (valeurs de CF-Cache-Status et en-tête Age)
- Fastly : mécanisme de cache bouclier
- Fastly : vérifier le cache (X-Served-By et X-Cache)
- Fastly : référence de l’en-tête X-Cache
- RFC 4786 : fonctionnement des services anycast
- RFC 7871 : sous-réseau du client dans les requêtes DNS
- RFC 9111 : mise en cache HTTP (section 4.2, fraîcheur)
- RFC 9211 : champ d’en-tête de réponse HTTP Cache-Status