Was ist ein eCDN?

Ein unternehmensinternes Netzwerk zur Inhaltsauslieferung verteilt Inhalte im privaten Netzwerk einer Organisation. Es kann Caches, Multicast, Peer-Auslieferung oder strategisch platzierte Edge-Knoten nutzen, um wiederholten Datenverkehr zu vorgelagerten Systemen zu begrenzen.

HTTP-Videostreaming nutzt Unicast: Wie Microsoft für Teams-Veranstaltungen beschreibt, erhält jeder Zuschauer einen eigenen Stream aus dem Internet. Wenn ein großer Teil der Beschäftigten eines Bürostandorts dieselbe Mitarbeiterversammlung verfolgt, konkurrieren diese identischen Streams um dasselbe Internet-Gateway oder dieselbe WAN-Verbindung. Ein eCDN ermöglicht es den meisten Zuschauern an einem Standort, das Video stattdessen aus dem internen Netzwerk zu beziehen, und nutzt dafür eine von drei Methoden. Bei Peer-to-Peer-eCDNs tauschen die Browser oder Apps der Zuschauer Videosegmente über WebRTC-Datenkanäle im LAN untereinander aus, koordiniert durch einen Cloud-Dienst. Cache-basierte eCDNs platzieren einen Video-Cache am Standort, der Zuschauer in der Nähe versorgt. Multicast-eCDNs senden einen einzigen Stream in ein multicastfähiges Netzwerk, dem jeder Empfänger beitritt. In allen Fällen stammt das Video weiterhin aus einer vorgelagerten Quelle, typischerweise dem Internet-CDN der Streaming-Plattform. Peer-to-Peer-eCDNs nutzen dieses CDN auch als Ausweichlösung: Im Konzept von Microsoft lädt beispielsweise jeder Zuschauer weiterhin einige Segmente über HTTP herunter, und Manifeste sowie DRM-Lizenzen kommen immer vom HTTP-Server, damit die Autorisierung der Plattform weiterhin greift. Anders als bei einem öffentlichen CDN, dessen Edge-Standorte sich nach der weltweiten geografischen Verteilung des Publikums richten, folgt die Topologie eines eCDN den Standorten, Subnetzen und VPNs der Organisation.

