6 min de lecture

CDN et performance web - 01 - Comment fonctionne un CDN : cache, edge et origin

Le fonctionnement d'un CDN en détail : serveurs edge, cache hit/miss, TTL, invalidation et headers HTTP de cache.

CDN cache performance infrastructure HTTP
CDN et performance web 2 / 8
  1. 01 CDN et performance web - 00 - C'est quoi un CDN et pourquoi t'en as besoin
  2. 02 CDN et performance web - 01 - Comment fonctionne un CDN : cache, edge et origin
  3. 03 CDN et performance web - 02 - Configurer Cloudflare devant ton site
  4. 04 CDN et performance web - 03 - CDN devant un bucket : servir des images et fichiers statiques
  5. 05 CDN et performance web - 04 - La sécurité offerte par un CDN : DDoS, WAF et bot protection
  6. 06 CDN et performance web - 05 - Optimiser les performances : cache rules, workers et compression
  7. 07 CDN et performance web - 06 - Comparatif : Cloudflare vs CloudFront vs Fastly vs les autres
  8. 08 CDN et performance web - 07 - Glossaire
← Precedent Suivant →

01 - Comment fonctionne un CDN : cache, edge et origin

Ce que tu vas apprendre

  • Le parcours complet d'une requête à travers un CDN
  • Les concepts de serveur origin, edge et PoP
  • Les headers HTTP de cache et comment les lire
  • Le problème de l'invalidation de cache

Prerequisites

Le parcours d'une requête

Quand un utilisateur tape paltemps.fr dans son navigateur, voici ce qui se passe avec un CDN devant le site :

  1. Le DNS resout paltemps.fr vers l'IP du serveur edge Cloudflare le plus proche de l'utilisateur (pas vers mon VPS).
  2. Le serveur edge vérifié son cache local. Si le contenu est la et pas expire, il le renvoie directement. C'est un cache HIT.
  3. Si le contenu n'est pas dans le cache (première requête ou TTL expire), le serveur edge contacte le serveur origin (mon VPS a Paris). C'est un cache MISS.
  4. Le serveur origin répond, le edge stocke la réponse dans son cache, puis la transmet a l'utilisateur.
  5. Les requêtes suivantes depuis la meme region sont servies depuis le cache edge. Le VPS ne voit rien.

Trois acteurs dans ce schema. Le serveur origin, c'est ton VPS, ton serveur applicatif, là où ton code tourne. Le serveur edge, c'est le noeud CDN proche de l'utilisateur. Le PoP (Point of Presence), c'est le data center physique qui contient un ou plusieurs serveurs edge.

Les headers HTTP de cache

Le cache HTTP repose sur des headers. C'est le serveur origin qui décidé quoi cacher et pour combien de temps, et le CDN respecte ces instructions (en theorie).

Les headers les plus importants :

Cache-Control est le boss. Quelques directives courantes :

  • max-age=3600 : le navigateur peut garder la réponse 1 heure
  • s-maxage=86400 : le CDN (shared cache) peut garder la réponse 24 heures
  • no-cache : revalidation obligatoire avant utilisation (ca ne veut PAS dire "ne pas cacher")
  • no-store : ne jamais stocker, nulle part
  • stale-while-revalidate=60 : servir le contenu expire pendant qu'on revalide en arriere-plan

ETag est un identifiant de version. Le serveur envoie un ETag avec la réponse, et le client peut renvoyer un If-None-Match avec cette valeur. Si le contenu n'a pas change, le serveur répond 304 Not Modified sans corps. Economie de bande passante.

Last-Modified fonctionne pareil avec des dates. Moins precis que ETag, mais suffisant pour du contenu statique.

Voir le cache en action

Avec curl, tu peux inspecter les headers de cache de n'importe quel site derrière Cloudflare :

bashcurl -I https://paltemps.fr/

