Technische Übersicht über Microsoft eCDN

Einführung

Microsoft eCDN betreibt ein WebRTC-basiertes Peer-to-Peer(P2P)-CDN, das HLS- und MPEG-DASH-Videostreams bereitstellt. Es ist kein zusätzliches Software-/Client-Plug-In oder Hardware erforderlich, damit die Lösung funktioniert. Sie benötigen lediglich einen HTML5-kompatiblen Webbrowser oder eine Teams Desktop-Anwendung.

Microsoft eCDN löst das Netzwerküberlastungsproblem, das bei großen Streamingereignissen wie "All-Hands-Meetings" auftritt. Wenn jeder Mitarbeiter versucht, denselben Stream gleichzeitig zu watch, wird die Office ISP-Verbindung gesättigt. Wenn Jedoch Microsoft eCDN bereitgestellt wird, wird während dieser großen Streamingereignisse ein effizientes P2P-Meshnetzwerk gebildet, das die Last der ISP-Verbindung erheblich reduziert.

Ein zu 100 % standardbasierter und nur SaaS-Dienst zu sein, bedeutet auch:

1. Die Zeit, die zum Testen und Bereitstellen von Microsoft eCDN benötigt wird, beträgt nur wenige Tage.

2. Microsoft eCDN ist grundsätzlich sicher, da es allen Microsoft O365-Sicherheitsstandards entspricht und aus JavaScript-Code besteht, der in der eingeschränkten Sandboxumgebung von Standardwebbrowsern oder dem Client der Streamingplattform ausgeführt wird.

Systemübersicht

Microsoft eCDN fungiert als Dienst, der Peers orchestriert und gleichzeitig Analysen und Kontrolle bereitstellt. Das System ist so konzipiert, dass es mit bestehenden Industriestandards und Technologien kompatibel ist. Dies bedeutet, dass es für die Arbeit mit Folgenden konzipiert ist:

• HTTP-basierte Streamingprotokolle wie HLS und MPEG-DASH.

• HTML5-basierte Videoplayer (JWPlayer, Video.js, Clappr, Kaltura usw.) und alle nativen Android- oder iOS-Player (ExoPlayer, AVPlayer usw.)

• HTTP-basierte CDNs: Akamai, Fastly, CloudFront, Cloudflare, Azure CDN usw.

• Streamingserver: Wowza, Nimble, Nginx rtmp-Modul usw.

• DRM-Technologien: Widevine, PlayReady, FairPlay usw.

• Um vollständig kompatibel mit vorhandenen Technologien und Infrastrukturen zu sein, aber dennoch in der Lage zu sein, vorhandene Technologien und Infrastrukturen zu erweitern, ist das Content Delivery-Modell, das Microsoft eCDN verwendet, ein Hybridmodell. Das heißt, jeder Viewer kann Ressourcen sowohl aus dem P2P-Netzwerk als auch aus dem HTTP-Netzwerk gleichzeitig herunterladen.

Auf hoher Ebene besteht das eCDN-System aus:

• Peeringermittlungsdienst: Verantwortlich für die Peerermittlung.

• Switchboard: Verantwortlich für das Erstellen der anfänglichen P2P-Verbindungen zwischen Viewern.

• Datenpipeline: Nutzt alle Diensttelemetriedaten und speichert sie für die Analysenutzung in einem Data Warehouse.

• Player-Plug-In: Verantwortlich für das Abfangen und Weiterleiten von videobezogenen Anforderungen an das Client-SDK.

• Client SDK: Verantwortlich für die intelligente Anforderung von Videoressourcen von HTTP/P2P und das Zusammenfügen der Datenpuffer in Echtzeit.

  • Das Client-SDK stellt eine Verbindung mit dem Back-End her (Peeringermittlungsdienst, Switchboard, Datenpipeline).

  • Der Ermittlungsdienst sendet dem Client SDK eine Gruppe von Peers, von denen er glaubt, dass sie für diesen bestimmten Viewer von Vorteil sein werden. Peers werden basierend auf Netzwerknähe, Cachezuordnung, Stream-Relevanz und anderen Parametern ausgewählt.

  • Das Client-SDK stellt webRTC-Datenkanalverbindungen mit dem angegebenen Satz von Peers mithilfe der Switchboard her.

  • HTTP-Anforderungen, die vom Videoplayer generiert werden, werden vom Player-Plug-In abgefangen und an das Microsoft eCDN Client SDK weitergeleitet, das basierend auf Echtzeitmessungen entscheidet, ob die gewünschte Ressource aus dem P2P-Netzwerk oder von HTTP oder gleichzeitig von beiden abgerufen werden soll, um diese Ressource auf die effizienteste und zeitnahe Weise an den Player zurückzugeben.

  • Manifestanforderungen, DRM-Lizenz und Verschlüsselung werden immer vom HTTP-Edgeserver abgerufen, um die aktuellste Kopie zu erhalten und autorisierungsmechanismen einzuhalten.

  • Unabhängig davon fordert das Client SDK die Autorisierung an, um Peerverbindungen über das Microsoft eCDN-Back-End zu erstellen. Nach der Autorisierung beginnt das Client SDK mit dem Herunterladen von Ressourcen von HTTP und P2P.

Übersicht über Clientlogik

Das Client-SDK ruft Inhalte gleichzeitig aus HTTP- und P2P-Quellen ab. Dies bedeutet, dass die Benutzererfahrung nicht durch Segmente beeinträchtigt wird, die nicht rechtzeitig abgerufen wurden, oder weil die Verbindungsgeschwindigkeit der P2P-Quelle nicht ausreicht.

