DDoS Schutz über BGP Netzwerkankündigungen

In zwei vorangegangenen Artikeln habe ich die Funktionsweise von DDoS Angriffen beschrieben, und wie man DDoS Angriffe auf einfache Art abwehrt. Heute beschreibe ich, wie man eine ganze Infrastruktur zuverlässig und umfassend vor DDoS Angriffen schützt.

Disclaimer: In diesem Artikel geht es um ein äusserst technisches Thema, ich werde dies jedoch mit einfachen Beispielen aus dem Strassenverkehr erklären.

Proxy Schutz - limitierte Sicherheit

Den Proxy-Schutz habe ich in einem früheren Artikel beschrieben. Es ist eine gute Lösung, wenn man einzelne Domänen schützen will, und dabei auch nur einzelne Dienste wie zum Beispiel Web. Das Problem hierbei ist jedoch, dass wenn ein Angreifer merkt, dass nur einzelne Dienste geschützt sind, andere hingegen nicht, er den Angriff dann auf einen nicht geschützten Service lancieren könnte. Technisch ausgedrückt das einfachste Beispiel ist z.B. ein DNS-Reflection Angriff, oder eine simple Bandbreiten Auslastung mittels ICMP.

In der Regel ist es bei Infrastrukturen jedoch so, dass man einzelne Services auf einzelnen Hosts laufen lässt - so dass ein Host nur wenig Angriffsfläche bietet - eben zum Beispiel nur HTTP (Web). In solchen Fällen kann ein Proxy-Schutz durchaus genügend sein. Wird die Infrastruktur grösser und setzt man Lösungen für den Lastenausgleich (Cluster) ein, muss allerdings eine Lösung gefunden werden, um ein ganzes Subnetz zu schützen.

Schutz ganzer Subnetze mittels BGP

BGP steht für Border-Gateway-Protocol, und ist ein Routing-Protokoll. Und nun etwas einfacher erklärt: Das Internet ist vergleichbar mit einem Strassennetz, und die Strassenbeschilderungen mit den Ortschaftsnamen sind die Routinghinweise für die Autofahrer. Die Strassenschilder im Verkehr sind "statisch" montiert, daher kann man daran nicht viel verändern. Ist eine Strasse überlastet, zeigen die Schilder nicht automatisch einen alternativen Weg an.

Das BGP ist hingegen ein dynamisches Routing-Protokoll. Fällt eine Verbindung aus, werden die Strassenschilder automatisch angepasst, und der Verkehr kann über eine andere Achse fliessen. Die Achse ist allenfalls etwas ungünstiger und länger, aber die Autofahrer kommen so wenigstens noch an. Genau so funktioniert BGP.

Wenn nun eine Infrastruktur angegriffen wird, so kann der Betreiber der Infrastruktur eine BGP-Ankündigung aussenden, welche allen grossen Verkehrsknoten im Internet meldet, dass der Traffic nun woanders durch geleitet werden soll. Die Strassenschilder zeigen nun in die Richtung eines DDoS Abwehr Anbieters. Solche Anbieter verfügen oft über Bandbreiten zwischen 0.5-2 Terabit, und können grosses Verkehrsaufkommen ohne Probleme bewältigen und nötigenfalls abweisen (=vernichten).

Der Schutz greift in dem Moment, wenn die BGP Ankündigungen seitens DDoS Schutz Anbieters seinerseits an seine Upstream Carrier kommuniziert wurde. Dies ist ein Prozess, der wenige Sekunden dauert. Jeder Anbieter hat zudem eigene ausgeklügelte Algorithmen, die eingehende Angriffe erkennt und die entsprechende Aktivierung proaktiv vornehmen kann.

Zulassen von legitimem Traffic

Nun soll aber legitimer Verkehr trotzdem zu unserer Website gelangen. Wie wird das nun sichergestellt? Nun, der Traffic wird beim DDoS Anbieter nicht einfach vernichtet, sondern er wird analysiert und nur die "bösen" Pakete werden abgewiesen (eine Art Strassensperre). Bei einem DDoS Angriff macht das etwa 99.9% des Traffics aus, der vernichtet wird. Die restlichen "guten" 0.1 Prozent werden dann wieder an uns zurückgesendet.

Da nun aber unsere Strassenschilder umgestellt sind, kann Traffic so gar nie mehr zu uns durchkommen und landet in einer Schleife automatisch wieder beim DDoS Anbieter. Deswegen ist es nötig, auf den Strassen eine eigene Spur zu haben (wie eine Busspur), welche aber nur privat verwendet werden darf (und mit einem Zaun entsprechend geschützt ist). Wir brauchen auf dieser Spur auch keine Strassenschilder, da es keine Möglichkeiten gibt, eine Abzweigung zu nehmen. Allerdings braucht diese Privatspur Platz. Die Spur führt jedoch direkt zu uns. In der Fachsprache spricht man hier von einem VPN.

Technisch funktioniert das sogar ziemlich ähnlich, dies wird über das GRE Protokoll (Generic Routing Encapsulation) aufgebaut. Somit wird der Verkehr also an den DDoS Anbieter gesendet, und guter Traffic wird mittels GRE an uns weitergeleitet. Die Antworten, die unsere Infrastruktur aufgrund der Anfragen versendet, gehen hingegen wieder auf normalem Wege (über unseren Provider) raus. Man spricht hier von einem asymmetrischen Routing: Die Anfragen kommen über GRE rein, die Antworten gehen über den normalen Verkehr wieder raus.

Nachteile der GRE Enkapsulierung

Einer der grössten Nachteile ist, dass für das GRE Protokoll die Pakete ein zweites Mal verpackt werden müssen. Entsprechend nimmt das Übertragungsvolumen pro Paket zu, es braucht Bandbreite auf der "Strasse" und die Übertragung dauert auch länger (höhere Latenz). Da der oben beschriebene GRE-Kanal virtuell ist, und damit nach wie vor übers Internet geht, ist nicht voraussehbar, wie hoch die Latenz tatsächlich sein wird. Bei Anwendungen, die eine hohe Bandbreite und niedrige Latenz voraussetzen, stösst diese Lösung definitiv an Grenzen.

Alternative zu GRE: Private Cloud Direktverbindungen

Damit man den Overhead der GRE Verbindung umgehen kann, muss zwischen der zu schützenden Infrastruktur und dem DDoS Anbieter eine Art "Strassentunnel" gebaut werden. Dieser wird nur privat zwischen Anbieter uns uns verwendet. Deshalb spricht man im Fach- und Marketing Jargon hier gerne von einer "Private Cloud". In diesen Tunnel werden nun die "guten" Autofahrer gesendet, damit sie auf geradem und direktem Wege zu uns ans Ziel gelangen, ohne eine Dritt-Infrastruktur zu belasten.

Technisch gesehen wird der DDoS Anbieter möglichst direkt mit der zu schützenden Infrastruktur verbunden. Idealerweise ist dies ein direktes Peering, so dass die beiden schlussendlich über Switchports direkt miteinander verbunden sind. Hierfür ist es nötig, dass der Anbieter in vielen grösseren Rechenzentren mit einem Anschluss vertreten ist - und dass die zu schützende Infrastruktur sich natürlich auch dort befindet. Wo dies nicht gegeben ist, wird die Infrastruktur direkt über Backbone Verbindungen angeschlossen, wobei ein besonderes Augenmerk auf Bandbreite und Latenz geworfen werden muss. Da der "gute" Traffic aber meist nicht allzu hohe Anforderungen an Bendbreite hat, stellt dies im Alltag sozusagen kein Problem dar.

Vergleich GRE und Private Cloud

Wer bis hierher aufmerksam gelesen hat, wird sich nun sagen, dass die direkten Verbindungen über eine private Cloud die beste Lösung wäre. Dem stimme ich aus einer technischen Sicht auch zu. Allerdings ist der Projektaufwand hierbei viel höher, und auch die Betriebskosten. Ein GRE Tunnel hingegen ist schnell mal aufgebaut, und muss in der Regel auch nicht gemanaged werden.

Daher entscheiden sich viele für eine GRE-basierende Lösung. Sobald jedoch hohe Bandbreiten über 1 Gigabit erforderlich werden, sollte man auf eine Direktverbindung setzen, denn sonst würde man die normalen Traffic Knoten unnötig belasten.

Weiter ist zu erwähnen, dass wenn man akut angegriffen wird, die private Cloud nicht schnell genug errichtet werden kann. Auch in diesen Fällen wird man sich also für die GRE-basierte Lösung entscheiden müssen.

Infrastrukturelle Anpassungen

Bei beiden Lösungen ist es nötig, dass ein eigener Internet-Edge mit dem BGP Protokoll betrieben wird. Grössere Provider betreiben ihren eigenen Edge, und können auch einzelne Subnetze routen. Zu diesem Stichwort ist es wichtig zu erwähnen, dass nur Subnetze geroutet werden können, als nicht einzelne IP-Adressen. Zudem muss ein solches Projekt vorab mit dem Provider abgesprochen werden, denn nicht jeder will, dass man in seine Infrastruktur eingreift. Dementsprechend findet man auf dem Markt bestimmte Provider, welche ihre DDoS Bereitschaft aktiv bewerben, oder sogar eigene Produkte anbieten - entweder als Reseller, oder als eigener DDoS Schutz Anbieter.

Kosten?

Viele DDoS Anbieter halten sich bezüglich der Kosten bei solchen Infrastruktur Lösungen bedeckt. Dies ist auch legitim, denn jedes Projekt hat wieder andere Anforderungen an Bandbreite und Traffic. Generell starten Enterprise-Lösungen wie oben beschrieben bei ca. 1'000 US$ monatlich, bei hohen Anforderungen an die Bandbreite bewegen sich die Preise im Feld von ca. 5'000$ monatlich.

Echte DDoS Abwehr: Proxy Schutz

In meinem letzten Artikel habe ich darüber berichtet, was Distributed Denial of Service (DDoS) Angriffe sind, und wie diese funktionieren. Im heutigen Artikel beschreibe ich nun eine von mehreren Methoden, wie solche Angriffe wirkungsvoll abgewehrt werden können, und wie dies technisch genau funktioniert. Ebenfalls werde ich auf einige der grössten Anbieter solcher Lösungen kurz eingehen.

Die Bandbreite ist das Hauptproblem

Das Hauptproblem bei DDoS Angriffen ist, dass sehr schnell die maximale Bandbreite des Ziel-Providers ausgeschöpft wird. Viele Hosting-Anbieter in der Schweiz verfügen (Stand 2013) über 10 Gigabit/s Anbindungen an die Upstream Provider. Ein starker DDoS Angriff kann aber schnell mal 50-300 Gigabit/s umfassen, womit man innert Minuten K.O. ist.

Massive CDN- und Analyse Infrastruktur

Nun kann man dies abfedern, indem man Content Delivery Networks einsetzt (darüber habe ich schon in einem früheren Artikel zu Web Performance Steigerung berichtet). Ein CDN verfügt über mehrere Standorte weltweit und hat die Fähigkeit, Routing mittels Anycast zu betreiben. Das bedeutet, dass wenn ein Benutzer auf die IP-Adresse unseres Servers zugreifen will, er stattdessen auf den nächstgelegenen CDN-Node geleitet wird. Ein Benutzer aus Washington wird also auf den CDN-Node in Washington geleitet, während ein Nutzer aus Stockholm auf den CDN-Node in Irland geleitet wird, usw. Im Falle eines DDoS Angriffes auf die IP-Adresse unseres Servers, wird der "verteilte" (distributed) Angriff also auf unsere CDN-Nodes "verteilt". Damit wird erstens die Gesamtbandbreite des Angriffes auf die Nodes aufgeteilt, und zweitens ist bis zu diesem Zeitpunkt unser Server vom Angriff noch nicht betroffen.

Diese Nodes nennt man "Scrubbing Facilities". Diese haben hohe Anforderungen an Durchsatz und Rechenpower, um die immensen Datenströme analysieren und Angriffe erkennen zu können. In der Regel verfügen Nodes seriöser Anbieter im Minimum über 100 Gigabit/s Anbindungen an ihre Backbone Provider.

Gängigste Methode: Proxy-Schutz

Hierbei verwenden wir für unsere Domain den DNS Server des DDoS-Mitigation-Anbieters. Dieser schaltet dann den DNS Record für unsere Domain so auf, dass dieser nicht mehr auf unseren Webhost zeigt, sondern auf die Scrubbing Facility. Damit ist die öffentliche IP-Adresse unseres Webhost nicht mehr bekannt. Ruft jemand nun unsere Domain auf, so wird er auf die nächst gelegene Scrubbing Facility geleitet. Ist mit dem Traffic alles okay, wird dieser auf unseren Webhost weitergeleitet - und zwar transparent - sprich der User merkt nichts von der Sache. Ebenfalls wird unser Webhost dann wieder über den Proxy antworten.

Entdeckt nun eine all dieser Scrubbing Facilities einen ungewöhnlichen Anstieg der Anfragen, so wird das gemeinsame Muster in Echtzeit analysiert und ein System von Blockierlisten aktiviert, welche die "bösen" Anfragen bereits schon in der Scrubbing Facility unterbindet. So gelangt nur noch weitgehend gereinigter Traffic auf unseren Webhost. Je nach dem wie weit angelegt ein solcher Angriff ist, werden die Blockierlisten weltweit auf allen Nodes in Echtzeit aktiviert, oder die Behandlung findet nur auf dem betroffenen Node statt.

Gibt es False Positives?

Nun kann man sich überlegen, was denn passiert, wenn eine legitime Anfrage blockiert wird. Hier ist grundsätzlich dazu zu sagen, dass die Blockierlisten erst dann erstellt, aktiviert und nachgeführt werden, wenn ein offensichtlicher Angriff im Gange ist. Dies ist relativ einfach bemerkbar, da der Traffic in einem solchen Moment extrem zunimmt. Das heisst, in Zeiten des "Friedens" wird der Traffic recht unrestriktiv an den Zielhost weitergeleitet, und wenn ein ungewöhnlicher Anstieg des Traffics zu beobachten ist, fangen die Mechanismen an zu greifen.

Während eines laufenden Angriffes, könnte es nun natürlich passieren, dass ein regulärer Besucher fälschlicherweise ausgefiltert wird. Dies wäre aber genau nicht das Ziel eines wirksamen DDoS Schutzes, denn man möchte ja die "Guten" durchlassen und die "Bösen" weg haben. Wie funktioniert das nun?

On the Fly Challenge Response Verfahren

Zur Zeit des Angriffes wird unserer Website automatisch eine Landingpage mit Javascript-Loader vorgeschaltet. Dies funktioniert, da der Traffic ja über den Scrubbing Proxy geht. Dieser Loader beinhaltet ein kleines Stück Javascript Code, in welchem der Browser eine rechenintensive Operation vornehmen muss, welche einige Sekunden dauert (Challenge). Erst wenn die Operation erfolgreich war und das Ergebnis (Response) korrekt ist, wird der Besucher an die richtige Website weitergeleitet und ein kryptographisch gesichertes Cookie gesetzt, in welchem drin steht, dass der User nun legitimiert ist und der Loader nicht jedesmal neu angezeigt werden muss.

Da bei grossangelegten Angriffen keine Webbrowser, sondern Scripts verwendet werden, ist eine solche Challenge-Response Berechnung durch die Angreifer gar nicht erst möglich. Man kann sich das Ganze als eine Art Captcha vorstellen, welches der Mensch aber nicht ausfüllen muss.

Dieses Verfahren kommt wie erwähnt in der Regel erst dann zum Einsatz, wenn ein Angriff im Gange ist. Ansonsten wären Besucher der Website darüber irritiert, dass sie jedesmal 5 Sekunden warten müssen beim ersten Zugriff auf die Website. Ich bin allerdings auch schon auf Websites im Finanz- und Aviatiksektor gestossen, welche dieses Verfahren standartmässig jedesmal anwenden (manchmal auch versteckt hinter einem Lade-Banner, usw).

Einrichtung und Aufwand

Der Vorteil an dieser Methode ist, dass sie sehr schnell umgesetzt ist. Seitens Webmaster gilt es lediglich den DNS Record anzupassen - oder wie heute bei kommerziellen Lösungen üblich, gleich den DNS Server des entsprechenden Anbieters für die Domain beim Registrar zu hinterlegen. Die Domain ist damit nach kurzer Zeit geschützt. Diese Methode eignet sich daher auch dann, wenn man bereits unter Angriff steht. Allerdings ist es nach Einrichtung des Schutzes dann nötig, sofort die IP zu wechseln, damit diese öffentlich nicht mehr bekannt ist. Tut man dies nicht, wirkt der Schutz nur sehr langsam (Stichwort TTL der Domain Records). Allerdings muss man sich dann auch bewusst sein, dass während einer gewissen Zeit die Website nicht erreichbar sein wird.

Daher ist es generell sowieso besser, einen DDoS Schutz proaktiv einzurichten, und nicht erst, wenn ein Angriff bereits am Laufen ist.

Und die Kosten?

Die Kosten eines DDoS Schutzes hängen oft von der entsprechend benötigten Bandbreite ab. Dabei findet man auf dem Markt verschiedene Modelle:

• Limitierung nach Angriffsbandbreite
• Limitierung nach gesäuberter Bandbreite
• Limitierung nach gesamten Datenübertragungsvolumen
• Limitierung nach gesäubertem Traffic
• Total Pakete pro Sekunde
• Unlimitiert

Auf Angebote, welche eine tiefe Limite auf die "Attack Bandwidth" setzen (1Gbit/s und daraunter), sollte man nicht eingehen. Damit würde man bewusst nur einen Schutz für kleine Angriffe einkaufen. Da man zudem nie im Voraus weiss, wie gross ein Angriff sein wird, gerät man hier während eines Angriffes schnell in Not mehr Geld auszugeben.

Eine genaue Zahl für einen wirksamen DDoS Schutz pauschal zu nennen ist nicht möglich. In der Regel wird man für einen wirksamen DDoS Schutz für eine Website nach oben erwähntem Proxy Verfahren zwischen 200 und 1000 US-Dollar im Monat berappen müssen. Grenzen nach oben findet man keine.

Empfohlene Anbieter

Es gibt sehr viele Anbieter, mit einer Google-Suche nach "DDoS Protection" wird man schnell fündig. Damit ihr euch aber von Anfang an zurecht findet, anbei einige vernünftige Anbieter:

• Prolexic
  Seriöser und führender Anbieter auf dem Markt, enorme Infrastruktur, allerdings oberes Preissegment. Bietet viele weitere sicherheitsrelevante Filterungen an
• CloudFlare
  Sehr seriöser Anbieter, bietet auch einen Free-Plan an (allerdings ohne DDoS Schutz, dafür mit weiteren Sicherheitsmechanismen)
• Black Lotus
  Klar führend, interessant ist hier das Kombi-Angebot mit dedizierten Servern; sozusagen alles aus einer Hand. 
• BlockDos
  Junges kanadisches Unternehmen, welche vor allem auf grössere Kunden ausgerichtet ist. 
• KoDDos
  Für grössere Projekte nicht empfehlenswert, aber für kleinere Sites sicher eine interessante Lösung. Interessant auch hier die Kombi-Angebote mit Hosting und VPS, sowie anonymen Hosting

Und weiter?

Dieser Artikel ist einer aus meiner Artikelserie über Large-Scale-Websicherheit. In einem der nächsten Artikel werde ich über DDoS Schutz mittels Private-Cloud Verbindungen und GRE-Tunnels zu Scrubbing Facilities berichten. Stay tuned! PS: Rechts in der Sidebar Mail-Adresse eintragen für neue Artikel!

DDoS Angriffe im Internet: Die Funktionsweise

DDoS steht für "Distributed Denial of Service" und stellt eine komplexe Art von Angriffen im Web dar. Bei solchen Angriffen wird versucht, mit einer grossen Menge von Hosts im Internet, Daten an einen spezifischen Webserver zu senden, um diesen in die Knie zu zwingen. DDoS Angriffe sind äusserst effektiv, denn selbst wenn die Server nicht in die Knie gezwungen werden, so kann mit solchen Angriffen relativ einfach die Gesamtbandbreite bei einem Hosting Provider überlastet werden.

Reales Beispiel 

Im März 2013 hat Spamhaus (sie erstellen Blacklists von bekannten Spammern) die Firma "Cyberbunker" auf ihre Blacklist aufgenommen. Cyberbunker ist ein bekannter dubioser Provider für unter anderem Spam-Versender. Dies führte dazu, dass gewisse Aktivisten einen DDoS Angriff gegen Spamhaus gestartet haben. Der Angriff war bisher einer der grössten DDoS Angriffe weltweit und überstieg 300 Gbps. Dies führte im März zu erheblichen Einschränkungen des Internets vor allem im deutschsprachigen Raume.

Motivationen

DDoS Angriffe werden in der Regel dazu verwendet, das Opfer auf die eine oder andere Art zu erpressen. Ebenfalls häufige Motivation ist das Schädigen oder gar Ausschalten von Mitbewerbern. In vielen Fällen führen diese Absichten zum gewünschten Erfolg, wenn sich das Opfer nicht gegen DDoS Angriffe schützt.

Wie funktioniert ein DDoS Angriff?

Dabei kommt das Wort "Distributed" zum Einsatz: Im Internet existieren sehr viele infizierte Rechner, welche Mitglied eines sogenannten Botnet sind, ohne dass die Besitzer der Rechner etwas davon wissen. Nun kann der Operator eines solchen Botnet all "seinen" Nodes einen Befehl senden, dass diese sich auf eine Website verbinden sollen. Was dann geschieht ist klar: Zehntausende von Rechner rufen gleichzeitig die Website ab, was die Server-Infrastruktur unter Umständen nicht zu tragen vermag. Man kann es vergleichen mit einem Callcenter, welches 90 Telefonleitungen hat. Wenn nun 1000 Personen gleichzeitig immer und immer wieder dort anrufen, dann wird das Callcenter nicht mehr in der Lage sein, ihre Dienstleistung aufrecht zu erhalten. Legitime Anrufer werden nicht mehr durchkommen. Genau gleich verhält es sich im Web.

Top 3 Arten von DDoS Angriffen

Es gibt sehr viele technische Möglichkeiten, um einen DDoS Angriff durchzuführen, oder sogar zu verstärken. Die einzelnen Methoden werde ich hier nicht im Detail beschreiben, dies sprengt den Umfang des Artikels. Ich gebe aber einen kurzen Überblick:
      

Layer 3/4 Angriffe

Auf dem Transport Layer werden Daten an einen Host gesendet, zum Beispiel Verbindungsaufbau Anfragen. Die Quelle dieser Anfragen kann gefälscht werden. Der Host muss dennoch auf alle Verbindungsanfragen reagieren. Sendet nun ein Angreifer sehr viele Verbindungsanfragen, so ist der Host bis zur CPU-Überlastung nur noch mit deren Handling beschäftigt.
   

DNS Amplifizierung Angriffe, gehebelte Angriffe

Hierbei geht es um einen sehr spezifischen Angriff, der heute aber sehr verbreitet ist. Dabei sendet der Angreifer eine Anfrage mit gefälschter Absender Adresse an verschiedenste DNS Server, und die DNS Server antworten an die (gefälschte) IP Adresse. Die gefälschte IP Adresse ist die Adresse des Opfers. Da eine DNS Abfrage in der Regel kaum grösser als 64 Byte ist, ein gesamte Zone aber schnell einige Kilobyte umfassen kann, wird der Angriff hiermit gehebelt. Ein Angreifer kann also mit 64 Byte pro Paket dafür sorgen, dass das Opfer mit z.B. 10'000 Byte angegriffen wird (Faktor 150). Da die Antworten von legitimen DNS Server kommen, ist es schwierig, hiergegen etwas zu unternehmen. Der Angriff zielt darauf ab, die Bandbreite des Opfers zu überlasten.
     

Layer 7 Angriffe

Diese Angriffe fokussieren auf spezifische Aspekte der entsprechenden Applikation. Zum Beispiel sendet der sogenannte "Slow-Read" Angriff Pakete langsam über verschiedenste Verbindungen an den Zielserver. Da der Apache Webserver für jede neue Anfrage einen eigenen Thread erstellt, kann so relativ einfach und schnell der Thread-Pool eines Webservers ausgeschöpft werden (danach kann der Server keine Verbindungen mehr entgegen nehmen).

Andere Methoden basieren darauf, dass der Angreifer Kenntnis über die entsprechend eingesetzte Web-Applikation hat. Weiss der Angreifer zum Beispiel von einer URL, für dessen Aufruf der Webserver lastintensive Arbeiten ausführen muss, so reicht es lediglich aus, diese URL zu Tausenden aufzurufen. Klassische solche Angriffspunkte sind Suchfunktionen auf Websites.

Rudimentäre Schutzmechanismen

Da die DDoS Angriffe in der Regel zur Ausschöpfung der Provider-Bandbreite führen, sind praktisch alle Methoden, welche man "alleine" noch umzusetzen vermag, nicht sehr effektiv. Solche Methoden wären aber, damit sie trotzdem erwähnt sind:

• Einrichten von Sperrlisten auf Firewalls, auf welchen die Absender blockiert werden. Da dies bei einem DDoS Angriff Zehntausende Quellen sein können, ist diese Methode sehr zeitaufwändig und aufgrund ständig wechselnder IP Adressen sehr ineffektiv.
• Einschalten von Rate-Limiting, womit nur eine gewisse Anzahl an neuen Verbindungen zugelassen wird. Damit schützt man zwar die Zielsysteme, aber das Ziel des Angriffs - die Nicht-Verfügbarkeit der Dienste - wurde damit trotzdem erreicht.
• Wechseln der IP-Adresse des Servers, oder zügeln auf einen anderen Server. Da die Websites aber per Domainname angesprochen werden, ist der Erfolg diese Massnahme nur von sehr kurzer Dauer
• Mittels Serverlastverteilung kann die Kapazität massiv erhöht werden. Ebenso massiv sind hierbei allerdings auch die Kosten - vor allem, wenn man die Kapazität auf die Last bei einem DDoS Angriff auslegen will. Also auch nicht sehr praktikabel.

Wirksamer Schutz

Mit rudimentären Schutzmechanismen erreicht man kaum mehr einen wirkungsvollen Schutz vor DDoS Angriffen. Die Technologien ändern sich ständig, und die Komplexität von DDoS Angriffen nimmt ständig zu.

Wie man sich dennoch effektiv gegen DDoS Angriffe schützen kann, berichte ich in meinem nächsten Artikel. Stay tuned!

PS: Um bei jedem Artikel informiert zu werden, trage rechts in der Sidebar deine E-Mail Adresse ein.

Google Hosted Libraries: Oder wieso lokales Hosten falsch ist

Da ich immer wieder sehe, dass Web-Site-Entwickler JavaScript Libraries downloaden und von ihrem eigenen Hosting-Account aus bereitstellen, schreibe ich nun in diesem Artikel, wieso man dies nicht tun sollte, respektive wie man es korrekt angehen soll.

Dabei erkläre ich was hosted libraries sind, und gehe dabei auf das Google-Ajax-API Content Delivery Network ein. Der schnellen Übersichtlichkeit halber aber vorweg:

Falsch:

<script type="text/javascript"
        src="fileadmin/scripts/jquery/jquery.min.js">
</script>

Richtig:

<script type="text/javascript"
        src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js">
</script>

Was ist falsch am Hosten von JS Bibliotheken?

Beispiel jQuery: Meistens bleibt es nicht nur bei einer zu ladenden Datei, sondern es werden noch etliche Submodule in eigenen Dateien mitgeladen (z.B. jquery-ui, jquery-colorbox, usw.). Ein Browser lädt diese Dateien im Grunde genommen hintereinander herunter (resp. gemäss HTTP 1.1 Standard RFC 2616 Sektion 8 zwei Downloads parallel, siehe auch mein Blog-Artikel zur Download-Parallelisierung). Während nun diese Downloads getätigt werden, werden keine weiteren Ressourcen der Website heruntergeladen, bis alle Module fertig geladen haben. Das Laden der Website verzögert sich, bis alle für die Bibliothek erforderlichen Files gedownloadet wurden. Doch worauf will ich hinaus?

Ebenfalls im HTTP 1.1 Standard ist beschrieben, dass die Limitierung von parallelen Downloads pro Host gilt. Wenn wir also die Javascripts von woanders her laden, dann geschieht dies in einer "eigenen Welt", und unsere Website kann munter die Ressourcen herunterladen, die es für die effektive Anzeige auch braucht. Der Download unserer Bilder, CSS usw. wird nicht blockiert durch Library-Downloads. Dazu kommt noch, dass wir die Bandbreite etwas schonen.

Was sind die Vorteile?

1. Die Libraries werden von Google auch mit Cache-Header versehen, welche 1 Jahr gültig sind. Da nun weltweit viele Websites das CDN verwenden, ist die Chance gross einen Besucher zu haben, der die Library bereits in seinem Cache hat. Damit muss der User die Library nicht nochmals downloaden, sondern behält sie in seinem Browser-Cache für alle Websites, welche die Library verwenden.
2. Kein Hosting, keine Bandbreite, kein Storage benötigt für die Libraries
3. Einfaches Umschalten auf eine neuere Library-Version: Anstatt die neue Version zu downloaden und zu installieren, kann einfach das script-src Attribut dahingehend geändert werden, dass eine andere Version angefordert werden soll.
4. Profitieren von der massiven Performance des Google-CDN

Kontras?

Wenn ich Leute frage, wieso sie die Libraries nicht über Google API CDN beziehen, sondern selber bereitstellen, erhalte ich in der Regel die folgende Antwort: Mein Web-Hoster ist schneller als das Google CDN, ich habs gemessen!

Das mag sein, solange der Web-Hoster mehr oder weniger dein Nachbar ist. Was aber, wenn ein User aus New-York deine Seite abruft? Ein 3-Way TCP Handshake zwischen Europa und USA hat einfach seine rund 60-80ms Latenz, schon nur das Licht braucht seine 30ms Reisezeit. Das Google CDN ist aber dezentral gehostet - sprich der Amerikaner kriegt seine JavaScript Libraries von einem dort lokalen CDN, und in Europa kriegen wir sie von einem für uns lokalen CDN. Global gesehen, ist es also vernünftiger, die CDN zu verwenden. Man kauft seine Kopfsalate auch nicht Übersee, wenn man sie im Supermarkt gegenüber kriegen könnte.

Was ich auch schon hörte ist, dass Leute Probleme damit haben, die Kontrolle über ihre JavaScript Libraries "weg zu geben". Ich denke, dieses Argument ist objektiv und sachlich relativ schnell zu entkräften. Ein Content Delivery Network ist weltweit dezentral angelegt, und die Leute von Google wissen wohl, wie man hoch verfügbare Services bereitstellt. Eine Google CDN Downtime ist mir zumal noch nie zu Ohren gekommen, während ich von verschiedenen Hostern schon Downtimes wegen "Wartungsarbeiten" in Kauf nehmen musste.

Welches CDN soll ich wählen (Daten aus 2012)?

Um beim Beispiel von jQuery zu bleiben, gibt es drei grosse CDN, welche diese Libraries anbieten: Google, Microsoft und MediaTemple. Es stellt sich die Frage, welches CDN gewählt werden soll. Das Unternehmen Pingdom (ein Monitoring Service Anbieter) hat über 30 Tage hinweg jeweils einmal pro Minute eine Library von den drei CDN bezogen, und nebenstehende Grafik erstellt.

Daraus ist ersichtlich, dass Media-Temple die besten Antwortzeiten hat. Wenn der Content aber über HTTPS geliefert werden sollte, dann ist das Google CDN die erste Wahl.

Weitere Libraries?

Google hostet nebst jQuery noch folgende Libraries. Ist eine Version einmal veröffentlicht, wird diese unendlich lang gehostet:

• AngularJS
• Chrome Frame
• Dojo
• Ext Core
• jQuery
• jQuery UI
• MooTools
• Prototype
• script.aculo.us
• SWFObject
• WebFont Loader

Nutzen der Browser Download-Parallelisierung für schnellere Websites

In einigen früheren Posts habe ich angesprochen, dass ein Browser nur z.B. 6 Ressourcen gleichzeitig downloaden kann, und die nächsten 6 dann in einem zweiten, dritten, vierten Schritt herunterlädt. Moderne Websites brauchen oft gegen 50-60 Ressourcen (Bilder, Javascript, CSS), was dann die Website im ersten Aufruf langsam erscheinen lässt, da es 10 hintereinander liegende Download Durchgänge braucht.

Dies resultiert darin, dass eine Website im blödsten Falle blockiert bis alle Ressourcen gedownloadet wurden, oder dass die Seite progressiv aufgebaut wird - was je nach Anwendung störend sein kann.

In diesem Artikel beschreibe ich, wie man mit dieser Limitation um gehen kann.

Wieso limitiert ein Browser die Download-Warteschlangenlänge?

Der HTTP 1.1 Standard in der RFC 2616 Kapitel 8.1.4 beschreibt, dass ein Browser maximal 2 Ressourcen gleichzeitig vom gleichen Host anfordern sollte. Mittlerweile downloaden die meisten modernen Browser entgegen dem Standard 6-8 Ressourcen gleichzeitig. Doch wieso überhaupt diese Limite?

Die RFC wurde zu Zeiten geschrieben, als das Web noch langsam, die Bandbreiten limitiert und die Server für heutige Verhältnisse absolut unperformant waren. Die Limite dient zum Schutz von Webservern vor Überlastung. Die Limiten wurden heute in den Browsern erhöht, doch sind sie noch da. Ja, das Web ist schneller, die Server performanter... aber die Websites viel umfangreicher!

Parallelisierung von Downloads über verschiedene Hosts

Hat man nun eine Website, die aus diversen Ressourcen (z.B. vielen Bildern) besteht, so ist der einfachste Trick der, dass man die Ressourcen über verschiedene Domain Namen verteilt. Dabei müssen die Domains nicht mal auf verschiedenen Hosts liegen - es reicht bereits aus, wenn es sich um Domain Aliase handelt, die sich im gleichen Hosting auf dem gleichen Server befinden.

Beispiel Google Maps

Im nachfolgenden Beispiel werden von Google Maps diverse Kacheln für die "Satelliten-Ansicht" geladen. Dies sind weitaus mehr als 6 Stück, und sie werden über diverse Domain-Aliase verteilt; laden damit also alle gleichzeitig:

Das gleichzeitige Laden ist nötig, damit die Karte sofort erscheint, und nicht zeilenweise aufgebaut werden muss. Im Screenshot sind in der ersten spalte die verschiedenen Domain Aliase ersichtlich, und ganz rechts die Startzeitpunkte der Downloads.

Falltüren

• Kann der Host so viele gleichzeitige Requests auch handhaben?
• Wie viel Zeit braucht ein DNS Lookup, um den Domain-Namen in eine IP-Adresse umzuwandeln?

Die erste Frage zu beantworten bedürfte einen neuen Post (Ideen für neue Posts sind immer willkommen!). Beim Apache ist die Frage zum Beispiel mit der Anzahl Sub-Prozessen des Servers beantwortbar. Hier muss man einfach etwas abwägen und ausprobieren.

Die zweite Frage zumindest kann mit Messungen beantwortet werden. Ein DNS Lookup braucht einige Milisekunden Zeit, und wird durch eine Round-Trip-Time verzögert. Allerdings muss ein Lookup nur einmal gemacht werden, danach wird das Resultat vom Browser, vom Betriebsystem und schlussendlich vom lokalen DNS Server zwischengespeichert. Hier kann man nur Erfahrungswerte nennen: Aus eigener Erfahrung holt man das Optimum bei vielen Ressourcen über 3 bis maximal 5 Domain Aliase heraus.

Wann lohnt sich die Technik der DNS Aliase?

Bei Websites mit weniger als 10-20 Ressourcen Anforderungen würde ich empfehlen, gar nichts zu unternehmen. Danach sollte man anfangen, in Sechser-Schritte die Ressourcen auszulagern, also etwa so:

• Alle CSS-Files (z.B. 5 Stück) auf static01.insor.ch
• JavaScript-Files (z.B. 15 Stück)
• 6 auf static01.insor.ch
• 6 auf static02.insor.ch
• 3 auf static01.insor.ch
• Alle Bilder (z.B. 30 Stück)
• 6 auf static02.insor.ch
• 6 auf static03.insor.ch
• usw.

Wichtig ist dabei auch, die Ladereihenfolge der CSS- und Javascript Files zu beachten, und die Javascripts allenfalls mit dem Script Attribut "async" zu laden. Danach muss man sich überlegen, in welcher Reihenfolge die Bilder geholt werden, und welcher Domainname zum entsprechenden Zeitpunkt wohl am "wenigsten ausgelastet" sein dürfte - und so sind die Files zu verteilen.

Zu beachten ist, dass die Files aber immer von der selben Domain aus angeboten werden - so können wir die Browser-Caching-Mechanismen benutzen. Würden die CSS-Dateien plötzlich von einer anderen Domain referenziert werden, müsste der Browser alles erneut downloaden.

Schlussendlich kommt man nicht darum herum, die Sache mit FireBug oder ähnlichem Tool einfach mal zu testen und etwas rum zu spielen, bis man das Optimum heraus geholt hat.

Und sonst...?

Bei grossen Ressourcen spielt dann bald auch mal die Bandbreite eine Rolle. Hier könnte man sich überlegen, die Ressourcen auf ein Content Delivery Network auszulagern. Die meisten CDN unterstützen zudem das Anbieten der Ressourcen über verschiedene Domain Aliase.

Feedback

Habt ihr Erfahrungen mit dieser Optimierungstechnik gemacht? Bitte kommentiert doch mit der entsprechenden Kommentarfunktion unten. Ich bin auch immer offen für Anregungen für neue Themen!

Minimieren von HTTP Requests: Single CSS/JS und Sprites

In meinem letzten Artikel über das Verteilen von Ressourcen auf Content Delivery Networks habe ich das Thema schon angeschnitten, dass man die Anzahl HTTP Requests minimieren sollte, um den Multiplikator der Round-Trip-Time gering zu halten. Nun erkläre ich, wie man das Maximum herausholt, indem man Ressourcen zusammenfasst.

Was ist das Problem bei Anforderung zahlreicher Ressourcen?

Die allermeisten Websites laden mehrere CSS und mehrere Javascript Dateien - gerade bei letzteren für einzelne Module der Übersichtlichkeit halber über diverseste Files. Der HTTP 1.1 Standard empfiehlt, dass ein Browser maximal 2 Ressourcen parallel von einem Host anfordert - die meisten Browser fordern zwar mehr an (ca. 6), aber das Problem ist dasselbe: Sind Javascripts über 24 Files verstreut, kann ein Browser diese maximal in einer Sechser-Parallelisierung downloaden - in unserem Fall wären das 4 mal hintereinander 6 parallele Downloads. Folgendes Netzwerk-Audit einer Website mit 20 Javascript Referenzierungen im Source (insgesamt 197 angeforderte Ressourcen)  illustriert dies, man beachte im Tooltip den Wert unter "Blocking" (damit ist gemeint, dass der Browser so lange blockiert war, bis er den Download resp. die Verarbeitung einleiten konnte):

Zum Zeitpunkt der Anforderung dieser Ressource, verbrachte der Browser also rund eine halbe Sekunde nur mit blockierendem Warten.

In meinem Artikel über den Einsatz von Content Delivery Netzwerken (CDN) habe ich berichtet, dass wir dies entschärfen könnten, indem wir diese Ressourcen auf einen anderen Host legen - denn die Limite von 6 parallelen Download bei modernen Browsern gilt per Host.

In einem anderen Artikel von mir habe ich zudem den Einsatz von Cache-Control-Headers empfohlen, womit die Ressourcen nach dem ersten Download im Browser-Cache verbleiben und so nicht jedes Mal neu angefordert werden müssen.

