Vue d’ensemble technique de Microsoft eCDN
Introduction
Microsoft eCDN exploite un CDN P2P (peer-to-peer) basé sur WebRTC qui fournit des flux vidéo HLS et MPEG-DASH. Aucun logiciel/plug-in client ou matériel supplémentaire n’est nécessaire pour que la solution fonctionne. Tout ce dont vous avez besoin est un navigateur web compatible HTML5 ou une application de bureau Teams.
Microsoft eCDN résout le problème de congestion du réseau qui se produit lors d’événements de diffusion en continu importants tels que les réunions à main. Si chaque employé tente d’watch le même flux en même temps, le lien du fai de bureau devient saturé. Toutefois, lorsque Microsoft eCDN est déployé, un réseau de maillage P2P efficace est formé pendant ces événements de diffusion en continu volumineux, ce qui réduit considérablement la charge sur la liaison isp.
Être un service 100 % basé sur des normes et SaaS uniquement signifie également :
Le temps nécessaire pour tester et déployer Microsoft eCDN n’est que de quelques jours.
Microsoft eCDN est intrinsèquement sécurisé, car il suit toutes les normes de sécurité Microsoft O365 et se compose de code JavaScript, qui s’exécute dans l’environnement limité et bac à sable (sandbox) des navigateurs Web standard ou du client de la plateforme de streaming.
Vue d’ensemble du système
Microsoft eCDN fonctionne comme un service qui orchestre les pairs tout en fournissant l’analytique et le contrôle. Le système est conçu pour être compatible avec les normes et technologies existantes du secteur. Cela signifie qu’il est conçu pour fonctionner avec :
Protocoles de diffusion en continu basés sur HTTP, tels que HLS et MPEG-DASH.
Lecteurs vidéo HTML5 (JWPlayer, Video.js, Clappr, Kaltura, etc.) et tout lecteur Android ou iOS natif (ExoPlayer, AVPlayer, etc.)
CDN basés sur HTTP : Akamai, Fastly, CloudFront, Cloudflare, Azure CDN, etc.
Serveurs de streaming : Wowza, Nimble, module rtmp Nginx, etc.
Technologies DRM : Widevine, PlayReady, FairPlay, etc.
Afin d’être entièrement compatible avec les technologies et l’infrastructure existantes, le modèle de distribution de contenu que Microsoft eCDN utilise est hybride. Autrement dit, chaque visionneuse peut télécharger des ressources à partir du réseau P2P et du réseau HTTP simultanément.
À un niveau général, le système eCDN se compose des points suivants :
Service de découverte de peering : responsable de la découverte d’homologues.
Standard : responsable de la création des connexions P2P initiales entre les visionneuses.
Pipeline de données : consomme toutes les données de télémétrie de service et les stocke dans un entrepôt de données pour la consommation analytique.
Plug-in lecteur : responsable de l’interception et du transfert des demandes vidéo vers le Kit de développement logiciel (SDK) client.
Kit de développement logiciel (SDK) client : responsable de la demande intelligente de ressources vidéo à partir de HTTP/P2P et de l’assemblage des mémoires tampons de données en temps réel.
Le Kit de développement logiciel (SDK) client se connecte au back-end (service de découverte de peering, standard standard, pipeline de données).
Le service de découverte envoie au Kit de développement logiciel (SDK) client un ensemble d’homologues qui, selon lui, profiteront à cette visionneuse particulière. Les homologues sont sélectionnés en fonction de la proximité du réseau, de l’allocation du cache, de la pertinence du flux, entre autres paramètres.
Le Kit de développement logiciel (SDK) client établit des connexions de canal de données WebRTC avec l’ensemble d’homologues spécifié à l’aide du Standard standard.
Les requêtes HTTP générées par le lecteur vidéo sont interceptées par le plug-in Player et transférées au Kit de développement logiciel (SDK) client Microsoft eCDN, qui décide, sur la base de mesures en temps réel, s’il faut extraire la ressource souhaitée du réseau P2P ou du protocole HTTP ou des deux simultanément afin de fournir cette ressource au lecteur de la manière la plus efficace et la plus rapide possible.
Les demandes de manifeste, la licence DRM et le chiffrement sont toujours récupérés à partir du serveur edge HTTP afin d’obtenir la copie la plus actuelle et de respecter les mécanismes d’autorisation.
Indépendamment, le Kit de développement logiciel (SDK) client demande l’autorisation de créer des connexions d’homologues à partir du back-end Microsoft eCDN. Une fois autorisé, le Kit de développement logiciel (SDK) client commence à télécharger des ressources à partir de HTTP et P2P.
Vue d’ensemble de la logique cliente
Le Kit de développement logiciel (SDK) client extrait simultanément le contenu à partir de sources HTTP et P2P. Cela signifie que l’expérience utilisateur ne sera pas affectée négativement par les segments qui n’ont pas été extraits dans le temps ou parce que la vitesse de connexion de la source P2P est insuffisante.
Sécurité
Microsoft eCDN est conforme aux normes de sécurité Microsoft O365.
Le service est aussi sécurisé que n’importe quel service CDN basé sur un serveur traditionnel. Étant donné qu’il s’agit d’une solution hybride, qui utilise eCDN en combinaison avec un serveur HTTP traditionnel, nous utilisons l’infrastructure de sécurité existante (jetons, clés, cookies, etc.) qu’un client a déjà en place.
En termes de communication, les homologues sont connectés les uns aux autres via le canal de données WebRTC, qui est un canal sécurisé qui utilise le protocole SCTP sur le chiffrement DTLS. En outre, chaque visionneuse est connectée au back-end via une connexion Websocket sécurisée qui utilise le chiffrement TLS. Par conséquent, ni les données envoyées entre les visionneuses ni les métadonnées envoyées entre chaque visionneuse et le back-end ne peuvent être compromises.
En termes de sécurité de flux, il existe plusieurs scénarios :
Authentification au démarrage de session
Dans ce cas, chaque session commence par le serveur demandant à la visionneuse un ID utilisateur et un mot de passe. Si ces informations d’identification sont valides, le serveur envoie le fichier manifeste à la visionneuse et le lecteur vidéo commence à demander des segments et des manifestes supplémentaires à partir du serveur HTTP en conséquence. Microsoft eCDN ne s’insère pas dans le processus de validation et la visionneuse doit passer par les mêmes portes d’authentification, que Microsoft eCDN soit déployé ou non. Seuls les téléspectateurs autorisés pour un flux peuvent participer au partage P2P pour ce flux et ils partagent uniquement pendant qu’ils regardent réellement le flux.
Tokenisation chronométrée d’URL
Dans ce cas, l’URL du manifeste comporte un jeton supplémentaire, qui encode quelques détails sur l’agent utilisateur de la visionneuse (adresse IP, heure d’expiration, etc.). Un utilisateur malveillant qui obtient d’une manière ou d’une autre une URL de manifeste par le biais de la connexion ou d’autres manières peut la distribuer à des utilisateurs non autorisés, mais ces visionneuses ne pourront pas accéder au flux, car l’URL du manifeste est tokenisée et le serveur HTTP rejette toute tentative de validation, soit en raison d’adresses IP ou d’autres incompatibilités d’agent utilisateur, soit en raison de l’expiration du délai d’expiration. Avec Microsoft eCDN, toutes les demandes de manifeste sont envoyées directement au serveur HTTP afin que la validation ne puisse pas être compromise.
Protection du contenu de segment vidéo
Les utilisateurs non autorisés qui accèdent aux URL de flux peuvent toujours tenter d’accéder au contenu des segments vidéo via d’autres homologues. Dans le cas où les segments ne sont pas chiffrés, le risque suivant existe : l’utilisateur non autorisé peut recevoir l’URL d’un segment d’un autre utilisateur, rechercher d’autres homologues disposant de cette ressource pertinente et tenter de demander cette ressource directement à ces utilisateurs (même si le serveur multimédia/CDN n’autorise pas l’accès à cette ressource).
Lorsque la création de jetons de contenu est activée, nous nous assurons que l’utilisateur est authentifié au niveau de la ressource avant que d’autres homologues puissent envoyer des données à cet utilisateur. Il s’agit d’un mécanisme granulaire qui peut accorder l’accès à certaines ressources et refuser l’accès à d’autres ressources sur la même session.
D’autres mesures de protection incluent le chiffrement :
Chiffrement
Prenons, par exemple, un flux HLS protégé par le chiffrement AES-128. Les utilisateurs malveillants peuvent envoyer l’URL du manifeste à des visionneuses non autorisées, ou même aux segments vidéo eux-mêmes, mais tant que les utilisateurs non autorisés n’ont pas accès à la clé de déchiffrement, ils ne pourront pas watch le flux. La clé peut être envoyée à l’utilisateur final de nombreuses façons, par exemple via le manifeste main, via la page HTML ou un autre chemin d’accès. Quoi qu’il en soit, le service ne s’insère pas dans ce processus et la clé est remise au lecteur vidéo à l’aide du même mécanisme, que le service soit déployé ou non, ce qui signifie que la clé est tout aussi sécurisée avec ou sans Microsoft eCDN.
DRM
Le cas d’utilisation drm ressemble au cas d’usage du chiffrement. La seule différence est que la licence et les clés sont distribuées par le mécanisme DRM plutôt que par le diffuseur. Ici aussi, Microsoft eCDN n’interfère pas avec la distribution de la licence ou des clés et ne les compromet donc pas.