Was ein CDN mit einer Anfrage tatsächlich macht
Ein Nutzer in Tokio, der eine Seite von einem Server in Virginia lädt, bezahlt für diese Distanz zweimal: einmal für den Hinweg der Anfrage, einmal für den Rückweg der Antwort. Glasfaser überträgt mit einem festen Bruchteil der Lichtgeschwindigkeit, und allein diese Strecke kostet etwa 150-200ms Round-Trip-Zeit, bevor der Origin-Server überhaupt etwas getan hat. Kommen noch eine Datenbankabfrage und ein, zwei langsame Hops dazu, fühlt sich eine Seite, die nebenan sofort lädt, auf der anderen Seite des Planeten träge an.
Ein CDN, ein Content Delivery Network, behebt das für Inhalte, die sich kopieren lassen: Bilder, CSS, JavaScript-Bundles, Videosegmente, manchmal ganze HTML-Seiten. Ein Netzwerk aus Servern nahe den Nutzern hält Kopien dieser Inhalte vor und antwortet direkt, sodass die meisten Anfragen nie den Ozean überqueren. Der Origin-Server bleibt die maßgebliche Quelle. Das CDN sitzt davor und fängt so viele Anfragen ab, wie es aus einer Kopie bedienen kann.
Wie eine Anfrage den passenden PoP findet
Ein CDN-Betreiber unterhält Server an vielen physischen Standorten, meist Points of Presence oder PoPs genannt: Rechenzentren in oder nahe Großstädten, jedes mit einem Ausschnitt der gecachten Inhalte und einem schnellen Weg zurück zum Origin-Server für alles andere. Zwei Mechanismen entscheiden, welcher PoP eine gegebene Anfrage übernimmt, und große CDNs nutzen beide.
DNS-basiertes Routing löst denselben Hostnamen je nach Herkunft der Anfrage zu unterschiedlichen IP-Adressen auf. Eine DNS-Abfrage für assets.example.com von einem Resolver in Frankfurt liefert die IP eines Frankfurter PoP zurück; dieselbe Abfrage aus São Paulo liefert eine völlig andere IP.
Anycast geht weiter. Viele PoPs geben über BGP dieselbe IP-Adresse bekannt, und das gewöhnliche Internet-Routing entscheidet, welcher davon ein bestimmtes Paket tatsächlich erreicht, basierend auf der Netzwerktopologie statt auf Geografie. Das CDN trifft diese Wahl nie selbst. Auch das Failover geht schneller: Fällt ein PoP aus dem Netz, hören Router auf, ihm Traffic zu schicken, ganz ohne DNS-Änderung, die sich erst verbreiten müsste.
| |
So oder so spricht der Client für gecachte Inhalte nie direkt mit dem Origin-Server. Er spricht mit dem PoP, den die Routing-Ebene ausgewählt hat, und dieser PoP hat den Inhalt entweder bereits oder holt ihn einmal und merkt ihn sich. Jeder PoP übernimmt die Aufgabe eines Reverse Proxys vor dem Origin-Server: Er terminiert die Verbindung des Clients und entscheidet, was als Nächstes passiert, mit einem angeschlossenen Cache und tausenden gleichzeitig laufenden Kopien rund um den Globus.
Cache Hit oder Cache Miss: woran Sie das erkennen
Die erste Anfrage für eine URL durch einen bestimmten PoP ist ein Cache Miss. Der PoP hat nichts gespeichert, holt sich den Inhalt also vom Origin-Server, legt eine Kopie gemäß den Regeln der Antwort ab und liefert sie aus. Jede spätere Anfrage für diese URL, von jedem Client, der zum selben PoP geroutet wird, ist ein Cache Hit: ausgeliefert aus dem Speicher des PoP, ohne den Origin-Server einzubeziehen, bis die Kopie abläuft oder gelöscht wird.
Ein Befehl verrät Ihnen, welchen der beiden Sie bekommen haben:
| |
Eine gecachte Antwort trägt einen Vendor-Header, der das Ergebnis benennt. Cloudflare fügt CF-Cache-Status hinzu, mit Werten wie HIT, MISS, EXPIRED (die TTL ist abgelaufen, der PoP hat neu geholt), REVALIDATED (der Origin-Server hat bestätigt, dass die alte Kopie noch gültig war) oder DYNAMIC (das CDN hat entschieden, dass diese Antwort überhaupt nicht cachebar ist). Das Fastly-Äquivalent ist X-Cache: HIT oder X-Cache: MISS. Führen Sie dieselbe Anfrage zweimal gegen eine cachebare URL aus, wechselt die zweite Antwort von MISS auf HIT.
| |
age gibt an, vor wie vielen Sekunden der PoP diese Kopie vom Origin-Server geholt hat. Hier sind das 412 Sekunden innerhalb einer 3600-Sekunden-TTL, die Kopie hat also noch fast eine Stunde, bevor die nächste Anfrage einen neuen Fetch auslöst.
Wie der Cache-Control-Header dem CDN sagt, was es cachen soll
Das CDN rät nicht, was es cachen soll. Der Origin-Server sagt es ihm, über den Cache-Control-Header jeder Antwort.
| Direktive | Was sie bewirkt |
|---|---|
max-age=N | Wie lange irgendein Cache (Browser oder CDN) die Antwort behalten darf, in Sekunden |
s-maxage=N | Wie lange ein Shared Cache (das CDN) sie behalten darf — überschreibt max-age speziell für das CDN, Browser folgen weiterhin max-age |
public | Erlaubt Caching ausdrücklich, auch bei Antworten, die sonst privat wirken würden (z. B. mit einem Authorization-Header) |
private | Nur der Browser darf das cachen; das CDN darf nicht |
no-cache | Caches dürfen speichern, müssen aber vor der erneuten Auslieferung beim Origin-Server revalidieren |
no-store | Nirgends cachen, weder Browser noch CDN |
Bei einem statischen Asset mit gehashtem Dateinamen (app.a3f9c1.css) ist die übliche Einstellung aggressiv: Cache-Control: public, max-age=31536000, immutable. Der Dateiname ändert sich, sobald sich der Inhalt ändert, also ist ein Jahr unbedenklich. Eine veraltete Kopie von app.a3f9c1.css ist ein Widerspruch in sich, weil genau dieser Name immer nur auf eine einzige Version der Datei zeigt.
Für HTML oder eine API-Antwort, die Sie zwar cachen, aber frischer halten wollen, hält Cache-Control: public, s-maxage=60, max-age=0 sie eine Minute lang im CDN, während Browser bei jeder Anfrage revalidieren. Es ist derselbe Short-TTL-Cache-Aside-Reflex, der auch hinter der Funktionsweise von Redis-Caching steckt, nur durchgesetzt über einen HTTP-Header statt über Anwendungscode.
Machen Sie es in die andere Richtung falsch, leckt Ihr Cache Daten. Liefern Sie eine personenbezogene Seite mit Cache-Control: public, max-age=3600 aus und setzen dabei kein Vary auf das Session-Cookie, kann das CDN die gecachte Seite von Nutzer A an Nutzer B ausliefern.
Wie Sie einen veralteten CDN-Cache leeren
Manchmal reicht eine TTL nicht: Sie haben einen Fix ausgeliefert und können nicht eine Stunde warten, bis er alle erreicht. Jedes CDN bietet dafür eine Purge-API oder eine Aktion im Dashboard. Sie teilen ihm mit, dass eine URL, oder eine ganze Zone, jetzt ungültig ist, und die nächste Anfrage wird als Cache Miss behandelt, egal wie viel TTL noch übrig war.
Die günstigere Gewohnheit ist, gar nicht erst purgen zu müssen. Versehen Sie den Dateinamen mit einem Content-Hash oder erhöhen Sie einen Query-String-Parameter, sodass jedes Deployment eine neue URL mit eigenem Cache-Eintrag ist und die veraltete Kopie der alten URL schlicht nicht mehr angefragt wird. Purgen bleibt für das übrig, was sich nicht umgehen lässt: ein Incident, eine rechtliche Takedown-Anforderung, ein durch einen falsch konfigurierten Vary-Header vergifteter Cache.
Wann ein CDN nichts bringt und was es kostet
Personalisierte Antworten sind in keinem sinnvollen Sinn cachebar. Ein Dashboard nach dem Login, eine Warenkorbseite, alles, was an eine Session gebunden ist — die nächste Anfrage will garantiert einen anderen Inhalt. Ein CDN vor solche Endpunkte zu stellen bringt nichts außer dem falschen Gefühl, Caching hinzugefügt zu haben, und riskiert bei falschen Cache-Regeln aktiv, die private Antwort eines Nutzers an einen anderen auszuliefern.
Ein CDN fügt außerdem eine weitere Schicht zum Debuggen hinzu. „Läuft lokal, aber nicht in Produktion" bedeutet manchmal, dass der Code in Ordnung ist und ein PoP eine Antwort ausliefert, die von vor Ihrem Fix gecacht wurde; die Anfrage erreicht den Origin-Server erst, wenn die TTL abläuft oder Sie purgen.
Auch die Form des Traffics zählt. Ein internes Tool oder ein regionaler Dienst ohne internationales Publikum bezahlt für PoPs, die er nie nutzt, und gewinnt Latenz zurück, die er nie hatte. Ein CDN löst zwei konkrete Probleme: die Strecke zu weit entfernten Nutzern und die wiederholte Last auf dem Origin-Server. Ist keines davon Ihr Problem, ist es Infrastruktur ohne Aufgabe.
Wie Sie prüfen, ob bereits ein CDN im Einsatz ist
Führen Sie curl -I gegen ein statisches Asset auf einer Site aus, die Sie selbst betreuen. Trägt die Antwort cache-control, einen age-Header oder einen Vendor-Status wie CF-Cache-Status oder X-Cache, cacht bereits etwas vor Ihrem Origin-Server, ob Sie das bewusst eingerichtet haben oder Ihr Hoster es mitgeliefert hat. Fehlen diese Header bei Assets, die aus mehr als einer Region angefragt werden, ist das der konkrete Grund, eines einzurichten: Cloudflare, AWS CloudFront und Fastly stellen sich in unter einer Stunde kostenlos oder nutzungsbasiert vor eine Domain, ohne dass sich am Origin-Code etwas ändern muss.