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
Links: Verteilung über Einzelserver
Rechts: CDN-Schema

Ein Content Delivery Network (CDN), oder auch Content Distribution Network, sehr selten auch Inhaltszustellnetz 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 Standorte 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 sowie Cloud Intelligence. CDN-Dienste können in den Bereichen Sicherheit, DDoS-Schutz und Web Application Firewalls (WAF) sowie WAN-Optimierung angewendet werden.

Funktionsweise

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

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.
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 ein 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.

Im Wesentlichen gibt es 3 Typen von Inhalten:

Dynamic content (Dynamische Inhalte)
dynamische_Webseiten, 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 Computergrafik, CSS, JavaScript oder ganze statische Webseiten.
Streaming content (Streaming-Inhalte)
Die Streaming Media, die mit Hilfe einer Webbrowser-Steuerung wiedergegeben werden.

Caching

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.

CDN-Topologien

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.

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.

CDN-Arten

Content-Delivery-Netzwerke können auf unterschiedlichen Bereitstellungsprinzipien basieren:

Origin Push CDN

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.

Ein 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. Push-CDNs sind bei relativ statischen Webseiten mit großen eingebetteten Datenmengen zu bevorzugen.

Origin Pull CDNs

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.

Peer-to-Peer CDN

P2P-Netzwerk

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.

Peer-Assisted CDN

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.

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.

Public und Private CDN

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 basiert auf einem Pay-as-you-use-Modell, 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 einer 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 dedizierten Servern, die nicht mit anderen Organisationen geteilt werden, oder in privaten Rechenzentren implementiert.

Viele Organisationen verwenden sowohl öffentliche als auch private CDN-Infrastrukturen, um Inhalte bereitstellen zu können. Dieses Vorgehen wird als Multi-CDN- oder Hybrid-CDN-Ansatz bezeichnet.

Multi-CDN-Ansatz

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. 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.

Es gibt einige Vorteile, die für Multi-CDN-Ansätze sprechen:

Sicherheit

DDoS-Angriffe können enorme wirtschaftliche Verluste verursachen und dem Ruf des Unternehmens schaden. Eine weitere Gefahr entsteht, wenn – wie bislang üblich – CDN-Anbieter und Shared-Hosting-Betreiber viele Webseiten auf denselben Servern mit denselben IP-Adressen speichern. Das Routing zur Zielseite erfolgt erst nach Entschlüsselung der Daten. Angreifer können eine Anfrage an die IP-Adresse einer vertrauenswürdigen Seite oder Applikation auf einem Netzwerkknoten erzwingen, auf der sich auch eine von ihnen kontrollierte Seite oder Anwendung befindet. Mit diesen „Underminr“-Angriffen können Anfragen an Steuerrechner von Botnetz-Servern getarnt werden. Davor schützt die Trennung der Kunden auf einem Knoten (Tenant Isolation). Bis 2018 wurden Angriffe in ähnlicher Weise getarnt mittels Domain Fronting. Dabei gaben Angreifer im TLS-Handshake über die Server Name Indication (SNI) eine legitime Domain an – im HTTP-Header dagegen steckte ihre Zieladresse. Aufgrund des formal korrekten Handshakes gelangten Anfragen durch Firewalls und wurden erst im CDN entschlüsselt und an die im HTTP-Header angegebene Zieladresse geleitet. Domain Fronting gilt seit 2018 als unterbunden, da große Hoster Header und SNI exakt abgleichen.

Dynamische Inhalte

Eine Webseite verwendet dynamische Inhalte, um verschiedene und individuell angepasste Contents für den Nutzer anzeigen 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.

Auswahl von CDN-Anbietern

Open-Source-Software und freie Service-Anbieter

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. Andere Anbieter wie Jsdelivr oder cdnjs bieten zusätzlich zahlreiche weitere, kleinere Bibliotheken an. Wobei Jsdelivr auch das Zusammenfassen zu einem HTTP-Request ermöglicht.

Siehe auch

Einzelnachweise

  1. ↑ So in der NIS-2-Richtlinie oder BR-Drs. 166/24 (PDF; 0,9 MB)
  2. ↑ How Does a CDN Work? In: CDNetworks. 29. Januar 2021, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  3. 1 2 3 4 5 Content Delivery Network Explained. In: globaldots.com. 21. April 2021, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  4. ↑ Web (HTTP/S) Cache and Caching Proxy. In: CDN Guide, Learning Center. Imperva, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  5. ↑ CDNs vs Caching: What Are They And How Are They Different? – Ezoic. 7. Februar 2020, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  6. 1 2 CDN Infrastructure – Architecture and Topology. In: Learning Center. Imperva, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  7. 1 2 Simon Edmonds: Push vs Pull – Which is the best? In: cdn.net. 5. Dezember 2016, archiviert vom Original (nicht mehr online verfügbar) am 21. März 2022; abgerufen am 1. Juni 2022 (amerikanisches Englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
  8. ↑ Push CDN | The Differences Between Push And Pull CDNs. In: belugacdn.com. Abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  9. 1 2 CDN Types – How to Select a CDN – Advantages of CDN. In: techlineinfo.com. Abgerufen am 1. Juni 2022.
  10. ↑ 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).
  11. ↑ 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]).
  12. ↑ Carlo Giulietti: Content Delivery in P2P networks. In: Grio Blog. 1. Oktober 2015, abgerufen am 1. Juni 2022 (amerikanisches Englisch).
  13. ↑ 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]).
  14. ↑ 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]).
  15. ↑ 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]).
  16. ↑ Private & Public Content Delivery Network Explained. SuperLumin, abgerufen am 26. Mai 2022 (englisch).
  17. ↑ So führen Sie eine erfolgreiche Multi-CDN-Strategie ein. In: it-daily.net. 19. Februar 2021, abgerufen am 1. Juni 2022.
  18. ↑ manage it. In: ap-verlag.de. Abgerufen am 1. Juni 2022.
  19. ↑ ADAMnetworks’ Research Uncovers Vulnerability in Internet Infrastructure, Affecting 88 Million Domains. In: ap-Businesswire.com. Abgerufen am 26. Mai 2026.
  20. ↑ ‘Underminr’ Vulnerability Lets Attackers Hide Malicious Connections Behind Trusted Domains. In: Securityweek.com. Abgerufen am 26. Mai 2026.
  21. ↑ Was ist ein CDN? In: myrasecurity.com. Abgerufen am 1. Juni 2022.
  22. ↑ Hosted Libraries. In: developers.google.com. Abgerufen am 13. November 2021 (englisch).
  23. ↑ jsDelivr. In: jsdelivr.com. Abgerufen am 13. November 2021 (englisch).
  24. ↑ About Us. cdnjs, abgerufen am 13. November 2021 (englisch).
  25. ↑ jsDelivr. In: github.com. 12. November 2021, abgerufen am 13. November 2021.