Peer-to-Peer, Cache oder Multicast: Welche Anforderungen stellen sie jeweils an das Netzwerk? Peer-to-Peer benötigt keine Server vor Ort, aber Peers müssen einander innerhalb des LAN direkt über UDP und den Koordinationsdienst des Anbieters über HTTPS und WebSocket erreichen können. Microsoft geht davon aus, dass TLS-Inspektion diese WebSocket-Verbindung beeinträchtigt, und empfiehlt, seine Domains davon auszunehmen. Ein Cache-basiertes eCDN benötigt einen Cache-Server am Standort der Zuschauer. OmniCache von Ramp ist laut der Dokumentation von Brightcove eine Software-Appliance für den Betrieb vor Ort: Ein Plug-in im Webplayer schreibt die Stream-URL so um, dass Desktop- und Mobilgeräte die Daten aus dem Cache beziehen. Dieser ruft alles, was er noch nicht enthält, vom CDN der Plattform ab. Multicast benötigt Router, die ein Multicast-Routingprotokoll ausführen, und Hosts, die ihre Gruppenmitgliedschaft signalisieren. Die Implementierung von Ramp erfordert außerdem einen Server vor Ort und einen Empfangsclient auf jedem Zuschauerrechner. Dafür benötigt sie laut Ramp unabhängig von der Größe des Publikums nur die Bandbreite eines einzelnen Zuschauers. Anbieter kombinieren die Methoden: Der Player von Ramp kann auf einen lokalen Cache zurückgreifen, wenn der Empfangsclient oder der Multicast-Stream nicht verfügbar ist.
Funktioniert browserbasiertes Peering ohne Änderungen an den Clients? Oft nicht. Browser verbergen lokale IP-Adressen in WebRTC hinter mDNS-Namen. Deshalb bezeichnet die Einrichtungsanleitung von Microsoft die Richtlinie WebRtcLocalIpsAllowedUrls in Chrome und Edge, die dem Dienst lokale IP-Adressen offenlegt, als erforderliche Komponente, damit der Browserclient am Peering teilnehmen kann (die Teams-Desktop-App ist nicht betroffen). Auch die von Vimeo veröffentlichten Anforderungen von Kollective besagen, dass die Peering-Effizienz ohne eine entsprechende Richtlinie begrenzt ist. Dieselbe Anleitung verlangt die Konfiguration einer zweiten Richtlinie, LocalNetworkAccessAllowedForUrls, die den aufgeführten Websites den Zugriff auf Endpunkte im lokalen Netzwerk erlaubt. Ohne sie können Browserclients laut Microsoft möglicherweise keine Peer-Verbindungen aufbauen. Die Anweisungen von Microsoft legen beide Richtlinien über die Windows-Registrierung fest und beschreiben, wie Kunden die erste mithilfe von Gruppenrichtlinien oder einem Endgeräteverwaltungssystem wie Intune in großem Maßstab ausrollen. Geräte, die nicht am Peering teilnehmen können, werden nicht blockiert. Sie greifen auf die gewöhnliche Auslieferung durch den Server zurück. Genau diese Last sollte das eCDN beseitigen.
Wie bleibt Peering auf einen Standort beschränkt und außerhalb des VPN? Durch den Koordinationsdienst und die Subnetzkonfiguration. Der Dienst von Microsoft erfasst, welche Peers im Netzwerk benachbart sind, verbindet keine Peers, die er unterschiedlichen Standorten zuordnet, und kann anhand einer vom Kunden bereitgestellten Subnetzzuordnung Peering nach lokaler IP-Adresse erzwingen. Dieselbe Zuordnung kann WLAN-Clients daran hindern, Daten zu Peers hochzuladen, um ihre Upload-Verbindung nicht zu überlasten. Für VPN-Nutzer empfiehlt Microsoft Split-Tunneling und das Abschalten von Peering für VPN-Subnetze. Vimeo gibt für Kollective und Hive Streaming dieselbe Empfehlung, damit Peers Videos nicht über den VPN-Konzentrator austauschen. Subnetzregeln wirken auf die Adresse, die der Dienst sieht: Microsoft warnt, dass die Browserrichtlinie für lokale IP-Adressen nur den am höchsten priorisierten Netzwerkadapter eines Geräts offenlegt. Daher kann ein Zuschauer im Browser mit mehreren Adaptern, etwa bei einem dauerhaft aktiven VPN, der falschen Subnetzgruppe zugeordnet werden. Beziehen Sie Browser mit VPN-Verbindung in den Test vor der Veranstaltung ein und prüfen Sie, welcher Gruppe sie zugeordnet werden. Bei ausgeschaltetem Peering bezieht jeder VPN-Zuschauer weiterhin einen eigenen Stream. Bei einem erzwungenen (vollständigen) Tunnel wird dieser Stream durch die VPN-Infrastruktur geleitet, sofern für ihn keine direkte Route eingerichtet ist. Microsoft veröffentlicht eine solche Ausnahme für den Datenverkehr der Teilnehmer an Teams-Veranstaltungen. Zur Zugriffskontrolle erklärt Microsoft, dass nur Zuschauer, die von der Videoplattform authentifiziert wurden, dem Peer-Netzwerk beitreten und dass Peer-Verbindungen mit DTLS verschlüsselt sind.
Woran erkennen Sie, dass das eCDN die externe Anbindung tatsächlich entlastet? Nicht an einer erfolgreichen Wiedergabe, denn der Rückgriff auf die HTTP-Auslieferung erfolgt automatisch. Entscheidend ist der Anteil der Bytes, die innerhalb des Netzwerks ausgeliefert werden. Das Dashboard von Microsoft zeigt neben erneutem Puffern die Peer-to-Peer-Effizienz als Verhältnis der von Peers gelieferten Bytes zu den gesamten Bytes an. Im durchgerechneten Beispiel benötigt ein Stream mit 2 Mbps für 1.000 Zuschauer ohne Entlastung 2 Gbps und bei einer Effizienz von 90 % nur 200 Mbps. Testen Sie vor der Veranstaltung mit einer realistischen Zahl gleichzeitiger Zuschauer: Microsoft bietet einen stillen Test an, der eine Live-Veranstaltung simuliert, und weist darauf hin, dass die erreichbare Entlastung bei zwei Zuschauern auf 50 % und bei drei auf 67 % begrenzt ist. Wenige Testrechner bilden das Ergebnis daher zu niedrig ab.

Setzen Sie ein eCDN ein, wenn große interne Livestreams sonst die Netzwerkverbindungen des Unternehmens auslasten würden. Die Auslieferungsmethode muss zu den Vorgaben für Firewall, Topologie, Geräte und Datenschutz passen, sonst greifen Clients möglicherweise wieder auf Datenverkehr vom Origin-Server zurück.

Was ist ein eCDN?

So funktionieren eCDNs

Wichtige Fakten

Wann eCDNs wichtig sind

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline