Qu’est-ce qu’un eCDN ?

Un réseau de diffusion de contenu d’entreprise distribue des contenus au sein du réseau privé d’une organisation. Il peut utiliser des caches, la multidiffusion, la diffusion entre pairs ou des nœuds de périphérie placés stratégiquement pour limiter le trafic amont répété.

La vidéo en streaming sur HTTP utilise la monodiffusion : comme le décrit Microsoft pour les événements Teams, chaque spectateur reçoit un flux individuel depuis Internet. Lorsqu’une grande partie d’un bureau regarde la même réunion générale, ces flux identiques se disputent la même passerelle Internet ou liaison WAN. Un eCDN permet à la plupart des spectateurs d’un site d’obtenir plutôt la vidéo depuis l’intérieur du réseau, selon l’une de trois méthodes. Les eCDN pair à pair font échanger des segments vidéo entre les navigateurs ou les applications des spectateurs via des canaux de données WebRTC sur le LAN, sous la coordination d’un service cloud. Les eCDN avec mise en cache installent sur un site un cache vidéo qui dessert les spectateurs à proximité. Les eCDN à multidiffusion envoient un seul flux sur un réseau prenant en charge la multidiffusion, auquel chaque récepteur se joint. Dans chaque cas, la vidéo provient toujours de l’amont, généralement du CDN Internet de la plateforme de streaming. Les eCDN pair à pair utilisent aussi ce CDN comme solution de repli : dans la conception de Microsoft, par exemple, chaque spectateur télécharge encore certains segments via HTTP, et les manifestes ainsi que les licences DRM proviennent toujours du serveur HTTP afin que le contrôle d’autorisation propre à la plateforme continue de s’appliquer. Contrairement à un CDN public, dont les points de présence en périphérie suivent la répartition géographique mondiale du public, la topologie d’un eCDN suit les sites, les sous-réseaux et les VPN de l’organisation.

Pair à pair, cache ou multidiffusion : qu’exige chaque méthode du réseau ? Le pair à pair ne nécessite aucun serveur sur site, mais les pairs doivent pouvoir communiquer directement entre eux via UDP au sein du LAN et accéder au service de coordination du fournisseur via HTTPS et WebSocket ; Microsoft s’attend à ce que l’inspection TLS perturbe cette connexion WebSocket et recommande d’exempter ses domaines de cette inspection. Un eCDN avec mise en cache nécessite un serveur de cache déployé là où se trouvent les spectateurs. OmniCache de Ramp, tel que le décrit Brightcove, est une appliance logicielle sur site : une extension du lecteur web réécrit l’URL du flux afin que les ordinateurs et les appareils mobiles récupèrent le contenu depuis le cache, qui obtient auprès du CDN de la plateforme tout ce qu’il ne détient pas déjà. La multidiffusion nécessite des routeurs exécutant un protocole de routage multidiffusion et des hôtes signalant leur appartenance aux groupes, ainsi que, dans l’implémentation de Ramp, un serveur sur site et un client récepteur sur chaque ordinateur de visionnage ; en contrepartie, Ramp indique qu’elle n’utilise que la bande passante d’un seul spectateur, quelle que soit la taille du public. Les fournisseurs combinent les méthodes : le lecteur de Ramp peut se replier sur un cache local lorsque le récepteur ou le flux multidiffusion est indisponible.
Les échanges entre pairs dans le navigateur fonctionnent-ils sans modification des clients ? Souvent, non. Les navigateurs masquent les adresses IP locales à WebRTC derrière des noms mDNS ; le guide de configuration de Microsoft présente donc la politique WebRtcLocalIpsAllowedUrls dans Chrome et Edge, qui expose les adresses IP locales à son service, comme un composant obligatoire pour que son client navigateur participe aux échanges entre pairs (l’application de bureau Teams n’est pas concernée), et les exigences de Kollective publiées par Vimeo indiquent que l’efficacité des échanges entre pairs est limitée sans politique équivalente. Le même guide indique qu’une seconde politique, LocalNetworkAccessAllowedForUrls, qui permet aux sites répertoriés d’accéder aux points de terminaison du réseau local, doit aussi être configurée ; sans elle, selon Microsoft, les clients navigateur peuvent être empêchés d’établir des connexions entre pairs. Les instructions de Microsoft configurent les deux politiques via le registre Windows et décrivent le déploiement à grande échelle de la première par les clients à l’aide d’une stratégie de groupe ou d’un système de gestion des terminaux tel qu’Intune. Les appareils qui ne peuvent pas échanger entre pairs ne sont pas bloqués. Ils se replient sur la diffusion classique depuis le serveur, ce qui représente précisément la charge que l’eCDN devait supprimer.
Comment maintenir les échanges entre pairs à l’intérieur d’un site et hors du VPN ? Grâce au service de coordination et à la configuration des sous-réseaux. Le service de Microsoft cartographie le voisinage des pairs sur le réseau, ne relie pas les pairs qu’il détecte sur des sites différents et peut imposer des échanges entre pairs selon l’adresse IP locale à partir d’une cartographie des sous-réseaux fournie par le client ; cette même cartographie peut empêcher les clients Wi-Fi de téléverser des données vers les pairs pour éviter de saturer leur liaison montante. Pour les utilisateurs de VPN, Microsoft recommande le tunneling fractionné et la désactivation des échanges entre pairs pour les sous-réseaux VPN, et Vimeo donne des conseils similaires pour Kollective et Hive Streaming afin que les pairs n’échangent pas de vidéo via le concentrateur VPN. Les règles de sous-réseau s’appliquent à l’adresse que voit le service : Microsoft avertit que la politique du navigateur relative aux adresses IP locales n’expose que la carte réseau ayant la priorité la plus élevée sur un appareil ; un spectateur utilisant un navigateur sur un appareil équipé de plusieurs cartes, par exemple avec un VPN permanent, peut donc être affecté au mauvais groupe de sous-réseaux. Incluez les navigateurs connectés au VPN dans le test avant l’événement et vérifiez le groupe auquel ils sont affectés. Lorsque les échanges entre pairs sont désactivés, chaque spectateur connecté au VPN récupère toujours un flux individuel et, avec un tunnel forcé (complet), ce flux passe par l’infrastructure VPN, sauf si une route directe lui est attribuée ; Microsoft publie une telle exception pour le trafic des participants aux événements Teams. Concernant le contrôle d’accès, Microsoft indique que seuls les spectateurs authentifiés par la plateforme vidéo rejoignent le réseau de pairs et que les connexions entre pairs sont chiffrées avec DTLS.
Comment savoir si l’eCDN réduit réellement le trafic amont ? La réussite de la lecture ne le prouve pas, car le repli sur la diffusion HTTP est automatique. La mesure pertinente est la part des octets distribués à l’intérieur du réseau. Le tableau de bord de Microsoft indique l’efficacité du pair à pair, calculée en divisant les octets transmis entre pairs par le nombre total d’octets, ainsi que les remises en mémoire tampon. Son exemple chiffré présente un flux à 2 Mbps destiné à 1 000 spectateurs, nécessitant 2 Gbps sans réduction du trafic amont et 200 Mbps avec une efficacité de 90 %. Testez avant l’événement avec un nombre réaliste de spectateurs simultanés : Microsoft fournit un test silencieux qui simule un événement en direct et précise que la réduction du trafic amont atteignable est plafonnée à 50 % avec deux spectateurs et à 67 % avec trois ; un test sur quelques machines sous-estime donc le résultat.

Déployez un eCDN lorsque des diffusions internes en direct à grande échelle satureraient autrement les liaisons du réseau d’entreprise. La méthode de diffusion doit respecter les contraintes de pare-feu, de topologie, d’appareils et de confidentialité, faute de quoi les clients peuvent se rabattre sur des échanges directs avec l’origine.

Qu’est-ce qu’un eCDN ?

Fonctionnement des eCDN

Points clés

Quand les eCDN sont utiles

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle