Was ist ein CDN und wie Cloudflare zu einem führenden Anbieter wurde

Was ein CDN ist

Ein Content Delivery Network ist eine verteilte Gruppe von Servern, die Inhalte über Standorte ausliefert, die näher bei den Nutzern liegen als der Origin-Server der Anwendung. Der Origin bleibt die maßgebliche Quelle. CDN-Server am Netzwerkrand speichern wiederverwendbare Antworten, nehmen Verbindungen entgegen und leiten Anfragen weiter, die die Anwendung benötigen.

Diese Edge-Server sind in Points of Presence organisiert, oft PoPs genannt. Ein PoP kann aus vielen Maschinen bestehen und direkt mit lokalen Internetanbietern, Mobilfunkanbietern, Cloud-Netzwerken und weiteren Transitnetzen verbunden sein. Das CDN leitet Besucher normalerweise anhand der Netzbedingungen zu einem passenden PoP, nicht allein anhand der kürzesten geografischen Entfernung.

Ohne CDN erreicht jede Anfrage den Origin oder dessen Load Balancer. Ein Besucher in der Nähe des Origins erhält möglicherweise schnell eine Antwort. Wer sich auf einem anderen Kontinent befindet, muss mehr Netzwerke durchqueren, und jeder Verbindungsaufbau oder Umlauf zur Anwendung fügt Verzögerung hinzu. Selbst schnelle Server können die Zeit nicht beseitigen, die Signale über große Entfernungen benötigen.

Angenommen, eine Anwendung braucht drei aufeinanderfolgende Austausche, bevor sie nützliche Inhalte darstellen kann. Bei einer Round-Trip-Zeit von 90 Millisekunden verursachen diese Austausche rund 270 Millisekunden, noch vor Übertragung und Verarbeitung. Verlegt man den Verbindungspunkt an einen Edge-Standort mit 20 Millisekunden Round-Trip-Zeit, spart diese Abfolge rund 210 Millisekunden. Das genaue Ergebnis hängt von Routing, Auslastung, Wiederverwendung von Protokollen und davon ab, ob die angeforderte Antwort bereits gecacht ist.

Ein CDN ist keine Sammlung vollständiger Miniatur-Websites. An einem bestimmten Edge kann ein beliebtes Bild liegen, während ein anderer Edge keine Kopie besitzt. Es kann ein öffentliches Dokument eine Stunde lang cachen, aber jede authentifizierte API-Anfrage weiterleiten. Der Cache wird anhand von Anfrageattributen, Antwort-Headern, konfigurierten Regeln und verfügbarer Kapazität gefüllt und aktualisiert.

Ein CDN ist auch etwas anderes als Webhosting. Hosting führt die Quellanwendung aus, speichert maßgebliche Daten und erzeugt Antworten. Das CDN arbeitet als Reverse Proxy vor dieser Infrastruktur. Einige Anbieter bieten inzwischen Edge-Computing und Speicher an, sodass Teile einer Anwendung in ihren Netzwerken laufen können. Dadurch wandern Datenbank und übriges Backend jedoch nicht automatisch mit.

Dieser Unterschied erklärt das zentrale Versprechen: Ein CDN verringert vermeidbare Entfernung und wiederholte Arbeit am Origin. Es kann ineffizienten Anwendungscode nicht beschleunigen, langsame Datenbankabfragen nicht reparieren und einen überlasteten Origin nicht entlasten, wenn Anfragen nicht gecacht werden können.

Wie ein CDN jede Anfrage verarbeitet

Ein CDN verarbeitet eine Anfrage, indem es die Verbindung des Nutzers an einem Edge-Standort annimmt, prüft, ob dort eine gültige Antwort erzeugt werden kann, und den Origin nur bei Bedarf kontaktiert. DNS- und Anycast-Routing leiten den Traffic meist in das Netzwerk des Anbieters, bevor Caching-Entscheidungen fallen.

Eine typische Anfrage durchläuft fünf Schritte:

1. DNS liefert eine Adresse zurück, die dem CDN zugeordnet ist, statt den Origin direkt offenzulegen.
2. Das Netzwerk leitet die Verbindung zu einem verfügbaren Edge-Standort, an dem das CDN TLS und das HTTP-Protokoll aushandelt.
3. Der Edge berechnet aus Merkmalen wie Schema, Host, Anfrageziel, Abfrageparametern und ausgewählten Headern einen Cache-Schlüssel.
4. Ein frischer Treffer führt zu einem Cache Hit. Bei Miss, Bypass oder abgelaufenem Eintrag kontaktiert der Edge eine höhere Cache-Ebene oder den Origin.
5. Das CDN sendet die Antwort an den Nutzer und kann eine geeignete Kopie für spätere Anfragen speichern.

Anycast ermöglicht vielen Einrichtungen, dieselben Adressbereiche anzukündigen. Das Internet-Routing trägt die Verbindung dann zu einer erreichbaren Ankündigung. Dadurch gelangen Nutzer meist zu einer nahen Einrichtung, obwohl Routing-Richtlinien und Peering dazu führen können, dass eine andere Einrichtung besser arbeitet als die geografisch nächstgelegene.

Die Aktualität des Caches wird hauptsächlich durch HTTP-Antwort-Header und CDN-Regeln bestimmt. Ein Origin könnte Folgendes zurückgeben:

Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=60
ETag: "build-4821"

In diesem Beispiel darf ein Browser die Antwort fünf Minuten lang wiederverwenden, während ein gemeinsam genutzter Cache sie eine Stunde lang als frisch ansehen kann. Während des angegebenen Revalidierungsfensters kann ein kompatibler Cache eine veraltete Kopie zurückgeben, während er auf eine aktualisierte Version prüft. Der ETag ermöglicht eine bedingte Validierung. So muss die vollständige Antwort nicht übertragen werden, wenn sich der Inhalt nicht geändert hat.

