Überblick

Zweck

Diese Komponente simuliert einen CDN-Edge-Node für Labor- und Demo-Umgebungen. Sie repräsentiert die Rolle, die Anbieter wie Akamai, Cloudflare, Amazon CloudFront oder Fastly in der Netzwerkarchitektur eines Kunden spielen – die Caching-Schicht, die dem Endbenutzer am nächsten liegt und sich vor einem Ursprungsserver befindet.

In produktiven Multi-Vendor-Architekturen kombinieren Kunden häufig ein CDN eines Drittanbieters mit F5 Distributed Cloud:

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

Dieser Simulator ersetzt das kommerzielle CDN durch einen NGINX-basierten Edge-Node, sodass die Integration demonstriert und getestet werden kann, ohne Anbieterverträge oder Produktionsinfrastruktur zu benötigen.

Architektur

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

Der NGINX-Edge-Node:

Terminiert TLS am Edge (selbstsigniert oder Let’s Encrypt)
Speichert Antworten auf dem Datenträger mittels proxy_cache_path
Leitet Cache-Misses an einen konfigurierbaren Ursprungsserver weiter (den F5 XC HTTP Load Balancer VIP)
Meldet den Cache-Status über den X-Cache-Status-Antwortheader (HIT, MISS, BYPASS, EXPIRED)

Was simuliert wird

CDN-Funktion	NGINX-Implementierung
Edge-Caching	`proxy_cache` mit datenträgerbasiertem Speicher
Cache-Key-Generierung	`proxy_cache_key` basierend auf Schema, Host und URI
Origin-Pull	`proxy_pass` zum F5 XC HTTP Load Balancer
TLS-Terminierung	NGINX-Direktive `ssl_certificate`
Cache-Control-Beachtung	`proxy_cache_valid` mit Weitergabe des Origin-Headers
Cache-Status-Reporting	`add_header X-Cache-Status $upstream_cache_status`
Health-Endpunkt	`/health`-Location mit Rückgabe 200 OK

Endpunkte und Anfrage-/Antwortverhalten

Health-Check

GET /health

Antwort (200 OK, Content-Type: application/json):

{
  "status": "healthy",
  "component": "cdn-edge",
  "engine": "nginx",
  "vendor_profiles": ["akamai", "cloudflare", "cloudfront", "fastly", "azure-front-door"]
}

CDN-Proxy (alle anderen Pfade)

GET /<any-path>

In Richtung Origin injizierte Anfrage-Header (67+ Header von 5 Anbietern):

Kategorie	Hinzugefügte Header
Client-IP	`True-Client-IP`, `CF-Connecting-IP`, `Fastly-Client-IP`, `X-Azure-ClientIP`, `CloudFront-Viewer-Address`, `X-Forwarded-For`, `X-Real-IP`
Geolokalisierung	`X-Akamai-Edgescape` (zusammengesetzt), `CF-IPCountry`, `cf-ipcity`, `cf-iplatitude/longitude`, `CloudFront-Viewer-Country/City/Latitude/Longitude`, `X-Geo-Country-Code/City/Region`
Geräteerkennung	`CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Tablet-Viewer`, `X-Akamai-Device-Characteristics`
TLS/Fingerprint	`CloudFront-Viewer-TLS`, `cf-ja3-hash`, `cf-ja4`, `CloudFront-Viewer-JA3-Fingerprint`
Bot-Erkennung	`cf-bot-score` (85 = wahrscheinlich menschlich), `cf-verified-bot`
Anfrage-Tracing	`Cf-Ray`, `X-Akamai-Request-ID`, `X-Amz-Cf-Id`, `X-Azure-Ref`
Edge-Identität	`X-CDN-Edge`, `X-CDN-POP`, `X-Served-By`, `Fastly-FF`, `X-Azure-FDID`
Standard	`Via`, `Forwarded`, `CDN-Loop`, `X-Forwarded-Proto/Host/Port`

Antwortheader, die jeder weitergereichten Antwort hinzugefügt werden:

Header	Werte	Zweck
`X-Cache-Status`	`HIT`, `MISS`, `BYPASS`, `EXPIRED`, `STALE`	Cache-Verhalten für diese Anfrage
`X-CDN-Edge`	`cdn-simulator`	Identifiziert diesen Edge-Node
`X-CDN-POP`	`SJC`	Simulierter Point of Presence IATA-Code
`X-Served-By`	`cache-sjc3120-SJC`	Simulierter Cache-Node im Fastly-Format
`X-Request-ID`	UUID (pro Anfrage)	Eindeutiger Anfrage-Bezeichner

Cache-Verhalten

Erste Anfrage an einen beliebigen Pfad: X-Cache-Status: MISS (vom Origin abgerufen, jetzt gecacht)
Nachfolgende identische Anfragen: X-Cache-Status: HIT (aus dem Datenträger-Cache bedient)
Cache-Key: $scheme$host$request_uri (Schema + Hostname + vollständiger Pfad + Query-String)
Cache-TTL: 10 Minuten für 200/301/302, 1 Minute für 404
Stale-Bereitstellung: gibt gecachten Inhalt bei Origin-Fehlern zurück (500/502/503/504)

VM-Zugriff

Zugriffsmethode	Befehl/Pfad
SSH	`ssh azureuser@<PUBLIC_IP>`
NGINX-Konfiguration	`/etc/nginx/conf.d/cdn-edge.conf`
NGINX-Logs	`/var/log/nginx/access.log` und `/var/log/nginx/error.log`
Cache-Verzeichnis	`/var/cache/nginx/cdn/`
Cloud-Init-Log	`/var/log/cloud-init-output.log`

Modulares Komponentendesign

Dies ist ein Teil einer größeren Laborumgebung. Jede Komponente ist eigenständig und wird unabhängig bereitgestellt:

Diese Komponente stellt den CDN-Edge bereit (NGINX auf Azure VM)
Andere Komponenten stellen die Origin-Anwendung, die F5 XC-Konfiguration, DNS, WAF-Richtlinien usw. bereit.

Der menschliche Operator fügt Komponenten einzeln hinzu. Die Dokumentation jeder Komponente ist so verfasst, dass ein KI-Assistent sie lesen und die Infrastruktur eigenständig bereitstellen kann.

Warum NGINX

NGINX wurde als CDN-Simulationsengine ausgewählt, weil:

F5-Produkt — F5 hat NGINX Inc. im Jahr 2019 übernommen; es ist Teil des F5-Portfolios
Branchenbewährt — Cloudflare betrieb sein gesamtes CDN über ein Jahrzehnt lang auf NGINX, bevor es zu Pingora migrierte; Netflix verwendet NGINX für sein Open Connect CDN
Einzelprozess — verarbeitet TLS-Terminierung und Caching in einer einzigen Binärdatei, anders als Varnish, das einen separaten TLS-Proxy erfordert
Einfache Bereitstellung — apt install nginx auf Ubuntu 24.04, zwei Direktiven aktivieren das Caching
Gut dokumentiert — umfangreiche offizielle Dokumentation für Content-Caching und Reverse-Proxy-Konfiguration