infra / reseaux-tcp-ip

CDN et anycast

Leçon 181 exercice

Explication

Ce que vous allez apprendre

Comprendre pourquoi la distance physique impacte directement la latence perçue par l'utilisateur
Distinguer un CDN basé sur du GeoDNS d'un CDN basé sur l'anycast
Comprendre pourquoi l'anycast permet un failover automatique sans changement de configuration DNS
Piloter le cache d'un CDN depuis l'origine avec les en-têtes Cache-Control et s-maxage
Vérifier si une réponse vient du cache CDN ou de l'origine, et purger un cache après déploiement

Dans quel contexte ?

Un site e-commerce sert des utilisateurs en Europe, en Amérique et en Asie depuis un unique serveur d'origine situé à Paris. Les visiteurs australiens se plaignent de temps de chargement de plusieurs secondes, alors que les visiteurs français ne remarquent rien. En plaçant le site derrière un CDN anycast, chaque visiteur est automatiquement routé vers le point de présence le plus proche géographiquement, sans configuration DNS différenciée par région — la latence australienne chute drastiquement.

Le problème : la distance physique coûte du temps

Même à la vitesse de la lumière, une requête qui parcourt la moitié du globe prend un temps mesurable — assez pour que l'utilisateur le perçoive. Un CDN (Content Delivery Network) résout ce problème en répliquant le contenu sur des serveurs répartis géographiquement, pour que chaque utilisateur soit servi par une copie proche de lui plutôt que par un serveur unique et lointain.

Approche	Mécanisme	Failover
GeoDNS (CDN traditionnel)	Le DNS répond une IP différente par région	Nécessite un changement DNS, plus lent
Anycast (CDN moderne)	Une seule IP annoncée via BGP depuis plusieurs sites	Automatique, géré par le routage réseau

Astuce

Pour vérifier si une réponse vient du cache CDN ou remonte jusqu'à l'origine, inspecte l'en-tête de réponse (cf-cache-status chez Cloudflare, x-cache ailleurs) : HIT = servi depuis le cache du point de présence, MISS = requête remontée jusqu'au serveur d'origine.

Deux façons de diriger l'utilisateur vers le bon serveur

La méthode historique (GeoDNS) répond différemment à la même requête DNS selon la localisation détectée du visiteur : chaque emplacement a sa propre adresse IP, et c'est le DNS qui choisit laquelle donner. La méthode moderne, l'anycast, va plus loin : une seule et même adresse IP est annoncée simultanément depuis plusieurs datacenters à travers le monde, via BGP (vu dans la leçon précédente). C'est le routage réseau lui-même, pas le DNS, qui achemine automatiquement chaque utilisateur vers l'instance la plus proche selon la topologie du réseau à cet instant.

Pourquoi l'anycast est particulièrement robuste

Comme le choix du serveur se fait au niveau du routage réseau plutôt qu'au niveau applicatif, si un datacenter tombe en panne, BGP retire simplement son annonce et le trafic bascule automatiquement vers le datacenter suivant le plus proche — sans configuration DNS à changer, sans attente de propagation. C'est ce mécanisme qui permet à des adresses comme 1.1.1.1 de répondre en quelques millisecondes partout dans le monde.

Le rôle du cache, une couche indépendante

Un CDN ne fait pas que rapprocher géographiquement : il met aussi en cache le contenu pour éviter de recontacter le serveur d'origine à chaque requête. Les en-têtes HTTP (Cache-Control, s-maxage) permettent à l'origine de contrôler précisément combien de temps le CDN doit conserver une copie avant de revérifier — un contrôle distinct du cache navigateur classique.

Commandes & code

CDN et anycast

# CDN (Content Delivery Network) : réplique du contenu sur des serveurs proches géographiquement
# des utilisateurs, pour réduire la latence et la charge sur l'origine.

# Anycast : PLUSIEURS serveurs, dans des lieux différents, PARTAGENT LA MÊME adresse IP.
# Le routage réseau (BGP) envoie chaque utilisateur vers l'instance la plus proche/rapide,
# sans configuration côté client -> c'est ainsi que 1.1.1.1 ou 8.8.8.8 répondent "instantanément" partout.

# Observer l'anycast en pratique : le même /24 est annoncé depuis plusieurs continents
dig +short 1.1.1.1 -x                       # reverse DNS générique, ne révèle pas le POP
mtr -rw 1.1.1.1                               # le nombre de sauts varie fortement selon TA localisation
traceroute 1.1.1.1                              # le dernier saut avant 1.1.1.1 identifie le datacenter le plus proche

# Vérifier depuis quel Point of Presence (POP) un CDN te sert (souvent exposé en header/endpoint debug)
curl -sI https://cloudflare.com | grep -i cf-ray        # ex: cf-ray: 8a1b2c3d4e5f6789-CDG (CDG = Paris)
curl -s https://www.cloudflare.com/cdn-cgi/trace           # endpoint de debug : colo=CDG, loc=FR...

# --- CDN traditionnel : DNS-based (pas d'anycast) ---
# Le résolveur DNS répond avec une IP différente selon la localisation géographique du client
# (GeoDNS) -> chaque POP a sa propre IP, le routage se fait AU NIVEAU DNS, pas réseau

# --- CDN moderne : Anycast (Cloudflare, Google, la plupart des gros CDN actuels) ---
# UNE SEULE IP publique, annoncée en BGP depuis chaque datacenter -> le routage Internet
# choisit lui-même le chemin le plus court, avec un failover automatique si un POP tombe

# Cache-Control : piloter la mise en cache CDN depuis l'origine
# Réponse HTTP typique d'une origine derrière un CDN
add_header Cache-Control "public, max-age=3600, s-maxage=86400";
# max-age    -> durée de cache côté navigateur
# s-maxage   -> durée de cache côté CDN/proxy partagé, prioritaire sur max-age pour les caches partagés
add_header Vary "Accept-Encoding";     # évite de servir du contenu compressé à un client qui ne le supporte pas

# Purger le cache d'un CDN après un déploiement (API typique, exemple Cloudflare)
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://exemple.com/app.js"]}'

# Vérifier si une réponse vient du cache CDN ou de l'origine
curl -sI https://exemple.com/app.js | grep -i "cf-cache-status\|x-cache"
# HIT = servi depuis le cache du POP, MISS = requête remontée jusqu'à l'origine

Résumé

L'anycast fait router automatiquement chaque client vers l'instance la plus proche via BGP, avec un failover réseau natif si un site tombe.
Un CDN plus ancien peut reposer sur du GeoDNS (IP différente par région) plutôt que sur l'anycast.
s-maxage pilote le cache CDN indépendamment du cache navigateur ; les headers cf-cache-status/x-cache révèlent un HIT ou un MISS.

Exercices pratiques

1 disponible

Mission : justifier une migration GeoDNS vers anycast et rassurer la sécurité

Objectif : Expliquer le mécanisme de failover anycast et le lien de confiance qu'il partage avec BGP, puis diagnostiquer le comportement du cache CDN.

Contexte

Une entreprise migre son CDN d'un système GeoDNS traditionnel vers un CDN anycast moderne. L'équipe infrastructure vante la robustesse du failover automatique, mais l'équipe sécurité s'inquiète : après avoir étudié le BGP hijack dans la leçon précédente, elle se demande si l'anycast est vraiment plus sûr ou juste plus rapide.

Résoudre l’exercice →