Die Time to Live ist nur ein Teil der Entscheidung. Antworten mit private oder no-store sollten nicht in einen gemeinsam genutzten Cache gelangen. Auch Anfragen mit Autorisierungsdaten und Antworten, die Session-Cookies setzen, brauchen eine bewusste Behandlung. Werden personalisierte HTML-Seiten unter einer gemeinsamen Kennung gecacht, kann ein Nutzer die Inhalte eines anderen sehen.

Der Cache-Schlüssel bestimmt, welche Anfragen dieselbe gespeicherte Antwort wiederverwenden dürfen. Wer jeden Tracking-Parameter einbezieht, erzeugt viele Kopien gleicher Inhalte und senkt die Trefferrate. Wer einen Parameter ignoriert, der die Antwort verändert, kann falsche Inhalte zurückgeben. Sprache, Gerätetyp, Mandantenkennung, ausgewählte Cookies und Komprimierungsunterstützung gehören nur dann in die Kennung, wenn sie beeinflussen, was der Server sendet.

Purge entfernt gespeicherte Kopien vor ihrem normalen Ablauf. Das hilft bei dringenden Korrekturen, doch häufige globale Purges verwerfen aufgewärmte Cache-Einträge und erhöhen die Last auf dem Origin. Versionsbasierte Asset-Namen sind für Deployments sicherer: Neues HTML verweist auf einen neuen Asset-Namen, während alte unveränderliche Dateien gecacht bleiben können, bis kein Client sie mehr anfordert.

Ein Cache Miss ist kein Fehler. Er tritt bei neuen, abgelaufenen, seltenen oder absichtlich nicht cachebaren Inhalten ganz normal auf. Eine gute CDN-Konfiguration zielt darauf, sichere und wertvolle Antworten zu cachen, nicht jede Anfrage zwanghaft zu speichern.

Was ein CDN verbessert und was es nicht lösen kann

Ein CDN verbessert Auslieferungszeit, Effizienz des Origins, Ausfallsicherheit und Schutz am Netzwerkrand, wenn seine Konfiguration zur Anwendung passt. Wie groß der Gewinn ist, hängt vom Standort der Nutzer, der Wiederverwendung von Inhalten, der Cache-Richtlinie und der Arbeit ab, die weiterhin das Backend erreicht.

Am deutlichsten sinkt die Verbindungs-Latenz. Die TLS-Aushandlung findet nahe beim Besucher statt, wiederverwendbare Inhalte vermeiden einen Umlauf zum Origin und dauerhafte Verbindungen verringern wiederholten Einrichtungsaufwand. Moderne Protokolle können zudem in Mobilfunknetzen mit Paketverlusten oder wechselnder Verbindung besser funktionieren. Das kann die Zeit bis zum ersten Byte reduzieren und Kennzahlen zur Seitenerfahrung verbessern. Render-blockierende Skripte, übergroße Client-Bundles, Layout-Verschiebungen oder langsame Browserausführung verschwinden dadurch nicht.

Die Entlastung des Origins kann Infrastruktur- und Datenübertragungskosten senken. Nehmen wir einen Dienst, der jeden Monat 8 TB cachebarer Dateien vom Origin aus sendet. Liefert das CDN 92 Prozent dieser Bytes aus dem Edge-Speicher, entfallen auf gewöhnliche Misses rund 640 GB Origin-Transfer, bevor Revalidierungs-Traffic und Betriebsaufwand hinzukommen. Das finanzielle Ergebnis hängt von Egress-Preisen des Hosting-Anbieters, dem CDN-Tarif, Gebühren pro Anfrage, Transformationsgebühren und kostenpflichtigen Routing-Funktionen ab.

Ein verteiltes Netzwerk kann einen plötzlichen Besucheransturm aufnehmen, ohne jede wiederholte Dateianfrage an einen Server zu schicken. Es kann Nutzer auch von einer fehlerhaften Edge-Einrichtung weglenken. Ist Origin-Failover konfiguriert, kann berechtigter Traffic an ein Backup-Backend gehen. Das garantiert keine Verfügbarkeit, wenn die Datenbank ausfällt, beide Origins dieselbe Abhängigkeit nutzen oder jede Anfrage Live-Arbeit der Anwendung erfordert.

Der Reverse Proxy schafft eine Sicherheitsgrenze. Er kann volumetrischen Angriffstraffic verwerfen, Firewall- und Rate-Regeln durchsetzen und die Origin-Adresse aus normalen DNS-Antworten heraushalten. Diese Grenze wird wirkungslos, wenn alte DNS-Einträge, E-Mail-Header, direkte Hostnamen oder Drittanbieterdienste den Origin offenlegen und seine Firewall weiterhin beliebigen Internet-Traffic akzeptiert.

Für die Anwendungssicherheit bleibt der Betreiber verantwortlich. Ein CDN kann fehlerhafte Autorisierung, unsicheren Datenzugriff, offengelegte Geheimnisse, verwundbare Abhängigkeiten oder Missbrauch der Geschäftslogik nicht selbst beheben. Verwaltete Firewall-Regeln reduzieren häufigen Angriffstraffic, müssen aber überwacht und angepasst werden, damit weder Fehlalarme entstehen noch anwendungsspezifische Bedrohungen übersehen werden.

Manche Workloads profitieren kaum. Eine private Anwendung, die in derselben Einrichtung wie ihr Origin genutzt wird, hat bereits geringe Netzwerklatenz. Eine für jede Anfrage einzigartige Antwort gewinnt wenig durch gemeinsames Caching. Große Uploads können weiter Origin-Kapazität verbrauchen, und ein Edge-Proxy schafft eine weitere Stelle, an der Timeout-, Body-Größen- oder Header-Grenzen verstanden werden müssen.

Entscheidend ist, ob das CDN mehr Verzögerung, Datenübertragung und Risiko vermeidet, als es an Gebühren und betrieblicher Komplexität hinzufügt. Miss das mit echtem Traffic, statt anzunehmen, dass jedes verteilte Netzwerk jede Anwendung verbessert.

Wo CDNs in modernen Anwendungen passen

CDNs passen überall dort, wo viele Nutzer wiederverwendbare Inhalte anfordern oder von einem nahen Verbindungspunkt profitieren. Statische Websites sind der einfachste Fall, doch auch Software-Downloads, APIs, Medienauslieferung, SaaS-Anwendungen, mobile Clients und vernetzte Geräte nutzen Edge-Netzwerke auf unterschiedliche Weise.

Häufige Einsatzmuster sind:

• Assets statischer Websites: Cache Bilder, Schriften, Stylesheets, Skripte, Dokumente und andere öffentliche Dateien mit langen Gültigkeitszeiten und versionsbasierten Namen.
• Oberflächen von Webanwendungen: Liefere das anfängliche HTML und das Frontend-Bundle am Edge aus und rufe Kontodaten danach von authentifizierten Diensten ab.
• APIs: Beende TLS nahe bei Clients, nutze Upstream-Verbindungen wieder, drossele missbräuchliche Aufrufer und cache nur ausdrücklich öffentliche oder sicher getrennte Antworten.
• Videos und große Dateien: Speichere beliebte Segmente oder Downloads nahe bei Zuschauern, damit ein Start oder Live-Event die Quelle nicht überlastet.
• Mobile- und Geräteverteilung: Liefere signierte Anwendungspakete, Firmware, Karten und Medien effizient aus, ohne die Update-Prüfung zu verlieren.

Dynamischer Traffic braucht mehr Sorgfalt als statische Dateien. GET- und HEAD-Antworten können cachebar sein, wenn sie öffentliche Daten enthalten und klare Aktualitätsregeln definieren. Ändernde Anfragen sollten normalerweise die Anwendung erreichen. Authentifizierte Antworten sollten den gemeinsamen Speicher umgehen, außer das Design trennt Einträge absichtlich und belegt, dass Identitäten nicht kollidieren können.

GraphQL und ähnliche API-Stile erschweren pauschales Caching, weil ein Endpunkt viele unterschiedliche Antworten erzeugen kann. Persistente Operationen, normalisierte Anfrage-Bodys, von der Anwendung erzeugte Surrogatkennungen oder ein spezieller API-Cache können helfen, aber erst wenn Autorisierung und Invalidierung klar sind.

Streaming basiert auf kleinen Mediensegmenten und Varianten mit adaptiver Bitrate statt auf einer riesigen Videoübertragung. Beliebte Segmente werden bei einem Event oft wiederverwendet. Seltene Aufzeichnungen benötigen möglicherweise eine höhere Cache-Ebene oder persistenten CDN-Speicher, damit sie nicht wiederholt von der Quelle abgerufen werden. Rechteverwaltung, signierter Zugriff, geografische Einschränkungen und das Verhalten des Players bleiben eigene Designfragen.

SaaS-Produkte mit mehreren Regionen nutzen oft ein CDN für die Anwendungsoberfläche und öffentliche Ressourcen, während ein Traffic-Manager für Live-Daten eine Anwendungsregion auswählt. Der Edge kann Verbindungskosten senken, aber keine Datenbankentfernung beseitigen, wenn ein Nutzer in einer Region Daten abfragen muss, die anderswo liegen. Datenplatzierung und Konsistenz bestimmen weiterhin einen großen Teil der interaktiven Latenz.

Für ein Koder.ai-Projekt bietet sich eine klare Aufteilung an: Cache das öffentliche React-Bundle, Schriften und Medien, während Go-Dienste weiter Anfragen autorisieren und PostgreSQL hinter der Anwendungsschicht bleibt. Flutter-Anwendungspakete lassen sich über ein CDN ausliefern, wenn Release-Signierung und Update-Kontrollen erhalten bleiben. Wenn Cloudflare vor einer Koder.ai-Custom-Domain eingesetzt wird, bestätige die nötige DNS-Konfiguration mit dem Hosting-Setup und teste sie, bevor du Produktions-Traffic umstellst. Der Quellcode-Export gibt Teams außerdem die Möglichkeit, dasselbe Muster nach dem Deployment auf selbst verwalteter Infrastruktur anzuwenden.

Caching wirkt am besten, wenn Anwendungsentwickler die Semantik der Antworten festlegen. Der CDN-Betreiber sollte nicht erraten müssen, ob eine Antwort öffentlich ist, wie lange sie gültig bleibt oder welche Anfrageattribute sie verändern.

Wie man CDN-Anbieter misst

Ein CDN-Anbieter sollte anhand der Standorte, Traffic-Arten, Zuverlässigkeitsziele, Sicherheitsanforderungen und des Betriebsmodells der Anwendung bewertet werden. Kein einzelner Benchmark bestimmt einen universellen Marktführer, denn Anbieter unterscheiden sich je nach Region, Carrier, Protokoll, Cache-Zustand und Funktionskonfiguration.

Ein sinnvoller Vergleich umfasst fünf Bereiche:

• Reichweite und Zusammenschaltung: Prüfe Einrichtungen nahe bei den tatsächlichen Nutzern, Peering mit ihren Netzwerken, die Verbindung zum Origin und die Unterstützung der benötigten Länder.
• Performance: Miss Zeit bis zum ersten Byte, Downloadzeit, Cache-Verhalten, Verbindungsfehler und Seitenerfahrung in mehreren Perzentilen.
• Zuverlässigkeit: Prüfe Servicezusagen, Vorfallhistorie, Traffic-Steuerung, Origin-Failover, Verhalten der Steuerungsebene und Reaktionszeit des Supports.
• Sicherheit und Compliance: Vergleiche DDoS-Abdeckung, Firewall-Kontrollen, Bot- und Rate-Tools, Logging, Zertifikatsverwaltung, Datenstandort und Audit-Anforderungen.
• Betrieb und Kosten: Berücksichtige Konfiguration, Automatisierung, Beobachtbarkeit, Support, Migrationsaufwand, Zusatzoptionen, Anfragegebühren und Origin-Egress.

Die Zahl der Einrichtungen allein ist ein schwaches Maß für Performance. Ein Anbieter kann in einer Stadt vertreten sein, ohne gut mit dem Carrier deiner Kunden verbunden zu sein. Ein anderer hat möglicherweise weniger Einrichtungen, aber bessere Routen in die wichtigen Netzwerke. Auch der Standort, der eine Anfrage bedient, kann sich bei Überlastung oder Wartung ändern.

Nutze sowohl synthetische Tests als auch Real-User-Monitoring. Synthetische Systeme wie Catchpoint, ThousandEyes und WebPageTest liefern wiederholbare Tests aus kontrollierten Standorten. Browsermessungen zeigen Geräte, Carrier, Funkbedingungen und Seitenverhalten echter Besucher. SpeedCurve und eigene Browser-Telemetrie können diese Informationen erfassen. Verbreitungsberichte von W3Techs oder BuiltWith zeigen, wie häufig ein Anbieter verwendet wird, sind aber kein Geschwindigkeitstest.

Führe die Bewertung als kontrollierten Test durch:

1. Erfasse eine Origin-only-Basislinie nach Region, Geräteklasse, Inhaltstyp und Traffic-Zeitraum.
2. Konfiguriere für jeden Kandidaten vergleichbare Cache-, TLS-, Komprimierungs- und Sicherheitsrichtlinien.
3. Teste kalte Misses, warme Hits, Revalidierung, dynamische Antworten, große Objekte und Uploads getrennt.
4. Simuliere einen fehlerhaften Origin und einen plötzlichen Traffic-Anstieg, ohne Produktionsdaten zu gefährden.
5. Vergleiche die gemessenen Gewinne mit der vollständigen Monatsrechnung und der Engineering-Zeit für den Betrieb jeder Option.

Die mittlere Latenz verschleiert Nutzer mit der schlechtesten Erfahrung. Verfolge p50, p75, p95 und p99, wenn die Stichprobengröße es zulässt. Trenne Edge-Zeit von Origin-Zeit, damit ein langsames Backend nicht dem CDN zugeschrieben wird. Vergleiche erste Besuche mit wiederholten Besuchen und unterscheide cachebare Bytes von Anfragezahlen.

Auch die Cache-Trefferrate braucht zwei Perspektiven. Die Anfrage-Trefferrate zeigt, wie oft der Edge ohne Origin antwortet. Die Byte-Trefferrate zeigt, wie viel Übertragung der Edge übernimmt. Einige große Videos können eine hohe Byte-Rate erzeugen, während Tausende kleiner API-Anfragen weiter das Backend erreichen.

Zur Zuverlässigkeitsmessung gehören Edge-Fehler, Origin-Fehler, DNS-Fehler, TLS-Fehler, Timeouts und erfolgreiches Failover. Eine nominelle Verfügbarkeitsquote sagt wenig aus, wenn das Dashboard während eines Vorfalls nicht erreichbar ist oder Konfigurationsänderungen zu langsam verteilt werden.

Sicherheitsvergleiche brauchen workload-spezifische Tests. Stelle sicher, dass legitime Clients Rate Limits überstehen, verwaltete Regeln keine echten Käufe oder API-Aufrufe blockieren, Logs genug Belege für Untersuchungen liefern und der direkte Zugriff auf den Origin geschlossen ist. Compliance-Zertifizierungen zählen nur, wenn der vertraglich vereinbarte Dienst und der konfigurierte Datenfluss in ihren Geltungsbereich fallen.

So bekommt das Wort «führend» eine praktische Bedeutung. Der führende Anbieter für eine bestimmte Anwendung ist derjenige, der ihre gemessenen Ziele bei akzeptablen Kosten und Betriebsrisiken erfüllt.

Warum Cloudflare als führender Anbieter gilt

Cloudflare gilt als führender CDN-Anbieter, weil es große Netzreichweite, hohe Verbreitung, leicht zugängliche Einstiegstarife, Sicherheitsdienste und programmierbare Anwendungsauslieferung in einem Netzwerk verbindet. Seine Stellung beruht auf dieser Kombination, nicht auf einem nachweisbaren ersten Platz für jeden Workload.

Cloudflare startete 2010 mit einem Dienst, der unerwünschten Traffic filterte und die Auslieferung von Websites verbesserte. Caching und DDoS-Abwehr nutzten dieselbe Reverse-Proxy-Architektur. Kunden konnten dadurch Performance und Schutz erhalten, ohne Appliances am Origin zu installieren. Später baute das Unternehmen das Netzwerk um DNS, Anwendungssicherheit, privaten Zugriff, Entwickler-Computing, Speicher- und Mediendienste aus.

Sein Netzwerk erreicht mehr als 330 Städte in über 125 Ländern und ist mit mehr als 13.000 weiteren Netzwerken verbunden. Diese Breite verschafft Cloudflare viele Möglichkeiten, Traffic nahe bei Zugangsnetzbetreibern auszutauschen. Anycast erlaubt, dieselben kundenorientierten Dienstadressen über diese Einrichtungen hinweg zu betreiben, ohne für jede Region eigene öffentliche Endpunkte anzulegen.

Die Zugänglichkeit trug zur Verbreitung bei. Eine kleine Website kann mit einem kostenlosen Tarif starten, während größere Unternehmen kostenpflichtige Kontrollen, Support, vertragliche Zusagen und spezialisierte Netzwerkdienste kaufen können. Dashboard und APIs bündeln DNS, Proxying, Zertifikate, Caching, Traffic-Regeln und Sicherheitsrichtlinien in einem Betriebsmodell.

Das gemeinsame Netzwerk ermöglicht außerdem, dass eine Anfrage an einem Edge mehrere Funktionen durchläuft. Cloudflare kann TLS beenden, Sicherheitsrichtlinien prüfen, den Cache abfragen und Anwendungslogik ausführen, ohne für jeden Schritt durch unabhängige Anbieter-Netzwerke zu routen. Diese Bündelung kann Integrationsaufwand senken, erhöht aber auch die Abhängigkeit von der Konfiguration und Verfügbarkeit eines Anbieters.

Cloudflare ohne definierte Messgröße als weltweit führendes CDN zu bezeichnen, würde die Belege überdehnen. Akamai kann für einige große Medien- und Enterprise-Auslieferungsprogramme besser passen. CloudFront ist oft die naheliegende Wahl für Anwendungen, die eng an AWS gebunden sind. Fastly bietet erfahrenen Teams detaillierte Kontrolle über die Auslieferung. Regionale Anbieter können globale Anbieter bei einem konzentrierten lokalen Publikum übertreffen.

Cloudflare gehört zur führenden Gruppe, weil es in vielen Bewertungskategorien überzeugend ist und Organisationen sehr unterschiedlicher Größe nutzen können. Die endgültige Entscheidung braucht dennoch Workload-Tests, Vertragsprüfung und einen klaren Plan für den Ausfall des Anbieters.

Wie Cloudflare-Caching heute funktioniert

Cloudflare cached geeignete statische Ressourcen auf proxied DNS-Einträgen automatisch. HTML-, JSON- und personalisierte Anwendungsantworten benötigen eine ausdrückliche Richtlinie. Teams sollten für neue Konfigurationen Cache Rules nutzen und Origin-Header als Teil des Anwendungsvertrags behandeln.

Ein als proxied markierter DNS-Eintrag leitet kompatiblen Web-Traffic durch Cloudflare. Ein DNS-only-Eintrag löst direkt zum konfigurierten Origin auf und erhält für diesen Eintrag weder CDN-Caching noch HTTP-DDoS-Filterung oder Edge-Firewall-Verarbeitung. Dieser Unterschied ist leicht zu übersehen, wenn manche Hostnamen Proxy-Status anzeigen und andere nicht.

Das Standard-Cache-Verhalten von Cloudflare berücksichtigt Faktoren wie Methode, Dateiendung, Statuscode, Query-String, Antwort-Header, Cookies und Autorisierung. Statische Dateitypen sind normalerweise geeignet. HTML und JSON werden standardmäßig nicht gecacht. Antworten mit einschränkenden Cache-Direktiven, einem Set-Cookie-Header oder bestimmte authentifizierte Anfragen umgehen den Speicher häufig.

Cache Rules können Eignung, Edge- und Browser-Gültigkeit, Cache-Kennungen, Behandlung von Abfrageparametern und Verhalten nach Antwortstatus verändern. Moderne Regeln sind stapelbar. Mehr als eine Regel kann auf eine Anfrage zutreffen, und eine spätere widersprüchliche Einstellung kann gewinnen. Das unterscheidet sich von älteren Page Rules. Bestehende Page Rules brauchen weiterhin eine sorgfältige Migration, neue Designs sollten jedoch die eigenen Regelprodukte für Caching, Weiterleitungen, Origin-Auswahl und Konfiguration verwenden.

Tiered Cache verringert die Zahl der Edge-Einrichtungen, die einen Origin kontaktieren. Wenn eine untere Ebene keinen Treffer hat, prüft sie eine obere Ebene, bevor sie das Objekt von der Quelle anfordert. Cloudflare enthält Tiered Cache und seine intelligente Topologie in den Standardtarifen, während globale, regionale und benutzerdefinierte Topologien eingeschränkter verfügbar sind. Wenn Misses über ausgewählte obere Ebenen gebündelt werden, kann das die Wiederverwendung verbessern und gleichzeitige Origin-Verbindungen verringern.

Cache Reserve ergänzt die normale Cache-Hierarchie um persistenten Speicher. Es ist eine kostenpflichtige, nutzungsbasierte Option für cachebare Objekte mit längeren Gültigkeitszeiten. Gespeicherte Objekte werden entsprechend ihrer Cache-Richtlinie trotzdem veraltet und müssen eventuell am Origin revalidiert werden. Aufbewahrung und Aktualität sind getrennt: Die Aufbewahrung bestimmt, ob eine gespeicherte Kopie verfügbar bleibt, die Aktualität bestimmt, ob Cloudflare sie ohne Prüfung der Quelle senden darf.

Argo Smart Routing ist eine separate kostenpflichtige Funktion, die Netzbeobachtungen nutzt, um bessere Wege für Traffic auszuwählen, der im Cloudflare-Netzwerk zum Origin gelangen muss. Das kann dynamischen Anfragen und Misses helfen, ersetzt aber nicht die Optimierung langsamer Anwendungsverarbeitung.

HTTP/3 steht für Besucherverbindungen zu Cloudflare in Standardtarifen zur Verfügung, wenn ein Edge-Zertifikat aktiv ist. Diese Einstellung erzeugt keine HTTP/3-Verbindung von Cloudflare zum Origin. Teams sollten die Protokollergebnisse in Mobilfunknetzen testen, statt einen aktivierten Schalter als Beweis für eine Verbesserung zu behandeln.

TLS besteht aus zwei Verbindungen: Besucher zu Cloudflare und Cloudflare zu Origin. Der Modus Full strict prüft, ob der Origin ein gültiges, nicht abgelaufenes Zertifikat für den angeforderten Hostnamen vorlegt. Flexible Verschlüsselung lässt das Segment zwischen Edge und Origin unverschlüsselt und sollte bei einer Produktionsanwendung, deren Origin HTTPS unterstützt, nicht verwendet werden.

Eine sichere Cache-Richtlinie folgt fünf Regeln:

• Cache öffentliche, wiederverwendbare Antworten und umgehe kontospezifische Inhalte standardmäßig.
• Gib versionsbasierten Assets lange Gültigkeitszeiten und Dokumenten kürzere Zeiten, die zum Veröffentlichungsbedarf passen.
• Entferne irrelevante Tracking-Parameter erst, nachdem du belegt hast, dass sie die Antwort nicht ändern.
• Teste Cookies, Autorisierung, Sprache, Gerät und Mandantenverhalten, bevor du den Cache-Schlüssel änderst.
• Purge bei Korrekturen gezielt und beobachte die dadurch entstehende Origin-Last.

Eine hohe Trefferrate ist nicht das einzige Ziel. Korrektheit, Datenschutz, Aktualität und vorhersehbare Invalidierung stehen an erster Stelle.

Was Cloudflare zusätzlich zum Caching bietet

Cloudflare ergänzt sein CDN um Anwendungssicherheit, Origin-Schutz, Edge-Computing, Medienverarbeitung und Dienste für privaten Zugriff. Diese Produkte teilen Infrastruktur und Verwaltung, unterscheiden sich aber bei Grenzen, Abrechnungsmodellen und Tarifverfügbarkeit.

Die wichtigsten Dienstgruppen sind:

• Anwendungssicherheit: DDoS-Abwehr, verwaltete und benutzerdefinierte Firewall-Regeln, Rate Limiting, Bot-Kontrollen, API-Schutz und Zertifikatsdienste.
• Origin-Schutz: Proxied-Adressierung, Netzwerk-Allowlists, Authenticated Origin Pulls, Health Checks, Load Balancing und ausgehende Cloudflare-Tunnel-Verbindungen.
• Entwicklerplattform: Workers-Computing plus Speicher- und Messaging-Produkte wie KV, D1, Durable Objects, R2 und Queues.
• Mediendienste: Bildspeicherung und Transformationen, automatische Formatauswahl, Video-Ingestion, Encoding, Speicherung und adaptive Auslieferung.
• Private Konnektivität: Zero-Trust-Zugriff, Secure-Web-Gateway-Funktionen und Netzwerkdienste für Mitarbeitende, Büros und Infrastruktur.

DDoS-Schutz ist in den Standard-CDN-Tarifen enthalten, während Kapazität für Firewall-Regeln, verwaltete Schutzmaßnahmen, Bot-Funktionen, Analyseaufbewahrung und Support-Stufen variieren. Rate Limits müssen missbräuchliche Automatisierung von legitimen Spitzen unterscheiden, etwa beim App-Start, Checkout, bei Webhooks oder Wiederholungsversuchen mobiler Clients.

Das Proxying eines Eintrags verbirgt die Origin-Adresse vor gewöhnlichen Besuchern, löscht aber keine Informationen, die bereits anderswo veröffentlicht wurden. Beschränke nach der Traffic-Prüfung die Origin-Firewall auf erlaubte Quellen. Authenticated Origin Pulls ergänzen eine zertifikatsbasierte Prüfung, dass eine Anfrage über Cloudflare kam. Cloudflare Tunnel kann eine öffentlich routbare Origin-Adresse überflüssig machen, indem er ausgehende Verbindungen aufbaut, sofern sein Betriebsmodell zum Dienst passt.

Workers führen Code zur Behandlung von Anfragen im Cloudflare-Netzwerk mit schlanken V8-Isolates aus. Sie können Weiterleitungen, Autorisierungsprüfungen, Experimente, Personalisierung, API-Komposition oder vollständige Anwendungsfunktionen übernehmen. Code darf nicht voraussetzen, dass veränderlicher Speicher zwischen Anfragen erhalten bleibt oder zwei Anfragen dasselbe Isolate erreichen. Zustandsbehaftete Koordination gehört in einen geeigneten Speicherdienst.

Cloudflare Images kann externe Bilder am Edge transformieren oder Quellbilder in einem kostenpflichtigen Tarif speichern. Der kostenlose Images-Tarif enthält ein monatliches Kontingent eindeutiger Transformationen, während höheres Transformationsvolumen und die Auslieferung gehosteter Bilder getrennt abgerechnet werden. Jede Kombination aus Quelle und Transformation beeinflusst die Nutzung. Unkontrollierte Größen oder Qualitätswerte können daher unnötige Varianten erzeugen.

Cloudflare Stream übernimmt die Ingestion, Speicherung, Encodierung und adaptive Auslieferung von Live- und On-Demand-Videos. Es ist ein eigener Dienst, nicht die kostenlose Folge des Aktivierens eines CDN. Prüfe Zugriffskontrollen, Wiedergabeminuten, Speicherdauer, Rechte an Quellen und unterstützte Encoding-Ausgaben, bevor du einen bestehenden Video-Workflow ersetzt.

Zero-Trust-Produkte lösen ein anderes Problem als die öffentliche Inhaltsauslieferung. Sie steuern, wie Nutzer und Geräte private Anwendungen oder das Internet erreichen. Der Kauf des CDN bedeutet nicht, dass jede Funktion für privaten Zugriff enthalten ist, auch wenn die Dienste im selben Netzwerk laufen.

Integrierte Analysen können Edge-Traffic, Cache-Ergebnisse, Sicherheitsereignisse und Worker-Ausführung verknüpfen. Aufbewahrungszeit und Detailgrad hängen von Tarif und Produkt ab. Exportiere wichtige Logs in das Monitoring-System der Organisation, wenn Vorfallsuntersuchungen oder Audit-Richtlinien längere Aufzeichnungen erfordern.

Cloudflare im Vergleich zu anderen CDN-Anbietern

Cloudflare zeichnet sich durch einen leicht zugänglichen Einstieg und die Breite der Dienste in einem Netzwerk aus. Andere Anbieter können besser zu einer bestimmten Cloud, Auslieferungslogik, Medien-Workflow oder einem Enterprise-Betriebsmodell passen. Der Vergleich sollte die Anwendung in den Mittelpunkt stellen, nicht den globalen Durchschnitt eines Anbieters.

• Cloudflare: Gut für Teams, die CDN, DNS, Sicherheit und Edge-Entwicklung unter einer Steuerungsebene möchten. Prüfe Anbieterabhängigkeit, Kosten für Zusatzoptionen, Regelinteraktionen und Tarifgrenzen.
• Amazon CloudFront: Gut für Workloads mit AWS-Origins, AWS-Identitäten, Logging und Infrastrukturautomatisierung. Prüfe regionale Preisvariablen und die Komplexität mehrerer AWS-Dienste.
• Fastly: Gut für Engineering-Teams, die detailliertes HTTP-Verhalten und programmierbare Auslieferungskontrollen wollen. Prüfe die höhere Konfigurationsverantwortung und die nötigen Fähigkeiten für einen sicheren Betrieb.
• Akamai: Gut für große Enterprise-, Medien-, Sicherheits- und global verteilte Auslieferungsprogramme. Prüfe Vertragsstruktur, Onboarding-Aufwand und tägliche Betriebskomplexität.
• Google- oder Azure-CDN-Dienste: Gut für Anwendungen, die auf der jeweiligen Cloud und ihren Identitäts- oder Monitoring-Tools standardisiert sind. Prüfe Portabilität und Konsistenz, wenn Origins oder Teams mehrere Clouds nutzen.

Die Full-Zone-Einrichtung von Cloudflare ändert normalerweise autoritative Nameserver. Das ist praktisch, wenn ein Anbieter DNS und Proxying verwalten soll. Organisationen, die einen anderen autoritativen DNS-Dienst behalten müssen, sollten die Verfügbarkeit einer Teilkonfiguration und die Tarifanfordernisse prüfen. Dieser Unterschied kann das Migrationsdesign bestimmen, bevor Performance-Tests beginnen.

CloudFront kann Integrationsaufwand reduzieren, wenn Inhalte bereits in AWS-Speicher liegen und Anwendungsberechtigungen AWS-Identitäten nutzen. Fastly kann Teams passen, die detaillierte Auslieferungslogik nah an Anfragen ausdrücken möchten. Akamai verfügt über lange Erfahrung mit anspruchsvollen Enterprise- und Medienprogrammen. Ein regionales CDN kann für einen auf ein Land ausgerichteten Dienst besseren lokalen Support, bessere Zahlungsbedingungen oder Carrier-Beziehungen bieten.

Zwei CDNs einzusetzen kann die Abhängigkeit von einem Edge-Netzwerk senken, führt aber zu Konfigurationsabweichungen, uneinheitlicher Cache-Invalidierung, Abstimmung von Zertifikaten, doppelten Sicherheitsregeln, getrennten Logs und schwierigerer Vorfallsdiagnose. Eine Multi-CDN-Architektur ist sinnvoll, wenn Anforderungen an Verfügbarkeit oder regionale Performance diese Betriebskosten übersteigen. Sie sollte nicht allein deshalb eingeführt werden, weil zwei Anbieter in unabhängigen öffentlichen Tests schneller wirken.

Cloudflare ist daher ein starker Standardkandidat, kein automatischer Gewinner. Ein kurzer Test gegen die relevanteste Alternative führt zu einer besseren Entscheidung als ein Vergleich der Funktionsanzahl.

Cloudflare-Preise und Gesamtkosten

Die Preise von Cloudflare beginnen mit festen Standardtarifen und ergänzen je nach Workload nutzungsbasierte Produkte und individuelle Verträge. Die öffentlichen Network- und CDN-Tarife sind:

• Free kostet 0 US-Dollar pro Monat und richtet sich an persönliche oder Hobby-Projekte, die nicht geschäftskritisch sind.
• Pro kostet 20 US-Dollar pro Monat bei jährlicher Abrechnung oder 25 US-Dollar bei monatlicher Abrechnung.
• Business kostet 200 US-Dollar pro Monat bei jährlicher Abrechnung oder 250 US-Dollar bei monatlicher Abrechnung.
• Enterprise verwendet einen individuellen Jahresvertrag für geschäftskritische Anwendungen.

Die Basistarife enthalten CDN-Auslieferung, autoritatives DNS, Universal SSL und DDoS-Schutz. Sie machen jedoch nicht jedes Cloudflare-Produkt kostenlos. Argo-Routing, Load Balancing, erweiterte Zertifikatsoptionen, Workers-Nutzung, Bildverarbeitung, Videoauslieferung, persistenter Cache-Speicher, Log-Zugriff und spezialisierte Sicherheitsfunktionen können separate Gebühren oder Vertragsbedingungen verursachen.

Schätze die Gesamtkosten mit den tatsächlichen Traffic-Kategorien. Trenne cachebare Bytes, dynamische Anfragen, Bildvarianten, Videominuten, Compute-Aufrufe, Log-Volumen, DNS-Anfragen und Quellübertragung. Modelliere anschließend Monate mit geringer, normaler und hoher Last. Berücksichtige auch Arbeitszeit für Konfiguration, Monitoring, Incident Response und Pflege von Richtlinien.

Einsparungen am Origin gehören in dieselbe Rechnung. Eine kostenpflichtige CDN-Funktion kann eine größere Cloud-Egress-Rechnung senken oder eine kleinere Quellflotte ermöglichen. Umgekehrt kann eine Website mit überschaubarem lokalem Traffic finanziell wenig gewinnen, selbst wenn der kostenlose Tarif Sicherheit und Verbindungsbehandlung verbessert.

Preise können auch die Architektur beeinflussen. Ein Team kann gewöhnliches Edge-Caching für beliebte Dateien, persistenten Speicher für eine kleinere Gruppe teurer Quellobjekte und direkte Origin-Auslieferung für seltene Inhalte wählen. Das ist oft günstiger, als jede Option auf den gesamten Traffic anzuwenden.

Wie du Cloudflare sicher auswählst und einführst