Sicherheit

Microsoft eCDN entspricht den Microsoft O365-Sicherheitsstandards.

Der Dienst ist genauso sicher wie jeder herkömmliche serverbasierte CDN-Dienst. Da es sich um eine Hybridlösung handelt, die eCDN in Kombination mit einem herkömmlichen HTTP-Server verwendet, nutzen wir die vorhandene Sicherheitsinfrastruktur (Token, Schlüssel, Cookies usw.), die ein Kunde bereits eingerichtet hat.

In Bezug auf die Kommunikation sind Peers über den WebRTC-Datenkanal miteinander verbunden, bei dem es sich um eine sichere Pipe handelt, die das SCTP-Protokoll über DTLS-Verschlüsselung verwendet. Darüber hinaus ist jeder Viewer über eine sichere Websocket-Verbindung, die TLS-Verschlüsselung verwendet, mit dem Back-End verbunden. Daher können weder die zwischen Viewern gesendeten Daten noch die zwischen den einzelnen Viewern und dem Back-End gesendeten Metadaten kompromittiert werden.

In Bezug auf die Streamsicherheit gibt es mehrere Szenarien:

Authentifizierung beim Sitzungsstart

In diesem Fall beginnt jede Sitzung damit, dass der Server den Viewer nach einer Benutzer-ID und einem Kennwort fragt. Wenn diese Anmeldeinformationen gültig sind, sendet der Server die Manifestdatei an den Viewer, und der Videoplayer beginnt mit der Anforderung von Segmenten und zusätzlichen Manifesten vom HTTP-Server entsprechend. Microsoft eCDN fügt sich nicht in den Validierungsprozess ein, und der Viewer muss die gleichen Authentifizierungsgates durchlaufen, unabhängig davon, ob Microsoft eCDN bereitgestellt wird. Nur Zuschauer, die für einen Stream autorisiert sind, können an der P2P-Freigabe für diesen Stream teilnehmen und nur teilen, während sie den Stream tatsächlich ansehen.

URL-Zeittokenisierung

In diesem Fall verfügt die Manifest-URL über ein zusätzliches Token, das einige Details zum Benutzer-Agent des Viewers (IP-Adresse, Ablaufzeit usw.) codiert. Ein böswilliger Benutzer, der eine Manifest-URL entweder durch Anmeldung oder auf andere Weise abruft, kann sie an nicht autorisierte Viewer verteilen, aber diese Viewer können nicht auf den Stream zugreifen, da die Manifest-URL tokenisiert wird und der HTTP-Server überprüfungsversuche ablehnt, entweder aufgrund von IP-Adressen oder anderen Benutzer-Agent-Übereinstimmungen oder aufgrund eines Zeitablaufs. Mit Microsoft eCDN werden alle Manifestanforderungen direkt an den HTTP-Server gesendet, sodass die Überprüfung nicht kompromittiert werden kann.

Schutz von Videosegmentinhalten

Nicht autorisierte Benutzer, die Zugriff auf die Stream-URLs erhalten, können weiterhin versuchen, über andere Peers auf den Inhalt der Videosegmente zuzugreifen. Für den Fall, dass die Segmente unverschlüsselt sind, besteht das folgende Risiko: Der nicht autorisierte Benutzer kann die URL eines Segments von einem anderen Benutzer erhalten, andere Peers finden, die über diese relevante Ressource verfügen, und versuchen, diese Ressource direkt von diesen Benutzern anzufordern (obwohl der Medienserver/CDN den Zugriff auf diese Ressource nicht zulassen würde).

Wenn die Inhaltstokenisierung aktiviert ist, stellen wir sicher, dass der Benutzer auf Ressourcenebene authentifiziert wird, bevor andere Peers Daten an diesen Benutzer senden können. Dies ist ein präziser Mechanismus, der den Zugriff auf bestimmte Ressourcen gewähren und den Zugriff auf andere Ressourcen in derselben Sitzung ablehnen kann.

Weitere Schutzmaßnahmen umfassen die Verschlüsselung:

Verschlüsselung

Nehmen wir beispielsweise einen HLS-Stream, der mit AES-128-Verschlüsselung geschützt ist. Böswillige Benutzer können die Manifest-URL an nicht autorisierte Zuschauer oder sogar an die Videosegmente selbst senden, aber solange die nicht autorisierten Zuschauer keinen Zugriff auf den Entschlüsselungsschlüssel haben, können sie den Stream nicht watch. Der Schlüssel kann auf vielfältige Weise an den Endbenutzer gesendet werden, z. B. über das Standard Manifest, über die HTML-Seite oder einen anderen Pfad. Unabhängig davon fügt sich der Dienst nicht selbst in diesen Prozess ein, und der Schlüssel wird mit demselben Mechanismus an den Videoplayer übermittelt, unabhängig davon, ob der Dienst bereitgestellt wird. Dies bedeutet, dass der Schlüssel mit oder ohne Microsoft eCDN genauso sicher ist.

DRM

Der DRM-Anwendungsfall ähnelt dem Verschlüsselungsanwendungsfall. Der einzige Unterschied besteht darin, dass die Lizenz und die Schlüssel vom DRM-Mechanismus statt vom Sender verteilt werden. Auch hier stört Microsoft eCDN nicht die Verteilung der Lizenz oder der Schlüssel und gefährdet sie daher nicht.