Aller au contenu

Vue d'ensemble

Ce composant simule un nœud CDN Edge pour les environnements de laboratoire et de démonstration. Il représente le rôle que jouent des fournisseurs tels qu’Akamai, Cloudflare, Amazon CloudFront ou Fastly dans l’architecture réseau d’un client — la couche de mise en cache la plus proche des utilisateurs finaux, placée en amont d’un serveur d’origine.

Dans les architectures multi-fournisseurs en production, les clients associent fréquemment un CDN tiers à F5 Distributed Cloud :

End User → CDN Edge (Akamai/Cloudflare/etc.) → F5 XC HTTP LB → Origin App

Ce simulateur remplace le CDN commercial par un nœud Edge basé sur NGINX, permettant ainsi de démontrer et de tester l’intégration sans contrats fournisseurs ni infrastructure de production.

┌─────────┐ ┌──────────────────────┐ ┌─────────────────┐ ┌────────────┐
│ Client │────▶│ CDN Edge (NGINX) │────▶│ F5 XC HTTP LB │────▶│ Origin App │
│ │ │ Ubuntu 24.04 Azure │ │ (Origin Server) │ │ │
└─────────┘ │ - TLS termination │ └─────────────────┘ └────────────┘
│ - Disk-based cache │
│ - X-Cache-Status │
└──────────────────────┘

Le nœud Edge NGINX :

  • Termine le TLS au niveau de la périphérie (certificat auto-signé ou Let’s Encrypt)
  • Met en cache les réponses sur disque via proxy_cache_path
  • Transfère les défauts de cache vers un serveur d’origine configurable (le VIP du répartiteur de charge HTTP F5 XC)
  • Rapporte l’état du cache via l’en-tête de réponse X-Cache-Status (HIT, MISS, BYPASS, EXPIRED)
Fonction CDNImplémentation NGINX
Mise en cache en périphérieproxy_cache avec stockage sur disque
Génération de clé de cacheproxy_cache_key basée sur le schéma, l’hôte et l’URI
Rapatriement depuis l’origineproxy_pass vers le répartiteur de charge HTTP F5 XC
Terminaison TLSDirective NGINX ssl_certificate
Respect du Cache-Controlproxy_cache_valid avec transmission des en-têtes d’origine
Rapport d’état du cacheadd_header X-Cache-Status $upstream_cache_status
Point de terminaison de santéEmplacement /health retournant 200 OK

Points de terminaison et comportement requête/réponse

Section intitulée « Points de terminaison et comportement requête/réponse »
GET /health

Réponse (200 OK, Content-Type: application/json) :

{
"status": "healthy",
"component": "cdn-edge",
"engine": "nginx",
"vendor_profiles": ["akamai", "cloudflare", "cloudfront", "fastly", "azure-front-door"]
}
GET /<any-path>

En-têtes de requête injectés vers l’origine (67+ en-têtes provenant de 5 fournisseurs) :

CatégorieEn-têtes ajoutés
IP clientTrue-Client-IP, CF-Connecting-IP, Fastly-Client-IP, X-Azure-ClientIP, CloudFront-Viewer-Address, X-Forwarded-For, X-Real-IP
GéolocalisationX-Akamai-Edgescape (composé), CF-IPCountry, cf-ipcity, cf-iplatitude/longitude, CloudFront-Viewer-Country/City/Latitude/Longitude, X-Geo-Country-Code/City/Region
Détection d’appareilCloudFront-Is-Mobile-Viewer, CloudFront-Is-Desktop-Viewer, CloudFront-Is-Tablet-Viewer, X-Akamai-Device-Characteristics
TLS/EmpreinteCloudFront-Viewer-TLS, cf-ja3-hash, cf-ja4, CloudFront-Viewer-JA3-Fingerprint
Détection de botscf-bot-score (85 = probablement humain), cf-verified-bot
Traçage des requêtesCf-Ray, X-Akamai-Request-ID, X-Amz-Cf-Id, X-Azure-Ref
Identité de la périphérieX-CDN-Edge, X-CDN-POP, X-Served-By, Fastly-FF, X-Azure-FDID
StandardVia, Forwarded, CDN-Loop, X-Forwarded-Proto/Host/Port

En-têtes de réponse ajoutés à chaque réponse mandatée :

En-têteValeursObjectif
X-Cache-StatusHIT, MISS, BYPASS, EXPIRED, STALEComportement du cache pour cette requête
X-CDN-Edgecdn-simulatorIdentifie ce nœud Edge
X-CDN-POPSJCCode IATA du point de présence simulé
X-Served-Bycache-sjc3120-SJCNœud de cache simulé au format Fastly
X-Request-IDUUID (par requête)Identifiant unique de la requête
  • Première requête vers un chemin quelconque : X-Cache-Status: MISS (récupéré depuis l’origine, désormais mis en cache)
  • Requêtes identiques suivantes : X-Cache-Status: HIT (servi depuis le cache disque)
  • Clé de cache : $scheme$host$request_uri (schéma + nom d’hôte + chemin complet + chaîne de requête)
  • TTL du cache : 10 minutes pour les codes 200/301/302, 1 minute pour les codes 404
  • Service depuis le cache périmé : retourne le contenu mis en cache en cas d’erreurs d’origine (500/502/503/504)
Méthode d’accèsCommande/Chemin
SSHssh azureuser@<PUBLIC_IP>
Configuration NGINX/etc/nginx/conf.d/cdn-edge.conf
Journaux NGINX/var/log/nginx/access.log et /var/log/nginx/error.log
Répertoire de cache/var/cache/nginx/cdn/
Journal cloud-init/var/log/cloud-init-output.log

Il s’agit d’un élément d’un environnement de laboratoire plus vaste. Chaque composant est autonome et déployé indépendamment :

  • Ce composant fournit la périphérie CDN (NGINX sur une VM Azure)
  • Les autres composants fournissent l’application d’origine, la configuration F5 XC, le DNS, les politiques WAF, etc.

L’opérateur humain ajoute les composants un par un. La documentation de chaque composant est rédigée de façon à ce qu’un assistant IA puisse la lire et déployer l’infrastructure de manière autonome.

NGINX a été sélectionné comme moteur de simulation CDN pour les raisons suivantes :

  1. Produit F5 — F5 a acquis NGINX Inc. en 2019 ; il fait partie du portefeuille F5
  2. Éprouvé dans l’industrie — Cloudflare a fait fonctionner l’intégralité de son CDN sur NGINX pendant plus d’une décennie avant de migrer vers Pingora ; Netflix utilise NGINX pour son CDN Open Connect
  3. Processus unique — gère la terminaison TLS et la mise en cache dans un seul binaire, contrairement à Varnish qui nécessite un proxy TLS séparé
  4. Déploiement simpleapt install nginx sur Ubuntu 24.04, deux directives suffisent pour activer la mise en cache
  5. Bien documenté — documentation officielle exhaustive pour la mise en cache de contenu et la configuration de proxy inverse