Content Delivery Network
![Links zu sehen ein Server, von dem aus Inhalte an mehrere Clients verteilt werden. Rechts die Verteilung der Inhalte über mehrere Server, d. h. das CDN](http://upload.wikimedia.org/wikipedia/commons/thumb/2/26/NCDN_-_CDN.svg/220px-NCDN_-_CDN.svg.png)
Rechts: CDN-Schema
Ein Content Delivery Network (CDN), oder auch Content Distribution Network genannt, ist ein Netz regional verteilter und über das Internet verbundener Server, mit dem Inhalte – insbesondere große Mediendateien – ausgeliefert werden. Ein CDN stellt skalierende Speicher- und Auslieferungskapazitäten zur Verfügung und gewährleistet auch bei großen Lastspitzen einen optimalen Datendurchsatz.
CDN-Knoten sind auf viele Orte verteilt und oft auch auf viele Backbones. Sie arbeiten zusammen, um Anfragen (Requests) von End-Nutzern nach Inhalten (Content) möglichst ökonomisch zu bedienen. Einzelne Standorte werden als PoP (Point of Presence) bezeichnet und bestehen aus Server-Clustern.
Im Hintergrund (Transparent) werden die Daten im Netz so vorgehalten (Caching), dass die jeweilige Auslieferung entweder möglichst schnell geht (Performance-Optimierung) oder möglichst wenig Bandbreite verbraucht (Kosten-Optimierung), oder beides zugleich.
Große CDNs unterhalten tausende Knoten mit zehntausenden Servern.
CDN ist ein Oberbegriff, der verschiedene Arten von Diensten zur Bereitstellung von Inhalten umfasst: Videostreaming, Software-Downloads, Beschleunigung von Web- und Mobilinhalten, lizenziertes/verwaltetes CDN, transparentes Caching sowie Dienste zur Messung der CDN-Leistung, Lastausgleich, Multi-CDN-Switching und Analysen und Cloud Intelligence. CDN-Anbieter können in andere Branchen wie Sicherheit, DDoS-Schutz und Web Application Firewalls (WAF) sowie WAN-Optimierung überwechseln.[1]
Funktionsweise[Bearbeiten | Quelltext bearbeiten]
Das CDN besteht zunächst aus einem Ursprungsserver, auf dem der Inhalteanbieter die zu verteilenden Inhalte ablegt, einer großen Zahl an Replica-Servern, die Kopien dieser Inhalte vorhalten, und einem Distributionssystem, das die Inhalte auf den Replica-Servern verteilt. Für die Umleitung der Benutzeranfragen auf die einzelnen Replica-Server ist ein Request-Routing-System zuständig, welches sich dabei auf verschiedene Kennzahlen über diese Server stützt, die ihm vom Accounting-System geliefert werden.
Sendet ein Client eine Anfrage an das CDN, dann wählt das Request-Routing-System einen geeigneten Replica-Server. Bei der Auswahl bezieht es Kennzahlen über deren aktuelle Belastung (zum Beispiel CPU-Auslastung, Anzahl der aktiven Verbindungen) und über die Netzwerkverbindung zwischen Client und Server (zum Beispiel geographische Entfernung, Latenzzeit, Übertragungsrate), seltener über die Identität des Clients (zum Beispiel Unterscheidung zwischen Standard- und Premium-User) mit ein, die ihm durch das Accounting-System zur Verfügung gestellt werden.
Nach Auswahl des Servers muss die Benutzeranfrage nun umgeleitet werden. Das am häufigsten eingesetzte Verfahren dafür ist DNS-basiertes Request Routing. Dabei werden Anfragen des Clients an einen vom CDN bereitgestellten DNS-Server weitergeleitet, der die IP-Adresse des Replica-Servers zurückgibt. Alternativ dazu kann auch ein HTTP-Statuscode 302 die Weiterleitung auf einen anderen Webserver veranlassen.
Architektur und Schlüsselkomponenten[Bearbeiten | Quelltext bearbeiten]
Inhaltsanbieter: die Einrichtung, die den Inhalt zur Verfügung stellt.
Autorisierung: Der Inhaltsanbieter erteilt dem CDN-Anbieter die Genehmigung zur Bereitstellung von Inhalten.
Berichterstattung: Der Inhaltsanbieter ersucht den CDN-Anbieter um eine Leistungsanalyse, um die Servicequalität des CDN-Anbieters zu bewerten und Zugang zu anderen maßgeblichen Daten zu erhalten.
Quelle: Der Inhaltsanbieter übermittelt eine Kopie des Inhalts.
Inhalt: Digitale Informationen, die zur Verbreitung erstellt oder lizenziert wurden.
Anforderung: Der Nutzer oder die Nutzerin fordert den Inhaltsanbieter auf, Daten lokal anzuzeigen oder zu speichern.
Ausliefern: CDN sendet den Inhalt an den Nutzer.[2]
Nutzer: Die Einheit, die Daten vom Inhaltsanbieter anfordern will.
- Delivery Nodes (Zustellungsknoten): Die Hauptaufgabe besteht darin, dem Endnutzer Inhalte zu liefern. Bei den Zustellungsknoten handelt es sich um Server mit Caches, auf denen Inhalte bereitgestellt werden. Die Inhalte können manuell auf diesen Knoten gespeichert werden (Push-CDNs), oder die Zustellungsknoten können die Inhalte von den Ursprungsknoten anfordern (Pull-CDNs). Der Hauptvorteil von Push-CDNs liegt darin, dass der Inhalt für die Nutzer, die ihn abrufen, ohne Verzögerung verfügbar ist. Der Hauptnachteil ist, dass der Inhaltsanbieter die Inhalte nach jeder Aktualisierung proaktiv „pushen“ muss. Der Unterschied zu Pull CDNs besteht vor allem in der automatischen Abfrage von Inhalten beim Content-Provider. Der Hauptnachteil ist die Anfangsgeschwindigkeit bei der Bereitstellung der Inhalte: Wenn der Benutzer die Inhalte das erste Mal abruft, erfolgt die Bereitstellung genauso schnell, wie wenn der Inhaltsanbieter kein CDN verwenden würde.
- Storage Nodes (Speicherknoten): Das Hauptziel besteht darin, Kopien der Originaldaten zu speichern, die auf Bereitstellungsknoten verteilt werden. Für die Speicherknoten kann ein hierarchisches Modell festgelegt werden, das eine Caching auf mehreren Ebenen zulässt.
- Origin Nodes (Ursprungsknoten): Das sind die wichtigsten Inhaltsquellen, die die Übertragung von Inhalten über das Netz oder die Infrastruktur des Inhaltseigentümers erlauben.
- Control Node (Kontrollknoten): Die Hauptaufgabe ist das Hosten von Verwaltungs-, Routing- und Überwachungskomponenten eines CDN.[2]
Im Wesentlichen gibt es 3 Typen von Inhalten:
- Dynamic content (Dynamische Inhalte): Inhalte, die mit Hilfe einer der gängigen Web-Programmiersprachen wie php, ruby oder Java automatisch erzeugt werden.
- Static content (Statische Inhalte): Inhalte, die sich normalerweise nicht sehr oft verändern und nicht neu erstellt werden müssen wie zum Beispiel Bilder, CSS und JavaScript.
- Streaming content (Streaming Inhalte): Die Videos oder Audiodateien, die mit Hilfe einer Webbrowser-Steuerung wiedergegeben werden.[2]
Caching[Bearbeiten | Quelltext bearbeiten]
Die Zwischenspeicherung (Caching) ist das Herzstück der CDN-Dienste. Ähnlich wie beim Caching von Browsern (siehe Cache) werden Dateien auf einer Festplatte gespeichert, wo sie schneller abgerufen werden können. Ein CDN verschiebt den Inhalt einer Webseite auf leistungsstarke Proxy Server, die für eine beschleunigte Verteilung von Inhalten optimiert sind. Diese Inhalte können nun von Website-Besuchern, die von einem nahe gelegenen Standort aus surfen, schnell abgerufen werden. Im Gegensatz zum Cache eines Webbrowsers, der nur für einen einzigen Benutzer verwendet wird, verfügt das CDN über einen gemeinsamen Cache. In einem gemeinsam genutzten CDN-Cache kann eine von einem Nutzer angeforderte Datei später von anderen Nutzern abgerufen werden, was die Anzahl der Anfragen an den Ursprungsserver erheblich verringert.[3][4]
CDN-Topologien[Bearbeiten | Quelltext bearbeiten]
Bezüglich der Topologie unterscheidet man bei Content Delivery Networks zwischen einer verstreuten und einer konsolidierten Topologie.
Verstreute CDNs betreiben eine große Anzahl von PoP mit mittlerer und niedriger Kapazität, die ausgewählte geografische Regionen dicht besiedeln. Der Schwerpunkt dieser Topologie liegt auf der optimalen räumlichen Nähe, wobei die einzelnen PoPs in unmittelbarer Nähe zueinander liegen können. Durch die physische Nähe kann die Latenzzeit wesentlich verringert werden, insbesondere in Regionen mit geringerer Breitbandkonnektivität. Nachteile dieser Form der Topologie sind der höhere Wartungsaufwand sowie die damit verbundenen Kosten und die durch mehrere Verbindungspunkte verlängerte Paketumlaufzeit. Diese Topologie kam vor allem in frühen CDNs zum Einsatz.[5]
Bei einem Konsolidierten CDN wird eine kleine Anzahl hoch-leistungsfähiger PoP betrieben, die strategisch in großen Datenzentren positioniert sind, um eine breite Bevölkerungsmenge zu bedienen. Diese Netzwerktopologie stellt einen modernen Ansatz für die Bereitstellung von Inhalten dar, der durch die Entwicklung der Internetkonnektivität ermöglicht wurde. Der Hauptvorteil einer konsolidierten Topologie ist die zentralisierte Infrastruktur, die flexibles Management und agile Konfigurationsbereitstellung ermöglicht. Dies kommt sowohl den Endnutzern als auch den Netzbetreibern zugute, da sie mehr Kontrolle und eine insgesamt bessere Reaktionsfähigkeit bieten. Zudem sind die hier eingesetzten Points of Presence widerstandsfähiger (z. B.: gegen DDoS-Angriffe). Nachteile dieser Topologie sind deren geringere Effektivität in Regionen mit schlechterer Konnektivität und die höhere Komplexität der Bereitstellung des Netzwerkes.[5]
CDN-Arten[Bearbeiten | Quelltext bearbeiten]
Content-Delivery-Netzwerke können auf unterschiedlichen Bereitstellungsprinzipien basieren:
Origin Push CDN[Bearbeiten | Quelltext bearbeiten]
Der Begriff Push-CDN bezieht sich auf die Art von Content-Delivery-Network, bei dem die einzelnen CDN-Server ähnlich wie der Ursprungsserver vorgehen. In diesem Szenario sendet der Ursprungsserver die Inhalte direkt und proaktiv an Edge-Server im CDN-Netzwerk (automatisch oder manuell) und verlinkt auf sie. Diese Inhalte werden auf dem Server zwischengespeichert, bis sie gelöscht oder bereinigt werden, weil eine neue Version der Seite gesendet wird. Die Webinhalte werden hierbei automatisch in den CDN-PoP eingefügt, der dem Standort des Clients am nächsten ist. Wenn Endnutzer also eine Datei (HTML, Video, CSS, …) anfordern, kann das CDN alle nötigen Daten nahtlos in deren Browser liefern. Die Verantwortlichkeit der Inhalte liegt dabei bei den jeweiligen Websiteeigentümern, die bei jeglichen Änderungen explizit in das CDN „gepusht“ werden müssen.[6]
Ein wesentlicher Vorteil dieser CDN-Art ist die effizientere und einfachere Nutzung des Datenverkehrs, da nur bei Änderungen Inhalte auf den CDN-Server hochgeladen werden müssen.[7] Push-CDNs sind bei relativ statischen Webseiten mit großen eingebetteten Datenmengen zu bevorzugen.[8]
Origin Pull CDNs[Bearbeiten | Quelltext bearbeiten]
Ein Pull-CDN basiert darauf, dass die tatsächlichen Inhalte nur auf den jeweiligen Webservern gespeichert werden, es werden keine Daten tatsächlich auf die CDN-Server hochgeladen. Hier zieht das CDN die Inhalte von den Hauptservern und speichert sie im Cache. Je nach Benutzeranforderung werden die Inhalte nicht vom Hauptserver, sondern von den zwischengespeicherten Kopien des nächstgelegenen CDN-Servers an den Client-Browser geliefert. Bei der ersten Anfrage für einen spezifischen Inhalt an einen Edge-Server treten höhere Ladezeiten auf, da die Daten erst in den Cache geladen werden müssen. Das CDN bewahrt die Dateien auf, bis sie ablaufen.[6][8]
Peer-to-Peer CDN[Bearbeiten | Quelltext bearbeiten]
![](http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/P2P-network.svg/220px-P2P-network.svg.png)
Peer-to-Peer (P2P) CDNs nutzen das Peer-to-Peer Protokoll zur Bereitstellung von Inhalten. Hierbei werden die Inhalte nicht auf designierten CDN-Servern gespeichert bzw. gecached, hier sind Benutzerclients Teil des Netzwerkes. Die Clients, die auf die Inhalte zugreifen, teilen die Teile mit anderen, d. h. während sie die Inhalte herunterladen, laden sie sie auch hoch, ohne das normale Browsing-Erlebnis zu beeinträchtigen. Das bedeutet, dass die inhaltszentrierten Netze im Gegensatz zu Client-Server-Systemen besser funktionieren, wenn mehr Nutzer auf die Inhalte zugreifen (insbesondere bei Protokollen wie Bittorrent, die eine gemeinsame Nutzung erfordern). Diese Eigenschaft ist einer der Hauptvorteile von P2P-Netzen, denn dadurch sind die Einrichtungs- und Betriebskosten für den ursprünglichen Inhaltsanbieter sehr gering.[9][10][11]
Peer-Assisted CDN[Bearbeiten | Quelltext bearbeiten]
Ein Peer-Assisted CDN (PA-CDN) beschreibt eine hybride Architektur, die darauf abzielt, die Vorteile von CDNs und P2P-Systemen zu kombinieren. Einerseits sind PA-CDNs auf die Beiträge der Endnutzer zur Bereitstellung von Inhalten angewiesen und ermöglichen daher eine Minimierung der Infrastrukturkosten im Vergleich zu herkömmlichen CDNs. Andererseits reduzieren PA-CDNs die Nachteile von reinen P2P-Systemen, indem sie die Inhalte auf einer minimalen Anzahl von Edge-Servern replizieren und so eine zuverlässige Verteilung der Inhalte mit einer garantierten Servicequalität ermöglichen. In diesem Zusammenhang besteht die größte Herausforderung für die Forschungsgemeinschaft darin, traditionelle CDNs und P2P zu integrieren und gleichzeitig von den Vorteilen beider Systeme zu profitieren.[12][13]
Bei Peer-Assisted CDN unterscheidet man im Wesentlichen zwischen zwei Typen:
- Zentralisierte PA-CDNs: In PA-CDNs mit zentralisierter Architektur kontaktieren Nutzer zunächst die nächsten Edge-Knotenpunkte mittels des Request-Routing-Systems des CDNs. Die Edge-Server registrieren die Peers, speichern deren Metadaten in einer zentralen Datenbank und leiten Teile des angefragten Inhalts sowie eine Liste zufällig ausgewählter Peers des Content-Schwarms an den ursprünglichen Peer weiter um weitere Teile des Inhalts von diesen abfragen zu können. Kann der Peer keine Verbindung mit der geforderten Anzahl an Peers aufbauen oder die Verbindung geht verloren, wird eine neue Liste von Peers an den Client zurückgegeben. Wird ein Teil des Inhalts in einer gewissen Zeitspanne nicht an den Nutzer gesendet, wird der Request direkt vom Edge-Server erfüllt. Somit wird eine gewisse Service-Qualität garantiert und das Management des Content-Schwarms um ein vielfaches erleichtert.
- Dezentralisierte PA-CDNs: PA-CDNs mit dezentralisierter Architektur werden von designierten Tracker-Peers verwaltet, welche anhand bestimmter Kriterien (z. B.: Nähe zum Edge-Server) ausgewählt werden. Ein Peer der einem derartigen CDN-Netz beitritt kontaktiert daher zunächst einen Tracker-Peer um eine Liste aller aktiven Peers im Schwarm zu erhalten. Kann dieser Peer keine Antwort auf den Request bieten, wird dieser solange an andere Tracker-Peers weitergeleitet, bis der gewünschte Inhalt lokalisiert wurde. Wenn nicht genügend Peers zum Herunterladen der Inhalte zur Verfügung stehen, fordert der Tracker-Peer die fehlenden Videoblöcke von einem Edge-Knoten an. Dezentralisierte Architekturen minimieren die erforderliche CDN-Infrastruktur, indem sie die meisten Funktionen der Schwarmverwaltung an die Benutzer delegieren. Gleichzeitig sind dezentrale PA-CDNs anfälliger für böswillige Angriffe und schwieriger zu verwalten als ihre zentralisierten Alternativen.[14]
Public und Private CDN[Bearbeiten | Quelltext bearbeiten]
Im Allgemeinen gibt es zwei Arten von CDNs. Einerseits gibt es das öffentliche CDN und andererseits das private CDN. Das öffentliche CDN wird von einem CDN-Betreiber verwaltet und passiert auf einem Pay-as-you-use-Model, bei dem eine Gebühr pro GB erhoben wird. Zudem ist ein öffentliches CDN oft die attraktivere Option, da die Infrastruktur bereits aufgebaut ist. Ein großer Nachteil könnte sein, dass bei einer Zunahme der Nachfrage oder eine Zunahme des gehosteten Inhaltsvolumens die monatlichen Gebühren schnell eskalieren könnten und deshalb die Kosten pro GB anwachsen könnten. Aus diesem Grund wird oft auf ein privates CDN zurückgegriffen, um die Kosten besser kontrollieren zu können. Ein privates CDN wird oft bei strengen Sicherheitsanforderungen oder bei der Anforderung von großen Mengen an Inhalten verwendet. Die privaten CDNs werden mit dediziertem Server, die nicht mit anderen Organisationen geteilt werden oder in privaten Rechenzentren implementiert.
Viele Organisationen verwenden sowohl öffentliche als auch private CDN-Infrastrukturen, um Inhalte bereitzustellen zu können. Dieses Vorgehen wird als Multi-CDN- oder Hybrid-CDN-Ansatz bezeichnet.[15]
Multi-CDN-Ansatz[Bearbeiten | Quelltext bearbeiten]
Mit einem Multi-CDN-Ansatz können Unternehmen zwei oder mehr Provider kombinieren, um ein großes Netzwerk zu schaffen, das ein globales Publikum bedient. Der Vorteil ist, dass die Unternehmen Zugriff auf die geballte Leistung mehrerer Provider in jeder geografischen Region erhalten. Dadurch wird das Buffering reduziert, es führt zu einer besseren Sicherheit und es führt zu einer besseren und schnelleren Skalierbarkeit.[16] Grundsätzlich stellt ein Server die Inhalte bereit, der dem Nutzer am nächsten oder der am geeignetsten für die Anforderungen der Inhalte ist. Fällt ein Anbieter aus, wird automatisch auf das nächstbeste CDN umgestellt. Die Multi-CDN-Strategie war in der Vergangenheit nur für große Unternehmen möglich, da die Konfiguration und die Wartung mehrerer CDNs zu komplex und teuer waren. Unter allen Umständen können jetzt auch die kleineren Unternehmen durch die Automatisierung das dynamische Multi-CDN-Switching nutzen. Das Multi-CDN-Switching nutzt Echtzeitdaten, um automatisch das beste CDN auswählen zu können.[17]
Es gibt einige Vorteile, die für Multi-CDN-Ansätze sprechen:
- Ein Unternehmen kann schneller in neue Regionen und neue Märkte expandieren und sich verzweigen, indem das Unternehmen verschiedene Standorte des gesamten Netzwerks von Servern verwendet. Dadurch kann das Unternehmen schneller wachsen, mehr Benutzer und mehr Inhalte verwalten.
- Aufgrund einer besseren Leistung erzielen die Unternehmen mehr Umsatz. Der Grund ist, dass die viel bessere Ladezeit die Kunden davon abhält, zu der Konkurrenz zu wechseln. Die Verwendung mehrerer Multi-CDNs bedeutet noch mehr Leistung und weniger Latenz.
- Mit großer Wahrscheinlichkeit wird die Cloud nicht abstürzen. Mit einem Einsatz von zwei oder mehr CDN-Anbietern ist die Ausfallzeit geringer. Das wiederum bedeutet mehr Sicherheit und weniger Risiko.
- Die Unternehmen haben mehr Kontrolle über ihr eigenes Geschäft. Durch die Orchestrierung mehrerer CDN-Anbieter können genaue Kriterien festgelegt werden, die zum Beispiel zur Tageszeit bestimmte Inhalte für den Kunden zur Verfügung stellen. Zudem wechseln Multi-CDNs automatisch zu dem CDN-Anbieter, der zu jeder Zeit und an jedem Ort die bestmögliche Leistung für die Webseite zur Verfügung stellt.
Vorteile[Bearbeiten | Quelltext bearbeiten]
Schnellere Ladezeiten: Die Zwischenspeicherung von Daten im Cache der Replica-Server ermöglichen CDNs kürzere Ladezeiten. Diese kürzere Ladezeit ist wichtig für die SEO-Performance sowie für die Zufriedenheit der Nutzer.
Geringere Bandbreitenauslastung: Durch die Replica-Server sind geringere Bandbreitenauslastungen zu erwarten.
Bessere Performance: Eine geringere Bandbreitenauslastung und schnellere Ladezeiten tragen automatisch zu einer besseren Performance der Webseite bei.
Höhere Sicherheit: Die Anfragen werden durch CDNs weitergleitet, das wiederum zu einer besseren Sicherheit der zwischengespeicherten Daten beiträgt. Dadurch erreichen die DDos-Attacken und SQLis nicht den Ursprungsserver.
Spielraum für Analysen: Die CDN-Anbieter tragen einen beträchtlichen Teil des Datenverkehrs im Internet bei. Daher verfügen diese über eine Vielzahl von Daten über Nutzer, welche für Analysen genutzt werden können.
Flexible Skalierbarkeit: Die Anpassung eines CDNs an neue Bandbreitenanforderungen kann in Echtzeit geschehen, ohne mehr als die gewünschte Bandbreite zu bezahlen. Da sich der Bandbreitenbedarf von Unternehmen in kürzester Zeit ändern kann, bietet dies mehr Flexibilität.
Niedrigere Hosting-Kosten: Dank eines CDN benötigen Websites weniger Webhosting-Ressourcen, da die Verwaltung der statischen Inhalte übernommen wird. Auf diese Weise werden die Hosting-Kosten reduziert.
Zahlreiche Einsatzmöglichkeiten: Die Einsatzmöglichkeiten eines CDN sind vielfältig, so dass sich die digitalen Lösungen für Unternehmen aus den verschiedensten Branchen anbieten.[18]
Nachteile[Bearbeiten | Quelltext bearbeiten]
Höherer Aufwand: Der Aufwand für die Einrichtung und den Betrieb eines CDN ist größer, da die Daten nicht mehr auf einem zentralen Server liegen.
Mehr Einfallstore für Hacker: Das Thema Sicherheit von CDNs ist ein kritischer Punkt. Replika-Server schützen an sich den Ursprungsserver vor Angriffen, andererseits gibt es aber auch mehr Einfallstore für Hacker, weswegen die Unternehmen gerade bei sensiblen Daten besonders vorsichtig sein müssen.
Kontrollverlust: Nachdem sich die Daten nicht mehr nur auf dem eigenen Server, sondern auch auf mehreren Replika-Servern befinden, führt ein CDN auch zu einem gewissen Kontrollverlust.
Suboptimal für dynamische Inhalte: Dynamische Inhalte wie Warenkörbe verwenden eigene Datenbanken und sind daher nicht für das Caching geeignet, weswegen CDNs hier suboptimal arbeiten.
SEO-Probleme: Schnellere Ladezeiten sind gut für die Suchmaschinenoptimierung, doch ein CDN kann aus SEO-Sicht nach wie vor problematisch sein, da der Content auf Servern Dritter gehostet wird. Der Content auf dem CDN kann dadurch nicht auf dem aktuellen Stand sein.[18]
Sicherheit[Bearbeiten | Quelltext bearbeiten]
Die DDoS-Angriffe sind nicht nur enorme wirtschaftliche Verluste, sondern haben auch ernsthafte Auswirkungen auf den Ruf und das Image des betroffenen Unternehmens. Untersuchungen haben gezeigt, dass es mindestens zehn Stunden dauert, bis ein Unternehmen mit der Abwehr eines Angriffs beginnen kann.[2]
Dynamische Inhalte[Bearbeiten | Quelltext bearbeiten]
Eine Webseite verwendet dynamische Inhalte, um verschiedene und individuell angepasste Contents für den Nutzer anzuzeigen zu können. Dynamische Inhalte können zum Beispiel Warenkörbe in Online-Shops oder Streaming-Dienste sein. Diese individuell angepassten Inhalte können prinzipiell nicht in Cache-Servern gespeichert werden, da sich diese Inhalte ständig ändern. Demzufolge sind die dynamischen Inhalte für CDNs ungeeignet.[19]
Auswahl von CDN-Anbietern[Bearbeiten | Quelltext bearbeiten]
- Akamai
- Amazon Web Services (CloudFront)
- CDNetworks
- Cloudflare
- Fastly
- Host Europe
- Lumen Technologies (ehemals Level 3 Communications)
- Limelight Networks
- Microsoft Azure
- NTT Europe (NTTEO)
- PlusServer
- Swiss TXT
Open-Source-Software und freie Service-Anbieter[Bearbeiten | Quelltext bearbeiten]
MirrorBrain ist eine freie HTTP-Server-Software für Linux zum Betrieb eines CDN.
Die Inhalte von freien JavaScript-, CSS-Frameworks oder freie Iconsets werden von verschiedenen CDN-Anbietern zum freien und erlaubten Hotlinking angeboten. Google Hosted Libraries bietet bekannte Bibliotheken wie jQuery, jQuery UI, AngularJS oder Dojo Toolkit an.[20] Andere Anbieter wie Jsdelivr[21] oder cdnjs[22] bieten zusätzlich zahlreiche weitere, kleinere Bibliotheken an. Wobei Jsdelivr auch das Zusammenfassen zu einem HTTP-Request ermöglicht.[23]
Siehe auch[Bearbeiten | Quelltext bearbeiten]
- Lastverteilung (auch load balancing genannt)
- Teilstreckenverfahren
Einzelnachweise[Bearbeiten | Quelltext bearbeiten]
- ↑ How Does a CDN Work? In: CDNetworks. 29. Januar 2021, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ a b c d e Content Delivery Network Explained. 21. April 2021, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ Web (HTTP/S) Cache and Caching Proxy | CDN Guide | Imperva. In: Learning Center. Abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ CDNs vs Caching: What Are They And How Are They Different? - Ezoic. 7. Februar 2020, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ a b CDN Infrastructure Architecture and Topology | Imperva. In: Learning Center. Abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ a b Simon Edmonds: Push vs Pull - Which is the best? 5. Dezember 2016, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ Push CDN | The Differences Between Push And Pull CDNs. Abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ a b CDN Types | How to Select a CDN | Advantages of CDN. Abgerufen am 1. Juni 2022.
- ↑ Jin Li: On peer-to-peer (P2P) content delivery. In: Peer-to-Peer Networking and Applications. Band 1, Nr. 1, März 2008, ISSN 1936-6442, S. 45–63, doi:10.1007/s12083-007-0003-1 (springer.com [abgerufen am 1. Juni 2022]).
- ↑ NETWORKING 2005. Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications Systems. doi:10.1007/b136094 (springer.com [abgerufen am 1. Juni 2022]).
- ↑ Carlo Giulietti: Content Delivery in P2P networks. In: Grio Blog. 1. Oktober 2015, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
- ↑ Zhengye Liu, Yuan Ding, Yong Liu, Keith Ross: Peer-assisted distribution of User Generated Content. In: 2012 IEEE 12th International Conference on Peer-to-Peer Computing (P2P). September 2012, S. 261–272, doi:10.1109/P2P.2012.6335807 (ieee.org [abgerufen am 1. Juni 2022]).
- ↑ Ge Zhang, Wei Liu, Xiaojun Hei, Wenqing Cheng: Unreeling Xunlei Kankan: Understanding Hybrid CDN-P2P Video-on-Demand Streaming. In: IEEE Transactions on Multimedia. Band 17, Nr. 2, Februar 2015, ISSN 1520-9210, S. 229–242, doi:10.1109/TMM.2014.2383617 (ieee.org [abgerufen am 1. Juni 2022]).
- ↑ Nasreen Anjum, Dmytro Karamshuk, Mohammad Shikh-Bahaei, Nishanth Sastry: Survey on peer-assisted content delivery networks. In: Computer Networks. Band 116, April 2017, S. 79–95, doi:10.1016/j.comnet.2017.02.008 (elsevier.com [abgerufen am 1. Juni 2022]).
- ↑ SuperLumin: Private & Public Content Delivery Network Explained. In: SuperLumin. SuperLumin, abgerufen am 26. Mai 2022 (englisch).
- ↑ So führen Sie eine erfolgreiche Multi-CDN-Strategie ein - Onlineportal von IT Management. 19. Februar 2021, abgerufen am 1. Juni 2022.
- ↑ manage it | IT-Strategien und Lösungen. Abgerufen am 1. Juni 2022.
- ↑ a b asioso: Vor- und Nachteile eines Content Delivery Networks. Abgerufen am 1. Juni 2022 (deutsch).
- ↑ Was ist ein CDN? Abgerufen am 1. Juni 2022 (deutsch).
- ↑ Hosted Libraries. Abgerufen am 13. November 2021 (englisch).
- ↑ jsDelivr - A free, fast, and reliable CDN for Open Source. Abgerufen am 13. November 2021 (englisch).
- ↑ About Us - cdnjs - The #1 free and open source CDN built to make life easier for developers. Abgerufen am 13. November 2021 (englisch).
- ↑ jsDelivr - Open Source CDN. jsDelivr, 12. November 2021, abgerufen am 13. November 2021.