Autor: Anders Henke

5. März 2025

Wie macht ein Content Delivery Network eine Website schneller?

Und wie findet der Webbrowser den Weg zu ihm?

Ein Content Delivery Network (CDN) kann helfen, Webinhalte schneller auszuliefern. Aber wie beschleunigen die im Webhosting verbreiteten CDNs überhaupt die Antworten? Und wie findet ein Webbrowser überhaupt den Weg zum CDN? Diese Fragen werden wir im Folgenden beantworten und klären, wie ein CDN Ihre Website beschleunigen kann.

Wie Netzwerklatenzen die Antwortzeit beeinflussen

Um eine Website im Webbrowser aufzubauen, fließen Datenpakete laufend hin und her: zum Beispiel bis eine TCP-Verbindung mit TLS-Verschlüsselung hergestellt ist und dann HTTP-Anfragen ausgetauscht sind. Die Netzwerklatenzen zwischen Client und Server summieren sich so zu Wartezeiten auf.

Ein gutes Beispiel hierfür ist die Verbindung zwischen einem Webserver in Europa und einem Webbrowser in den USA. Die nur durch den Verbindungsaufbau entstehende Wartezeit kann bis zu einer halben Sekunde betragen – ein deutlich spürbarer Zeitraum. Auf kürzere Distanzen sind die Netzwerklatenzen und so auch die Wartezeiten viel kürzer.

Reduzieren kann man diese Wartezeiten durch einen schneller erreichbaren Server. Da heute praktisch alle Internetverbindungen per Glasfaser stattfinden, muss ein „schneller erreichbarer“ Server näher beim Client stehen. Auch moderne Protokolle wie HTTP/2 können einiges an „hin und her“ vermeiden.

Was auch nicht hilft, sind Premium-Datenleitungen. IONOS wie auch verschiedene CDN-Anbieter betreiben zwischen ihren Standorten eigene Leitungen, die auf den speziellen Strecken verschiedene Vorteile bieten. Global gesehen konkurrieren diese Leitungen mit „dem restlichen Internet“, so dass der Vorteil schnell zusammenschmilzt.

Es gibt auch auf minimale Strecke optimierte Transatlantik-Leitungen, die etwas kürzere Netzwerklatenzen bieten, speziell zwischen London und New York. Richtfunk-Verbindungen können auch schneller sein als Glasfasernetze, bieten aber keine so hohe Bandbreite wie eine Glasfaser.
Börsenhändler zahlen für beides Rekordpreise, um derartige Verbindungen nutzen zu können. So können sie eine Information schneller verarbeiten oder speziell im Hochfrequenzhandel schneller als die Konkurrenz Wertpapiere kaufen oder verkaufen. Dieser spezielle Vorteil macht diese Leitungen dann aber für normalen Webtraffic oder gar ein Content Delivery Network viel zu teuer.

Die Rolle von Caching bei CDNs

Ein unterschätzter, aber wirksamer Faktor eines Content Delivery Networks ist das Caching. Statt dass der Webserver etwa bei jede Anfrage das HTML aus PHP-Code und Datenbank-Inhalten für eine Website “frisch” berechnet, speichert das CDN ein Ergebnis für einige Stunden zwischen und kann es auf Anfrage “sofort” ausliefern. Zum Vergleich: dynamische Inhalte jedes Mal neu zu generieren, kann gern eine Achtel- bis Viertelsekunde dauern. Diese Zeit fällt bei einem aggressiven Caching weg, dafür werden eben unter Umständen veraltete Inhalte ausgeliefert.

Man kann auf verschiedene Weisen festlegen, ob und wie lange Inhalte im Content Delivery Network vorgehalten werden:

Über den HTTP-Header Cache-Control gibt der „echte“ Webserver vor, wie lange Inhalte auf CDN-Servern oder im Browser zwischengespeichert (gecached) werden. Diese Informationen werden vom CDN und Webbrowser ausgewertet und beachtet.
Im CDN kann man oft auch konfigurieren, ob bestimmte Daten nie, immer oder für eine andere Zeit aus dem CDN-Cache ausgeliefert werden sollen. Das CDN überschreibt oder ignoriert dabei die Cache-Control-Header. Das Verfahren bietet sich dann an, wenn die jeweilige Webanwendung keine passenden Cache-Control-Header setzen kann und man „trotzdem“ ein Caching erzwingen möchte.
Zuletzt bieten die CDNs auch noch eine „Purge“-Funktion, um einzelne oder alle Inhalte einer Website aus dem CDN-Cache zu entfernen. Das CDN lädt diese Inhalte dann beim nächsten Zugriff wieder frisch vom echten Webserver und legt sie im CDN-Cache ab. Das plötzliche Löschen der Cache-Inhalte beim Cache-Purge kann zu einer kurzen Performance-Einbuße für die Website und einer ungewohnten Lastspitze auf dem hinter dem CDN betriebenen Webserver führen.

Weitere Möglichkeiten zur Optimierung von Webinhalten

Unabhängig von einem Content Delivery Network kann man die Übertragungsdauer für die eigentliche Datenübertragung optimieren, indem man Inhalte konsequent komprimiert. Für Bilder kann man ein modernes, kompakteres Bildformat wie WebP benutzen oder auch sonstige Inhalte komprimiert übertragen. Auch JavaScript- und CSS-Code lassen sich oft deutlich kompakter zusammenfassen. Für Programmierer interessante Einrückungen oder Zeilenenden braucht der Webbrowser nicht. Und optimalerweise kann nicht genutzter Code komplett weggelassen werden.

Damit wären wir bei den Grundideen eines heute üblichen Web-CDN:

Näher am Webbrowser gelegene Webserver antworten schneller als weit entfernte Webserver.
Wo immer möglich, sollten diese Webserver bereits zwischengespeicherte Inhalte ausliefern, statt diese für jeden Aufruf “frisch” produzieren zu lassen.
Moderne Protokolle wie HTTP/2 oder HTTP/3 (über QUIC) vermeiden einiges an “hin und her” und so an Wartezeiten.
Zusätzliche Optimierungen wie Kompression, Minifizierung oder Bildoptimierung können die Datenmengen und so auch die Übertragungsdauer weiter reduzieren. Wenn der Webserver sie nicht bereits ausführt, kann das CDN diese ggfs. nachholen.

Wo bitte, geht’s zum Content Delivery Network?

Und das bringt uns zur zweiten Frage: wenn ein Content Delivery Network weltweit viele Server aufstellt, die die gleichen Inhalte einer Webseite ausliefern – woher weiß dann der Webbrowser, welcher dieser vielen Server für ihn “optimal” ist und wie er diesen erreichen kann?

Dafür gibt es mehrere Verfahren, die teilweise unabhängig voneinander genutzt, teilweise aber auch miteinander kombiniert werden. Und dann gibt es auch einige Verfahren, die früher eingesetzt wurden, aber heute eher selten oder anders eingesetzt werden.

Grundlagen einer Webanfrage: Wie der Webbrowser eine Website aufruft

Zum Einstieg eine stark verkürzte Zusammenfassung einer Webanfrage:

Der eigene Webbrowser befragt einen rekursiven DNS-Server nach der IP-Adresse zu einer bestimmten Domain.
Der rekursive DNS-Server bedient sich aus eigenen Caches und den im DNS hinterlegten Informationen. Dabei lässt er sich von einem für eine bestimmte Domain autoritativen DNS-Server eine Liste mit einer oder mehreren IP-Adressen geben, speichert dieses Ergebnis zwischen und leitet es an den anfragenden Webbrowser weiter.
Der Webbrowser baut dann eine Verbindung zur genannten IP-Adresse auf, um die gewünschten Inhalte anzufragen und abzurufen.

Nachdem die Basics geklärt sind, geht’s los:

Die Verwendung von HTTP-Header Accept-Language für CDN-Routing

Im Betriebssystem des eigenen Rechners kann man eine Liste bevorzugter Sprachen einstellen.

Diese Information wird heute nicht nur vom Betriebssystem zur Lokalisierung genutzt. Viele Webbrowser übertragen diese Liste auch als “Accept-Language”-Header an fremde Webserver. Die Web-Applikationen können sich so automatisch in einer vom Benutzer bevorzugten Sprache zeigen.

Auch länderspezifische Sprachvarianten können per Accept-Language mit übertragen oder priorisiert werden. Diese Information kann auch von einem Content Delivery Network genutzt werden, um den Webbrowser auf einen etwa landes-genauen CDN-Server weiterzuleiten.

Aber: für so einen CDN-Einsatz ist Accept-Language doch etwas grob oder fehleranfällig. Möchte ein Reisender aus Japan mit seinem Smartphone von Europa aus etwas googlen, sollte Google den Besucher nicht auf den weit entfernten japanischen Server weiterleiten.

Innerhalb größerer Länder wie den USA macht es auch einen Unterschied, ob man einen Webserver „um die Ecke“ oder „auf der anderen Seite vom Kontinent“ anspricht. Auch da ist also Optimierungspotential, das man mit einer reinen Sprachentscheidung verschenken könnte.

Der HTTP-Header Accept-Language ist daher bei Content Delivery Networks eher nicht die beste Wahl, um Besucher auf einen naheliegenden Server weiterzuleiten. Aber: dieses Verfahren kommt mit wenig zusätzlicher Technik aus und kann für bestimmte Fälle wie etwa Software-Download-Mirrors gut genug sein.

GeoIP-Location in der Webanwendung

Mit Hilfe spezialisierter Geotargeting-Datenbanken können IP-Adressen einem bestimmten Land, einer geographischen Region oder gar einer Stadt zugewiesen werden. Mit dieser Information kann ein Webserver Anfragen eines Webbrowsers auf eine besser passende, regionale (Sub-)Domain umleiten.

Optimal ist das ganze nicht: ein „nicht optimaler“ Server beantwortet die erste Anfrage mit einer Weiterleitung, erst nach der Weiterleitung geht es dann schneller voran. Durch die Weiterleitung führt man in der Browserzeile gut erkennbare landes- oder regionale Subdomains ein, was auch nicht immer erwünscht ist. Teilt ein Benutzer A den Link zu so einer regionalen Subdomain mit einem anderen Benutzer B, würde der Benutzer B ja einen für ihn eher langsamen CDN-Server ansprechen.

Dieses Verfahren ist heute trotzdem noch verbreitet, beispielsweise bei Software-Download-Mirrors, bei kommerziellen CDN-Diensten kommt es eher im Hintergrund zur Optimierung oder für Content-Filter zum Einsatz. Wenn eine Website ihre Inhalte nicht in einem bestimmten Land oder einer Region zur Verfügung stellen möchte oder aus lizenzrechtlichen Gründen nur in bestimmten Ländern anbieten kann, kann so ein GeoIP-Location-Filter helfen. Aufgrund der Unschärfe von GeoIP-Datenbanken ist das zwar nicht 100%ig zuverlässig, aber meistens „gut genug“ für so einen Filter.

GeoIP-Location im DNS

Ein autoritativer DNS-Server muss heute nicht mehr komplett statisch arbeiten, sondern kann auch mit dynamisch generierten Antworten arbeiten – etwa einer GeoIP-Datenbank. Damit kann man dann unterschiedlichen Clients gegenüber auf die gleiche Anfrage unterschiedliche Antworten geben. So sprechen die Browser von Besuchern einen Server an, der näher an ihrem Standort liegt.

Inzwischen ist so eine GeoIP-Unterstützung unter verschiedenen DNS-Servern durchaus verbreitet, hier eine kleine Auswahl:

BIND 9

Knot

PowerDNS

gndsd

Es handelt sich um eine sehr spezielle DNS-Konfiguration, daher muss man die vom Content Delivery Network bedienten (Sub)-Domains auf vom CDN-Betreiber gemanagte DNS-Records umstellen. Im einfachsten Fall ist das nur ein CNAME, im schwierigeren Fall muss die komplette Domain vom CDN-DNS verwaltet werden.

Grenzen der GeoIP-Location im autoritativen DNS

Einige rekursive DNS-Server leiten zwar über eine DNS-Erweiterung (EDNS Client Subnet) das gekürzte IP-Subnetz des anfragenden Clients mit, andere rekursive DNS-Server schalten genau diese Funktion aus Privacy-Gründen ab und lassen den autoritativen DNS-Server im Unklaren, ob es nicht doch eine bessere Option geben könnte.

Und: gerade bei großen Ländern sind Zugriffe innerhalb des gleichen Landes nicht automatisch schneller als etwa in ein “benachbartes” Land, gleichzeitig sind die regionalen GeoIP-Location-Daten nicht immer zuverlässig genug für eine jederzeit treffsichere Entscheidung. Die GeoIP-Location im autoritativen DNS hat also auch ihre Grenzen.

Eine weitere Unschärfe: die Anfragen an den autoritativen DNS-Server des CDN erfolgen vom rekursiven DNS-Server z.B. des Internet-Zugang-Providers, Google-DNS oder ähnlichem. Verorten die GeoIP-Datenbanken dessen IP-Adresse in einer anderen Region oder gar einem anderen Land, liefern die autoritativen DNS-Server nicht optimale Antworten aus.

Problem: die Datenqualität von GeoIP-Datenbanken

In der Zeit der IPv4-Knappheit werden immer wieder IPv4-Netze auf neue Einsatzort verteilt. Manchmal werden auch freie IPv4-Netze verkauft und vom neuen Besitzer an einem ganz anderen Ort auf der Welt verwendet. Die Informationen in den verschiedenen GeoIP-Datenbanken müssen daher regelmäßig neu aufbereitet und erneuert werden.

Diese GeoIP-Datenbanken haben aber eine stark schwankende Datenqualität, da die Informationen aus ungenauen Quellen oder unscharfen Annahmen zusammengestellt werden.

Seit fast 30 Jahren gibt es die Möglichkeit, GPS-Angaben zum „Ort“ eines DNS-Namens (bspw. zum Reverse-DNS-Lookup einer IP-Adresse) zu verwenden. In der Praxis wird dieser LOC-Resource-Record allerdings kaum verwendet. Ein Grund dafür ist, dass die Granularität „pro IP-Adresse“ oft viel zu feingranular und unpraktikabel ist.

Seit 2021 gibt es es mit RFC 8805 die „Geofeeds“. In Geofeeds können Provider freiwillige Angaben zu Ort, Region und Land für ihre IP-Netze machen. Erst seit August 2024 gibt es mit RFC 9632 ein Standardverfahren, wie man die URLs dieser Geofeeds bekanntgeben kann.

Die Anbieter von GeoIP-Datenbanken sind daher sehr kreativ, um auch ohne Geofeeds unvollständige Daten zu ergänzen oder aufzulösen. Die genauen Verfahren sind dabei jeweils ein Betriebsgeheimnis, aber aus Fehlern kann man Rückschlüsse ziehen. Ohne aktive Mithilfe der jeweiligen Provider oder weiterer Techniken (z.B. GPS-Daten von Mobilfunkgeräten) ist eine genaue „Verortung“ von IP-Adressen nicht einfach.

Beispielsweise kann ein Anbieter in die traceroute-Ausgaben schauen, über welche Router eine IP-Adresse erreichbar ist. Stehen im Reverse-DNS-Lookup der IP-Adressen der Router zwei- oder dreistellige Kürzel, versucht man diese einem Land oder einer Region zuzuweisen. ISO3166-Ländercodes, ein ICAO-Flugplatzcode oder ein IATA-Flughafencode sind da häufige Vermutungen. Nicht jedes Drei-Buchstaben-Kürzel ist aber ein Hinweis auf einen Flughafen, sondern kann beispielsweise auch ein UN/Locode oder ein nationales Autokennzeichen sein.

Ein Anbieter von GeoIP-Datenbanken könnte auch von bekannten Standorten aus (z.B. per ping/traceroute) die Netzwerklatenzen untereinander sowie zu fremden IP-Netzen bestimmen. Aus den unterschiedlichen Latenzen kann man dann auf die grobe Region schließen. Mit anderen Methoden kombiniert kann man so unscharfe Annahmen bekräftigen.

Anycast-Technologie: Eine Möglichkeit zur Verbesserung der DNS-Ausfallsicherheit

Eine heute sehr verbreitete Verbesserung ist die Nutzung von Anycast für die autoritativen DNS-Server.

Um das Internet resilient gegenüber Störungen und Ausfällen zu machen, können die “großen” Internet-Router ihren IP-Traffic über verschiedene Leitungen und Pfade verschicken. Die Router lernen mit dynamischen Routing-Protokollen wie BGP verschiedene Pfade und berechnen, welcher dieser Wege aktuell der beste sein sollte. Fällt ein Weg dann aus, kennt der Router gleich weitere Alternativen.

Anycast setzt dynamische Routingprotokolle ein, um dieselben IP-Adressen (über verschiedene Router ) an verschiedenen Standorten gleichzeitig zur Verfügung zu stellen.

Global gesehen ist das ein “IP-Konflikt”, aus Sicht der verschiedenen Router im Internet sind es aber nur unterschiedlich gute Pfade zum gleichen Ziel.

Die im Internet angeschlossenen Router entscheiden dann selbst, welcher Pfad der für sie individuell gerade günstigste Weg ist. Sie schicken so alle Anfragen automatisch an den nächstgelegenen, für diese Domain autoritativen DNS-Server.

Verschiedene Antworten auf die gleiche Frage? Passt!

Diese verschiedenen autoritativen DNS-Server können dann auf die gleiche Anfrage auch unterschiedliche Antworten ausliefern: ein DNS-Server aus Frankfurt antwortet etwa mit den IP-Adressen der CDN-Server aus Frankfurt, ein DNS-Server aus Paris mit den IP-Adressen der CDN-Server aus Paris. Die rekursiven DNS-Server nennen den Webbrowsern „nahegelegene“ CDN-Server.

Vollkommen ohne spezielle GeoIP-Datenbanken sucht sich der Internet-Traffic einen optimalen Pfad über möglichst nahegelegene DNS-Server.

Ein seltenes Restproblem bleibt: die Antwort wird auf den Ort des rekursiven DNS-Servers optimiert, nicht nach dem dahinter anfragenden Client. Stehen der rekursive DNS-Server und sein Client ungewöhnlich weit entfernt, kommt die automatische Entscheidung zu einem ungünstigeren Ergebnis.

Betreibt etwa der DSL-Anbieter eine geographisch verteilte Hierarchie von DNS-Caches, kann es dazu kommen. Der direkt angefragte, rekursive DNS-Server holt sich seine Ergebnisse entweder aus einem lokalen Cache oder – von einem weiteren rekursiven DNS-Server, der aber an einem ganz anderen Standort steht. Da DNS selbst auf viel Caching setzt, machen die Latenzunterschiede innerhalb der DNS-Hierarchie keinen großen Unterschied aus. Für den DSL-Provider kann es aber günstiger sein, wenn er einen einzigen, “großen” Cache mit vielen “kleinen” Sub-Caches betreibt statt vieler “mittlerer” Caches. Beim GeoIP-DNS-Ansatz läuft man übrigens in ein ähnliches Problem.

Anycast ist für professionelle CDN-Betreiber eine eher kleine Hürde. Um Anycast einsetzen zu können, muss man von verschiedenen Standorten und Routern aus dynamische Routingprotokolle wie BGP mit anderen Providern einsetzen und über eine eigene AS-Nummer für die globalen Routingtabellen verfügen, ebenso benötigt man dafür mehrere eigene IP-Netze. Das BGP-Announcement muss auch “groß genug” sein, um von fremden Routern akzeptiert zu werden: in der Praxis ist das derzeit für IPv4 ein /22 an IP-Adressen. Die über Anycast erreichbaren Server und Router brauchen auch jeweils eigene IP-Adressen, um gemanaged zu werden und im Hintergrund weitere Dienste ansprechen zu können.

Also: eigene AS-Nummer, mindestens ein /22 an IPv4-Adressen, Peering-Anbindung an mehrere Provider über eigene Router – definitiv nichts mehr für den einfachen “Heimgebrauch” oder zum „das baue ich mir in der Cloud selbst nach“.

Anycast-Technologie für CDN-Webserver: Möglichkeiten und Grenzen

Anycast-IPs lassen sich grundsätzlich nicht nur für DNS nutzen, sondern auch für theoretisch beliebige andere Dienste. Bei dynamischen Routing-Protokollen muss man allerdings bedenken, dass theoretisch jedes IP-Paket über einen anderen Pfad geroutet wird und so bei Anycast auch verschiedene Server erreichen könnte. Für kleine DNS-Anfragen ist das kein Problem: die meisten Anfragen sind klein genug, um in ein einzelnes IP-Paket zu passen, die Antworten kommen dann eben von einem anderen Server mit einer möglicherweise leicht unterschiedlichen, aber immer noch akzeptablen Antwort. Bei größeren DNS-Anfragen (etwa: über TCP) wird das zum “falschen” DNS-Server geschickte Paket dort für kurze Verwirrung sorgen, die für den Client zu einem Verbindungsabbruch der laufenden TCP-Verbindung führt. Ein rekursiver DNS-Server als Client wird seine Anfrage wiederholen und dabei dann in der Regel erfolgreich sein, bei anderen Protokollen und Softwares ist die Fehlertoleranz deutlich geringer.

Sobald ein einzelnes IP-Paket einer laufenden HTTP-Verbindung den “falschen” Server erreicht, lehnt dieser das Paket ab. Dieses Antwortpaket unterbricht damit auf dem Client die laufende HTTP-Verbindung. Der Webbrowser kann mindestens ein Element nicht laden und es kommt zu Darstellungsfehlern auf der Webseite. Im Gegensatz zu den rekursiven DNS-Servern versuchen auch Webbrowser nicht, eine abgebrochene Anfrage selbst zu wiederholen. In so einer Situation käme es also zu Darstellungs- oder auch Verfügbarkeitsproblemen.

Um solche Probleme zu vermeiden, muss man einiges an Network-Engineering-Knowhow in die Routing-Konfiguration stecken: die Routing-Entscheidungen sollen möglichst stabil bleiben, gleichzeitig aber bei Ausfall einer CDN-Location trotzdem den Traffic übernehmen können.

Kombinierte Lösungen für spezielle Anforderungen

Die zuvor genannten Lösungen haben also jeweils Vor- und Nachteile. Im „ganz großen“ Einsatz kommen noch weitere Probleme hinzu:

Als Content Delivery Network muss man nicht nur den eingehenden, sondern vor allem auch den ausgehenden Traffic beachten. Sobald eine Netzwerkanbindung etwa 70% Auslastung erreicht, kommt es ohne eine intelligente Planung zu unerwünschten Warteschlangen-Effekten: etwas Traffic muss plötzlich unerwartet warten, da nicht mehr jederzeit genügend Bandbreite zur Verfügung steht. Je höher die Auslastung dabei ist, umso länger und häufiger muss gewartet werden. Diese Kapazitätsbewertung muss nicht nur für die Summe CDN-Server eines Standorts, sondern auch für jeden einzelnen CDN-Server gemacht werden. Durch ein optimales „Eintakten“ von Traffic könnte man aber auch die freien Kapazitäten oberhalb von 70% Auslastung nutzen.
Schaut man sich den typischen Verlauf von Internet-Traffic an, bemerkt man, dass dieser im Laufe des Tages stark schwankt: nachts sinkt der Traffic deutlich ab, tagsüber hat man ein gutes Mittelfeld und in bestimmten Stunden (etwa zur Mittagspause sowie nach Feierabend) steigt der Traffic deutlich an. Wer jederzeit jede Trafficspitze bedienen möchte, muss viel Überkapazität aufbauen, die man aber eigentlich auch für weniger dringende Übertragungen nutzen könnte.
Routingprotokolle wie BGP treffen nicht immer eine optimale Entscheidung, da ihnen einige Informationen (etwa über die Auslastung eines Servers oder die Geschwindigkeit einer bestimmten Leitung) fehlen können. Im Extremfall schickt man Traffic über eine langsamere, aber kürzere Verbindung mit weniger Bandbreite.

Um Kosten zu optimieren und gleichzeitig die Gesamtverfügbarkeit zu steigern, kann man aber auch die verschiedenen Verfahren kombinieren und um spezielle Routinen der eigenen Website ergänzen. Das erfordert dann aber recht weitgehende Eingriffe, die über ein einfaches CDN hinaus gehen.

Ein Beispiel für ein effizientes Loadbalancing: Facebooks Ansatz

Stand 2015: Mit etwas JavaScript-Code bei etwa jedem 80.000sten Abruf eines Profilbildes lässt facebook.com den jeweiligen Webbrowser die Leistung zu einem zufällig ausgewählten, meist nicht optimalen Alternativ-Server vermessen. Bei einer großen Website wie Facebook kommt es zu einer großen Menge an Messwerten. Dadurch ergibt sich für Facebook ein Gesamtbild, aus welchen IP-Netzen und GeoIP-Locations welche Facebook-Standorte und Facebook-Cluster gerade wie gut erreichbar sind. Die so gewonnenen Informationen nutzt man dann, um die per Anycast angebundenen autoritativen DNS-Server mit einer eigenen, alle fünf Minuten aktualisierten “Karte” zu versorgen, die den Traffic verschiedener Clients gezielt auf unterschiedliche Loadbalancer und Servercluster verteilt. Falls für ein bestimmtes Client-Netz noch keine Kartendaten vorhanden sind – nimmt man eben einen GeoIP-kompatiblen Serverstandort.

Auf diese Weise verteilt man den eingehenden Traffic optimal auf die eigenen Netze, Rechenzentren und Servercluster (mehr dazu in einer Präsentation von Patrick Shuff und einem FB-Research-Post von Hyojeong Kim).

Facebook wendete diese mit weiteren Messwerten aus Netzwerk-, Cluster- und Location-Auslastung auch für den ausgehenden Traffic an.

So wurde der ausgehende Traffic beispielsweise nicht mehr streng über den “besten” Pfad, sondern teilweise gezielt auch über einen zweiten, nur wenige Millisekunden “schlechteren” Pfad geschickt. Diese Strategie vermeidet es, den “optimalen” Pfads zu überlasten und sorgt so für eine gleichmäßige Auslastung seiner Internetleitungen. Viele herkömmliche Verfahren wie (gewichtetes) ECMP reichten Facebook hier einfach nicht mehr aus.

Facebook konnte auf diese Weise seine WAN-Netzwerkleitungen optimal auslasten, ohne diese zu überlasten. In etwa 5% der Fälle konnte man mit den eigenen Messwerten den Besuchern sogar eine um etwa 20 Millisekunden schnellere Alternative bieten, als es die Routingprotokolle für sich entschieden hätten (siehe dem FB-Research Paper „Engineering Egress with Edge Fabric: Steering Oceans of Traffic to the World„). Zu Gunsten der Wirtschaftlichkeit für Facebook bedient man aber eben auch einen Teil der Besucher über einen “zweitbesten” Pfad, so dass dieser Ansatz in einem Vergleichstest vielleicht nicht immer so optimal abschneiden würde wie ein anderer Ansatz.

Fazit – Die Rolle von CDNs in der modernen Web-Infrastruktur

Sind die Voraussetzungen für ein Content Delivery Network vorhanden, kann ein CDN sowohl für eine Entlastung der dahinter stehenden Webserver und eine Beschleunigung der jeweiligen Website für die Besucher sorgen. Wesentliche Mittel dafür sind Server, die netzwerk-technisch näher am Besucher stehen und so eine schnellere Antwort versprechen sowie das Ausliefern zwischengespeicherter, ggfs. optimierter Antworten.

Routingprotokolle wie BGP sorgen dafür, dass Traffic zwischen den verschiedenen Internet-Providern auch beim Ausfall oder Wartung einer oder mehrerer Internetleitungen automatisch über andere Wege verteilt und empfangen werden kann. Der Traffic nimmt dabei dann den nächstbesten Weg.

CDNs nutzen die gleichen Protokolle, um Traffic für ihre DNS- oder Webserver gezielt in die den Webseitenbesuchern möglichst naheliegenden Rechenzentren zu leiten. Verschiedene Server aus verschiedenen CDN-Rechenzentren sind dafür unter der gleichen IP-Adresse erreichbar, und über die Routingprotokolle entscheiden sich die Router der verschiedenen Provider zwischen Browser und CDN für die jeweils „kürzeste“ Strecke. Der Traffic landet so im nächstgelegenen Rechenzentrum, die Netzwerklatenzen werden reduziert.

Dürfen beim Beantworten der Anfragen auch nicht top-aktuelle Antworten ausgeliefert werden, kommt Caching zum Einsatz. Hierbei ergibt sich eine sehr deutliche Beschleunigung der Antworten und eine Entlastung der „echten“ Webserver hinter dem Content Delivery Network.

Welches genaue technische Modell jeweils eingesetzt wird, spielt primär für den CDN-Anbieter, aber nicht für die Besucher einer Website eine Rolle. Unterschiede sind messbar, aber kaum spürbar – und letztlich geht es ja darum, einen spürbaren Vorteil zu erzielen.

Wichtiger ist daher auch die Frage, ob und wie stark die eigene Website grundsätzlich von einem CDN profitiert. Enthält eine Website vor allem statisch ausgelieferte Inhalte (z.B. Grafiken, Stylesheets und JavaScript) und wird sie von einem weltweiten Publikum aufgerufen, führt an einem CDN kaum ein Weg vorbei.

Bei dynamisch generierten, nicht cachebaren Inhalten (z.B. einer API) kommt das Caching als wesentliche Stärke eines Content Delivery Network nicht mehr zum Tragen. Statt die Anfrage direkt vom echten Webserver zu beantworten, nimmt der gesamte Webtraffic erst einmal einen „Umweg“ über das CDN, ohne dass das CDN seine Vorteile ausspielen könnte. Hier kann der gezielte Verzicht auf ein CDN zu Gunsten eines „regionalen“ Servers sogar die bessere Wahl sein.