Après avoir analysé plus tôt la capacité des configurations de serveur standard dans Digital Ocean en termes de streaming WebRTC, nous avons remarqué qu'un serveur peut couvrir jusqu'à 2000 téléspectateurs. Dans la vraie vie, les cas où un serveur est insuffisant ne sont pas rares.
Supposons que les amateurs de jeux d'argent en Allemagne regardent les courses de chevaux en temps réel en Australie. Étant donné que les courses de chevaux ne sont pas seulement un jeu de sport mais impliquent également de gros gains à condition que les paris sur le terrain soient faits au bon moment, la vidéo doit être livrée avec la latence la plus faible possible.
Autre exemple: une entreprise mondiale, l'un des leaders du marché FCMG avec des filiales en Europe, en Russie et en Asie du Sud-Est, organise des webinaires de formation des directeurs commerciaux avec diffusion en direct depuis le siège en Méditerranée. Les téléspectateurs doivent pouvoir voir et entendre le présentateur en temps réel.
Ces exemples mettent en avant la même exigence: fournir des flux multimédias à faible latence à un grand nombre de téléspectateurs. Cela nécessitera le déploiement d'un réseau de diffusion de contenu - CDN.
Il convient de noter que la technologie de distribution de flux conventionnelle utilisant HLS n'est pas bien adaptée car elle peut ajouter jusqu'à 30 secondes de retard, ce qui est essentiel pour une émission en temps réel. Imaginez que les chevaux soient déjà terminés, les résultats ont été publiés sur le site, tandis que les fans regardent toujours la fin de la course. La technologie WebRTC est exempte de cet inconvénient et peut garantir des retards inférieurs à 1 seconde, ce qui est possible même sur tous les continents grâce aux canaux de communication modernes.
Pour commencer, nous verrons comment déployer le CDN le plus simple pour fournir des flux WebRTC et comment le faire évoluer par la suite.
Principes du CDN
Un serveur dans CDN peut jouer l'un des rôles suivants:
- Origin est le serveur conçu pour publier des flux multimédias. Il partage des flux avec d'autres serveurs ainsi qu'avec des utilisateurs.
- Transcoder est le serveur dédié au transcodage des flux. Il extrait les flux du serveur Origin et transmet les flux transcodés à Edge. Nous examinerons ce rôle dans la partie suivante.
- Edge est le serveur conçu pour partager des flux avec les utilisateurs. Il extrait les flux des serveurs Origin ou Transcoder et ne les transmet pas aux autres serveurs CDN.
Le serveur d'origine permet de publier des flux WebRTC et RTMP ou de capturer des flux à partir d'autres sources via RTMP, RTSP ou d'autres méthodes disponibles.
Les utilisateurs peuvent lire des flux à partir de serveurs Edge via WebRTC, RTMP, RTSP, HLS.
Afin de minimiser la latence, il est souhaitable de transmettre des flux entre les serveurs CDN à l'aide de WebRTC.
Le CDN statique est entièrement décrit au stade de la configuration. En fait, la configuration d'un CDN statique est similaire à la configuration d'un équilibreur de charge: tous les récepteurs sont répertoriés dans les paramètres du serveur source de flux.
Par exemple, nous avons un serveur Origin à Francfort, un Edge à New York et un à Singapour
Dans ce cas, Origin sera configuré plus ou moins comme ceci:
<loadbalancer mode="roundrobin" stream_distribution="webrtc"> <node id="1"> <ip>edge1.thestaticcdn.com</ip> <wss>443</wss> </node> <node id="2"> <ip>edge2.thestaticcdn.com</ip> <wss>443</wss> </node> </loadbalancer>
Voici le premier problème avec le CDN statique: afin d'inclure dans ce type de CDN un nouveau serveur Edge ou d'exclure un serveur d'un CDN, il est nécessaire de modifier les paramètres et de redémarrer tous les serveurs Origin.
Les flux publiés sur Origin sont diffusés sur tous les serveurs Edge répertoriés dans les paramètres. La décision sur le serveur Edge auquel l'utilisateur se connectera est également prise sur le serveur Origin. Voici le deuxième problème: s'il y a peu ou pas de téléspectateurs - par exemple, à Singapour, c'est en début de soirée tandis qu'à New York, c'est le milieu de la nuit - les flux seront diffusés sur Edge 1 de toute façon. Le trafic est gaspillé à aucune fin, et ce n'est pas gratuit.
Ces deux problèmes peuvent être résolus à l'aide de Dynamic CDN.
Maintenant, nous voulons configurer le CDN sans redémarrer tous les serveurs Origin et ne voulons pas transmettre de flux aux serveurs Edge sans aucun utilisateur connecté. Dans ce cas, il n'est pas nécessaire de conserver la liste complète des serveurs CDN quelque part dans les paramètres. Chaque serveur doit créer une telle liste indépendamment. Pour ce faire, il doit connaître l'état actuel des autres serveurs à tout moment spécifique.
Idéalement, spécifier le point d'entrée - le serveur qui commence le CDN - dans les paramètres devrait être suffisant. Lors du démarrage, chaque serveur doit envoyer une requête à ce point d'entrée et obtenir en réponse la liste des nœuds CDN et des flux publiés. Si le point d'entrée n'est pas accessible, le serveur doit attendre les messages des autres serveurs.
Le serveur doit communiquer toute modification de son état aux autres serveurs du CDN.
Le CDN le plus simple: au centre de l'Europe
Nous allons maintenant essayer de configurer et de démarrer un CDN dynamique. Supposons d'abord que nous devons fournir des flux multimédias aux téléspectateurs en Europe couvrant jusqu'à 5 000 utilisateurs. Supposons que la source du flux soit également située en Europe
Nous allons déployer trois serveurs dans un centre de données basé en Europe. Nous utiliserons les instances de Flashphoner WebCallServer (WebRTC stream video server) comme composants d'assemblage CDN
Configuration:
cdn_enabled=true cdn_ip=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
L'échange de messages entre les nœuds CDN dynamiques est implémenté via Websocket et Secure Websocket est certainement également pris en charge.
Les flux à l'intérieur de CDN sont diffusés via WebRTC. Généralement, UDP est utilisé comme transport, mais s'il est nécessaire de garantir une bonne qualité de streaming avec un canal entre les serveurs moins bon, il est possible de passer en TCP. Malheureusement, dans ce cas, la latence augmente.
Redémarrez les serveurs, ouvrez l'exemple de streaming bidirectionnel sur le serveur o-eu1 , publiez la vidéo cyclique du compte à rebours de 10 minutes à 0
Ouvrez l'exemple Player sur le serveur e-eu1 , lisez le flux
et faire la même chose sur e-eu2
Le CDN fonctionne! Comme vous pouvez le voir sur les captures d'écran, le timing dans la vidéo coïncide avec la seconde à la fois sur la partie publication et sur la partie visualisation grâce à WebRTC et à de bonnes chaînes.
Et au-delà, nous allons: connecter l'Amérique
Nous allons maintenant diffuser des streams aux téléspectateurs du continent américain en gardant à l’esprit la publication
Nous déploierons trois serveurs dans un centre de données américain sans fermer la partie européenne du CDN
Configuration:
cdn_enabled=true cdn_ip=o-us1.flashponer.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
Redémarrez les serveurs américains, vérifiez la publication
et la lecture
Notez que le segment européen continue de fonctionner. Nous allons vérifier si les utilisateurs américains pourront voir le flux publié depuis l'Europe. Publication du flux test_eu sur le serveur o-eu1
et jouer sur e-us1
Et cela fonctionne aussi! Quant à la latence, les captures d'écran démontrent à nouveau la synchronisation du timer dans la vidéo sur la partie publication et sur la partie visualisation sur la seconde.
Notez que la lecture sur un serveur Origin des flux publiés sur un autre serveur Origin n'est pas possible par défaut, mais si nécessaire, cela peut être configuré en conséquence.
cdn_origin_to_origin_route_propagation=true
À suivre
En résumé, nous avons déployé un CDN simple, puis l'avons mis à l'échelle avec succès sur deux continents en publiant et en lisant des flux WebRTC à faible latence. Dans ce but, nous n'avons pas modifié les paramètres de flux lors de la lecture, ce qui est assez souvent nécessaire dans la vie réelle: tous les téléspectateurs ont des canaux différents, et afin de maintenir la qualité du streaming, il est nécessaire, par exemple, de réduire la résolution ou le bitrate. Nous traiterons de cela dans la partie suivante ...
Image Flashphoner WebCallServer dans DigitalOcean Marketplace - image du serveur d'appels Web dans DigitalOcean.
CDN pour le streaming WebRTC à faible latence - Réseau de distribution de contenu basé sur le serveur d'appels Web.