Dans la réponse, cherche le header cf-cache-status. Les valeurs possibles :

  • HIT : servi depuis le cache edge. Le VPS n'a pas ete contacte.
  • MISS : pas dans le cache, requête transmise a l'origin. La prochaine fois, ca sera un HIT.
  • EXPIRED : le contenu etait dans le cache mais le TTL est dépassé. Revalidation en cours.
  • REVALIDATED : le contenu expire a ete revalide auprès de l'origin (304 Not Modified).
  • DYNAMIC : Cloudflare considéré que ce contenu ne doit pas etre cache (HTML par défaut, réponses avec cookies).
  • BYPASS : une regle a dit explicitement de ne pas cacher.

Un test rapide : fais deux curl -I de suite sur une ressource statique. Le premier devrait afficher MISS, le second HIT. Si c'est toujours DYNAMIC, c'est que Cloudflare ne cache pas ce type de contenu par défaut (on verra comment forcer ca dans l'article sur la configuration).

bash# Premier appel
curl -sI https://exemple.fr/style.css | grep cf-cache-status
# cf-cache-status: MISS

# Deuxieme appel
curl -sI https://exemple.fr/style.css | grep cf-cache-status
# cf-cache-status: HIT

Le TTL : combien de temps on garde

Le TTL (Time To Live) definit la duree de vie du contenu dans le cache. Deux TTL coexistent :

Le Browser Cache TTL contrôle combien de temps le navigateur de l'utilisateur garde le contenu localement. Tant que le TTL browser n'est pas expire, le navigateur ne fait meme pas de requête au CDN.

Le Edge Cache TTL contrôle combien de temps le serveur edge garde le contenu. Quand le edge TTL expire, la prochaine requête déclenché un fetch vers l'origin.

En pratique, je mets un edge TTL long (24h ou plus) pour le contenu statique (CSS, JS, images) et un TTL browser plus court (4h). Comme ca, si je deploie une mise à jour, je peux purger le cache edge et les utilisateurs recuperent la nouvelle version en quelques heures max.

L'invalidation de cache

Phil Karlton disait qu'il n'y a que deux problèmes difficiles en informatique : nommer les choses et l'invalidation de cache. Il avait raison.

Tu as déployé une nouvelle version de ton CSS. L'ancienne est dans le cache de 310 data centers Cloudflare. Comment la virer ?

Trois stratégies :

Purge manuelle. Dans le dashboard Cloudflare, tu peux purger tout le cache ou des URLs spécifiques. Ca marche, c'est juste pas automatise.

Cache busting par nom de fichier. Tu ajoutes un hash au nom : style.a3f8b2.css. A chaque build, le hash change, l'URL change, pas besoin de purger. C'est la méthode que je recommande. Webpack, Vite, esbuild le font tous automatiquement.

API de purge. Cloudflare propose une API pour purger par URL, par tag ou par prefix. Tu peux l'appeler depuis ton pipeline CI/CD. Pratique, mais ajoute de la complexité.

Le tiered caching

Par défaut, si un edge a Tokyo a un cache miss, il va directement chercher le contenu a ton origin a Paris. Mais Cloudflare propose du "tiered caching" (via Argo Smart Routing ou le cache tiering gratuit). L'idee : entre le edge et l'origin, il y a un cache regional. Le edge a Tokyo demande d'abord au cache regional en Asie. Si ce regional a le contenu, l'origin n'est jamais contacte.

Le résultat : moins de requêtes vers ton origin, meilleur cache hit ratio global, et une réduction de la latence meme sur les cache miss (le regional est plus proche que l'origin).

Sur le plan gratuit, Cloudflare active le tiered caching de base. Argo Smart Routing (paye, environ $5/mois + frais par Go) va plus loin avec du routage intelligent qui évité les chemins Internet congestionnees.

Prochain article : Configurer Cloudflare devant ton site.

Navigation : Precedent : 00 - Introduction | Suivant : 02 - Configurer Cloudflare

Sources

Retrouve d'autres articles techniques sur paltemps.fr.

Publie le · Mis a jour le

Articles liés

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.

Découvrir Pal'Temps