Cloudflare passt gut, wenn eine öffentliche Website, Anwendung oder API verteilte Nutzer bedient und das Team Edge-Auslieferung, Traffic-Schutz und Zertifikatsverwaltung möchte, ohne ein globales Proxy-Netzwerk selbst aufzubauen. Der Rollout sollte mit messbaren Zielen und einem rückgängig zu machenden Pilotprojekt beginnen, nicht mit einer Sammlung aktivierter Schalter.

Es kann weniger gut passen, wenn Richtlinien vollständige Kontrolle über Proxy-Maschinen verlangen, ein bestehender Anbieter-Vertrag den Bedarf bereits erfüllt, die Anwendung nicht unterstützte Protokolle nutzt oder Datenverarbeitung in eng definierten Rechtsräumen bleiben muss. Cloudflare bietet regionale und Enterprise-Kontrollen, doch die vertraglich vereinbarte Konfiguration muss gegen die rechtlichen und technischen Anforderungen der Organisation geprüft werden.

Eine sichere Einführung kann fünf Stufen folgen:

1. Erfasse Basiswerte für Latenz, Seitenmetriken, Fehlerraten, Origin-Last, Übertragungsvolumen und aktuelle DNS-Werte.
2. Füge die Domain hinzu, prüfe jeden importierten DNS-Eintrag und identifiziere Mail- oder Validierungseinträge, die DNS-only bleiben müssen.
3. Starte mit einem Hostnamen mit geringem Risiko oder einem begrenzten Traffic-Anteil. Prüfe anschließend Zertifikate, Weiterleitungen, Anfrage-Bodys, Uploads und Anwendungscallbacks.
4. Aktiviere Full strict-Verschlüsselung, beschränke den direkten Origin-Zugriff und führe Sicherheitsrichtlinien, wo möglich, zunächst im Monitoring-Modus ein.
5. Ergänze eng begrenzte Cache Rules, beobachte Misses und Bypasses und erweitere erst, nachdem authentifiziertes und personalisiertes Verhalten Tests bestanden hat.

Nameserver-Änderungen können Zeit brauchen, bis sie sich über Resolver verbreitet haben. Eine frühzeitige Senkung der relevanten DNS-Gültigkeitszeit kann den Übergang verkürzen, muss aber früh genug erfolgen, damit vorhandene gecachte Antworten ablaufen. Behalte die Konfiguration des bisherigen Anbieters bei, bis der neue Dienst über einen repräsentativen Traffic-Zeitraum stabil geblieben ist.

Sobald Traffic Cloudflare erreicht, prüfe den Antwort-Header CF-Cache-Status. HIT bedeutet, dass Cloudflare eine gecachte Antwort zurückgegeben hat. MISS bedeutet, dass keine nutzbare Kopie vorhanden war und eine Antwort upstream abgerufen wurde. DYNAMIC zeigt an, dass die Anfrage zum Anfragezeitpunkt nicht als geeignet galt. BYPASS weist meist auf eine Regel oder Origin-Antwort hin, die das Speichern verhindert hat. UPDATING kann erscheinen, wenn während einer Hintergrund-Revalidierung veraltete Inhalte zurückgegeben werden. Der Header Age zeigt, wie lange ein bedienter Cache-Eintrag seit seiner letzten Validierung oder Befüllung gespeichert ist.

Prüfe vor dem breiten Rollout fünf Ergebnisse:

• Angemeldete Nutzer erhalten niemals Inhalte anderer Nutzer, und Abmeldung oder Berechtigungsänderungen wirken korrekt.
• Purging und versionsbasierte Deployments ersetzen geänderte Ressourcen innerhalb des nötigen Aktualitätsfensters.
• Der Origin akzeptiert vorgesehenen Cloudflare-Traffic und lehnt nicht autorisierte direkte Verbindungen ab.
• Firewall- und Rate-Richtlinien erlauben echte Browser, APIs, Webhooks, Such-Crawler und Barrierefreiheits-Tools.
• Das Monitoring trennt Edge-Ausfälle, Quell-Ausfälle, Anwendungsfehler und blockierte Sicherheitsereignisse.

Vergleiche den Piloten mit der Basislinie bei denselben Perzentilen und ähnlichen Traffic-Zeiträumen. Achte auf Änderungen bei Zeit bis zum ersten Byte, Largest Contentful Paint, Fehlerrate, CPU des Origins, offenen Verbindungen und übertragenen Bytes. Ein schnellerer Median zusammen mit schlechterer p95-Latenz braucht Untersuchung, keine Feier.

Erhöhe die Cache-Gültigkeit schrittweise. Lange Werte verbessern die Wiederverwendung, vergrößern aber die Auswirkungen von Invalidierungsfehlern. Öffentliche versionsbasierte Assets vertragen lange Speicherung. Häufig bearbeitetes HTML braucht kontrollierte Revalidierung oder verlässliche Purge-Automatisierung. Kontoseiten sollten außerhalb gemeinsamer Speicher bleiben, außer die Anwendung wurde ausdrücklich für getrenntes Caching entwickelt und getestet.

Plane auch für Ausfälle, nachdem der Normalfall funktioniert. Halte Origin-Zertifikate erneuerbar, dokumentiere das Pausieren des Proxyings, speichere Infrastrukturkonfiguration in der Versionsverwaltung und teste Origin-Failover, wenn es gekauft wurde. Weise Zuständigkeiten für DNS, Cache-Richtlinien, Sicherheitsregeln, Rechnungswarnungen und Kommunikation bei Vorfällen zu.

Cloudflare ist die richtige Wahl, wenn dieser gemessene Rollout bei akzeptablen Gesamtkosten deutliche Gewinne bei Performance, Zuverlässigkeit oder Sicherheit erzielt. Das breite Netzwerk und die integrierten Produkte machen es zu einer führenden Option. Ob diese Fähigkeiten die Anwendung in der Praxis verbessern, entscheidet eine disziplinierte Konfiguration.