Tipp 1: Zusammenfassen von CSS

Dies ist wohl die einfachste Möglichkeit: CSS wird sequentiell abgearbeitet, also würde es reichen, die CSS Dateien in der richtigen Reihenfolge einfach in eine einzige Datei zusammenzufügen. Damit haben wir nur noch eine CSS Datei, und brauchen damit auch nur einen Request zu machen. 

Es kommt natürlich oft vor, dass gewisse CSS Dateien nur für einzelne Seiten gelten - diese kann man aber auch einzeln belassen. Das Ziel ist einfach, nicht unnötig viele Dateien zu haben. Also weg vom "modularisierten" Denken, wenn es um Performance geht!

Wem dies zu unübersichtlich wird, der kann auch ein kleines Script schreiben, welches ihm die CSS Dateien zusammenfasst und als gecachte Datei auf dem Webserver ablegt. Dies liesse sich soweit automatisieren, dass wenn das Datum der Source Dateien ändert, das Script bei einer neuen Anforderung ein neues Master-CSS generiert und ausliefert. Der Scripting Overhead und die mittlere Filesystemzugriffszeit von einigen Milisekunden machen sich bezahlt, verglichen mit der enormen Zeit für mehrere Round-Trips (vor allem wenn es mehr als 6 sind).

Tipp 2: Zusammenfassen von Javascript

Auch JavaScripts werden sequentiell abgearbeitet, also lassen sich auch diese in einer einzelnen Datei zusammenfassen - nach dem gleichen Prinzip wie bei den CSS Dateien. Ein Paradebeispiel ist jQuery, welches aus einem Master-JavaScript, und für jedes Modul aus einem weiteren CSS-Script besteht. Eine aufwändig interaktive Website wird schnell mal 10-20 solche Module laden, und das sind einfach wieder 4 Round-Trips à 6 parallelen Downloads.

Tipp 3: Arbeiten mit CSS-Sprites

Dabei packen wir das letzte Problem beim Kragen, und das sind übermässig viele Bilder, die einzeln mit HTTP-Requests vom Webserver angefordert werden. Auch hier gilt die Limite von 2 parallelen Downloads gemäss HTTP 1.1 Spezifikation. Was wir tun können ist folgendes: Anstatt 20 kleine Bilder zu erstellen (z.B. Runde Ecken, Buttons, usw.) - erstellen wir ein einzelnes, sehr breites Bild, in welchem alle diese Elemente enthalten sind. Danach positionieren wir die Bilder mit den CSS-Direktiven "background-image" und "background-position", so dass in einem DIV nur jener Ausschnitt des Bildes angezeigt wird, der für das DIV (z.B. eine Schaltfläche) auch interessant ist.

Damit reduzieren wir die Anzahl Requests für 20 Bilder auf einen. Dieser Tipp funktioniert natürlich nur mit Bildern, die wir effektiv per CSS verwenden. Werden die meisten Bilder mit <img> Tags geladen, würde die Umsetzung dieser Strategie zu einem Reeingineering des Web Templates führen. Ob dies den Aufwand rechtfertigt, ist im Einzelfalle abzuklären.

Ein gutes Beispiel für die CSS Sprite Technik sind zum Beispiel Landesflaggen. Anstatt 265 Requests vom Webserver anzufordern, holt man sich das Sprite mit einem einzigen Request. Die Ladeperformance ist definitiv spürbar!

Tipp 4: Minifizieren (verkleinern) von CSS und JS

Es existieren diverse Tools (wie z.B. der YUI Compressor), die aus CSS und Javascripts Leerzeilen, Abstände und Kommentare rausnehmen, um die Grösse der Dateien zu reduzieren. Bei Javascript werden selbst Funktions- und Variablennamen auf ein Minimum abgekürzt. Natürlich ist der Code danach nicht mehr leserlich. Der Hintergedanke ist aber auch, dass man dies nur für die endgültige Version macht, die dann auch bereitgestellt wird. Dies liesse sich mit unter Tipp-1 genanntem Script ebenfalls automatisieren, was ich aber nicht empfehle. Eine minimierte Version eines CSS/JS will trotzdem noch getestet sein.

Bei eingeschalteter serverseitigen Komprimierung ist die Minifizierung fast ohne Gewinn; man holt durch die fehlenden Kommentare usw. in der Regel kaum viel mehr als weitere 5% heraus.

Fazit

Würde man es schaffen, dass eine Website nur aus einem HTML-, einem CSS- und einem Javascript Dokument besteht; und würde man die Bilder mittels der CSS-Sprites Techniken in nur ein Bild packen, so würde die Website mit einem modernen Browser sämtliche Ressourcen im ersten und einzigen Durchgang downloaden können. Während die CSS-Sprite-Technik aufwändig umzusetzen ist, so ist das Zusammenfassen von JS und CSS aber sicher ein kleiner Aufwand. 

Eine umfassende Websites mit 30 CSS und JS Dateien (gerade bei JS Libraries), und einer RTT von 50ms, spart sich damit 200ms an blockierender Wartezeit durch Parallelitätslimitierungen. Kommt ein Besucher aus Übersee, fällt die RTT hier massiver ins Gewicht. Extrem wird es bei Nutzern von mobilen Endgeräten, wo die RTT in der Regel über 200ms liegt. Auf der Strecke Zürich-Bern mit den schweizerischen Bundesbahnen habe ich nicht selten eine RTT von 2000ms über 3G-Netzwerke. Was das für das Laden von 265 Flaggen bedeutet, liegt auf der Hand.

Speed und Ausfallssicherheit durch Content Delivery Networks (CDN)

In meinem letzten Artikel über die Ladereihenfolge von CSS und JS Dateien habe ich berichtet, dass man damit die Parallelität der Downloads positiv beeinflussen kann, wenn man dabei einige Grundregeln beachtet. Nun gehe ich einen Schritt weiter und zeige, wie man diese Ressourcen auf CDN's verteilt und damit noch höhere Performance rausholen kann.

Dieser Artikel ist vor allem interessant für Betreiber trafficstarker Websites.

Was sind Content Delivery Networks (CDN)?

Dabei handelt es sich um grosse Provider wie Akamai, Amazon, CloudLayer, usw. Diese fungieren als Reverse-Proxies für bestehende Websites, können aber auch verwendet werden, um häufig gebrauchte Ressourcen auszulagern und somit den "kleinen, lokalen" Hostinganbieter zu entlasten. Wieso würde man dies wollen?

1. Shared-Hosting: Dabei teilt man sich den Webspace mit anderen. Entsteht eine Last auf einer Website eines anderen Kunden, wird die eigene Website ebenfalls runtergezogen, das Laden von einzelnen Ressourcen zieht sich hin, und dies beeinflusst die Gesamtladezeit der Website negativ.
2. Traffic-Limiten: Bei den meisten Hostinganbietern ist nach einem Terabyte Schluss, oder es fallen vergleichsweise hohe Gebühren an
3. Bandbreiten-Limitierung: Die meisten Hosting-Anbieter drosseln die Bandbreite pro (dedizierten) Server auf 100mbit/s (Stand Januar 2013). Finden durch verschiedene User nun Streamings von Videos, oder Downloads statt, bleibt keine Bandbreite mehr für das Laden der Page
4. Traffic-Burst: Gerade bei Werbekampagnen kann es gut sein, dass ein Peak entsteht, welcher der Hostingserver nicht zu verarbeiten vermag. Das Resultat sind enorm degradierte Ladezeiten oder Totalausfälle.

Auf den vierten Punkt gehe ich in diesem Artikel nicht ein, dies ist ein anderes Thema. Dies wird in der Regel ebenfalls mit dem Einsatz von CDN gelöst.

Wie sind CDN aufgebaut?

Vereinfacht gesagt, sind dies Storage- und Netzwerkprovider. Ihr ladet eine Ressource hoch, und kriegt hierfür eine Zugriffs-URL. Der CDN Provider unterhält weltweit diverse synchronisierte Datacenters, und die angeforderten Ressourcen werden immer von demjenigen Rechenzentrum geladen, welches sich am Nächsten zum aufrufenden User befindet. Ein User in China wird also die Ressource aus einem Rechenzentrum in China abrufen; ein User aus Deutschland dann z.B. aus einem Rechenzentrum in Irland.

Diese CDN Anbieter verrechnen dabei den verwendeten Storage, den verwendeten Traffic und die bedienten HTTP Requests (als Beispiel, die Verrechnungsmodelle sind vielfältig).

Umsetzung

Diverse Ressourcen einer Website sind statisch (vor allem grosse Banner-Bilder, aber auch CSS, JavaScript, usw.). Anstatt sich hier nun auf eher langsame Leitungen oder Server zu verlassen, könnte man diese Ressourcen auf ein CDN auslagern. Das Vorgehen ist dabei wie folgt:

1. Anmeldung bei einem CDN
2. Upload der Ressourcen, respektive Sync der gesamten Website mit dem CDN
3. Lösen eines Domainnames, damit auf die Ressourcen des CDN zugegriffen werden kann (in der Regel  wird einem eine solche URL mitgeteilt)
4. Ersetzen der lokalen Referenzierung von Ressourcen (js, css, img) in den HTML Sourcen mit externen Referenzierungen auf das CDN

Was erreicht man damit?

Zu beobachten sind zwei Haupteffekte:

1. Erhöhung der Parallelisierung der Ressourcen-Downloads: Ein Browser lädt in der Regel 6 Ressourcen gleichzeitig vom selben Host herunter, dann die nächsten 6, usw. Durch die Verwendung von CDN kommen diese Ressourcen von einem anderen Ort, werden also parallel zu allen anderen lokalen Ressourcen heruntergeladen. Der Geschwindigkeitszuwachs dürfte vor allem bei Bannerbilder usw. spürbar sein.
2. Tiefere Round-Trip-Times bei ausländischen Besuchern: Ein Besucher aus den Staaten hat eine relativ hohe Latenzzeit zwischen Anfrage und Antwort vom Server - dies ist rein physisch durch die Distanz bedingt. Dadurch, dass die Ressourcen von einem für den User lokalen CDN-Mirror geholt werden, verringert sich die RTT auf ein Minimum, was absolut spürbar ist. Beispiel: Zwischen London und New York beträgt die RTT auf neuesten Leitungen ca. 60ms. Das ist reine Wartezeit bedingt durch die Distanz. Werden diverse Ressourcen sequentiell geladen (z.B. Javascripts), summiert sich diese Zahl entsprechend schnell auf.
3. Erhöhte Bandbreite, womit die Ressourcen schneller heruntergeladen werden

Weitere positive Nebeneffekte:

1. Die CDN übernehmen das Cache-Controlling. Wer dies also nicht selber machen kann (siehe mein Artikel über Cache-Control-Headers), der muss sich beim Einsatz von CDN nicht mehr darum kümmern.

Einrichtung und Kosten?

Die Sache ist einfacher als man denkt. Angemeldet hat man sich bei einem CDN schnell, und das syncen einer Website hat man auch innert meist nützlicher Frist hinter sich.

Die Kosten fallen wie folgt an (Beispiel Amazon CloudFront, Preise Europa und USA, Stand März 2013):

• Ca. 10 Rappen pro Gigabyte Traffic
• Ca. 1 Rappen pro 10'000 HTTP-Requests

Eine durchschnittliche Website wird ca. 10-20 Requests pro Seitenaufruf auslösen (pro Ressource ein Request, ausser, die Ressource ist lokal gecached im Browser, z.B. mittels mod_expires). Wenn ein Besucher im Durchschnitt 5 Seiten aufruft, so sind dies 100 Requests pro Besucher. Eine Page mit 2000 Besucher pro Tag wird damit auf 200'000 Requests im Tag kommen (=Hits), womit dies 20 Rappen pro Tag ausmacht. Je trafficreicher die Seite, desto höher werden die Kosten.

Eine News-Seite wie z.B. 20 Minuten Online mit täglich 468'000 Besucher (Mediadaten vom Februar 2013) à 20 Pageloads à 40 Assets verursacht andere Kosten: Dies sind täglich 374 Mio Hits, was pro Tag 370 Franken ausmachen würde. Dies wäre aber immer noch weitaus günstiger, als eine eigene High-Performance Infrastruktur zu betreiben.

Nicht beachtet sind hier die Traffic-Kosten per Gigabyte. Diese dürften durch die Caching-Mechanismen für eine normale Website aber nicht ins Gewicht fallen (meine Faustregel: pro 1000 monatliche Benutzer 1 GB pro Monat). Bei einem grossen News-Netzwerk mit viel Bild- und Videomaterial sieht das allerdings etwas anders aus. Allerdings kann man dann bei den CDN den Traffic vorab einkaufen, womit die Preise nochmals massiv tiefer sind.

Optimierung der Kosten

Die Anzahl HTTP-Requests kann man natürlich optimieren, indem man CSS und JavaScript Dateien je zusammenfasst, und mit CSS-Sprites arbeitet anstatt mit Einzelbildern. Dies hat dann ohnehin wiederum einen positiven Effekt auf die Seitenperformance.

Fazit

Interessant, wenn die Ladegeschwindigkeit ein wichtiges Geschäftskriterium ist. Tiefe Einstiegskosten erlauben es selbst kleinen Unternehmen, von CDN Gebrauch zu machen. Die Hauptvorteile kommen allerdings erst dann zum tragen, wenn entsprechende Übertragunsgvolumen technisch oder preislich durch klassisches Hosting zum Problem werden.