Plus tôt, en analysant les possibilités de configurations de serveur standard dans Digital Ocean du point de vue du streaming WebRTC, nous avons noté qu'un serveur peut servir jusqu'à 2000 spectateurs. Dans la vraie vie, il y a souvent des cas où un serveur ne suffit pas.
Disons que les fans d'excitation en Allemagne regardent les courses de chevaux en temps réel en Australie. Étant donné que les courses de chevaux ne sont pas seulement des sports équestres, mais aussi de grandes victoires, avec des paris faits à temps, la vidéo doit être livrée dans les plus brefs délais.
Un autre exemple. Une entreprise mondiale, l'un des leaders du marché des FCMG avec des filiales en Europe, en Russie et en Asie du Sud-Est, organise des webinaires pour former des directeurs commerciaux avec traduction depuis le siège en Méditerranée. Les téléspectateurs devraient voir et entendre le présentateur en temps réel.
Ces exemples combinent les exigences: fournir des flux multimédias à un grand nombre de téléspectateurs avec une faible latence. Pour ce faire, vous devez déployer un réseau de diffusion de contenu - CDN.
Notez que la technologie classique de livraison de flux utilisant HLS ne convient pas, car elle peut donner des retards allant jusqu'à 30 secondes, ce qui est essentiel pour les émissions en temps réel. Imaginez que les chevaux aient déjà atteint la ligne d'arrivée, les résultats sont publiés sur le site, et les fans inspectent toujours la course. Cet inconvénient est privé de la technologie WebRTC, qui peut fournir des retards en 1 seconde, avec des canaux de communication modernes, cela est possible même entre les continents.
Voyons d'abord comment déployer le CDN le plus simple pour fournir des flux WebRTC, puis le faire évoluer.
Structure CDN
Un serveur dans un CDN peut jouer l'un des rôles suivants:
- Origin est un serveur de publication de flux multimédias. Distribue des flux vers d'autres serveurs, il peut également distribuer aux abonnés.
- Transcoder - un serveur dédié au transcodage de flux. Récupère les flux des serveurs Origin et distribue les flux transcodés vers Edge. Nous traiterons de ce rôle dans la prochaine partie.
- Edge - un serveur conçu pour distribuer des flux aux abonnés. Il prend les flux des serveurs Origin ou Transcoder, ne distribue pas les flux aux autres serveurs CDN.
Vous pouvez publier des flux WebRTC et RTMP sur le serveur Origin ou capturer des flux à partir d'autres sources via RTMP, RTSP et d'autres méthodes possibles.
Les abonnés peuvent lire les flux des serveurs Edge via WebRTC, RTMP, RTSP, HLS
Entre les serveurs CDN, il est souhaitable de diffuser sur WebRTC pour réduire la latence.
Un 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 est configuré quelque chose 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 un CDN statique: pour ajouter un nouveau serveur Edge à un tel CDN, ou pour supprimer le serveur du CDN, vous devez modifier les paramètres et redémarrer tous les serveurs Origin.
Les flux publiés sur Origin sont diffusés sur tous les serveurs répertoriés dans les paramètres Edge. La décision concernant le serveur Edge auquel l'abonné se connectera est également prise sur le serveur Origin. Voici le deuxième problème: s'il n'y a pas de spectateurs ou très peu, par exemple à Singapour en début de soirée, et à New York en pleine nuit, les flux sont toujours diffusés vers Edge 1. Le trafic est passé au ralenti, et pas du tout gratuitement.
Le CDN dynamique peut résoudre ces deux problèmes.
Donc, nous voulons configurer CDN sans redémarrer tous les serveurs Origin, et nous ne voulons pas transférer de flux vers ces serveurs Edge où il n'y a pas d'abonnés. Dans ce cas, vous n'avez pas besoin de conserver la liste complète des serveurs CDN quelque part dans les paramètres. Chaque serveur doit lui-même créer une telle liste, et pour cela, il doit connaître l'état actuel des autres serveurs à un moment donné.
Idéalement, dans les paramètres, il devrait suffire de spécifier le point d'entrée, le serveur à partir duquel le CDN démarre. À ce point d'entrée, chaque serveur au démarrage doit envoyer une demande et recevoir une liste de nœuds CDN et une liste de flux publiés en réponse. Si le point d'entrée n'est pas disponible, le serveur doit attendre des messages d'autres serveurs.
Le serveur doit envoyer toute modification de son état à d'autres serveurs du CDN.
Le CDN le plus simple: au centre de l'Europe
Essayons donc de configurer et d'exécuter un CDN dynamique. Supposons que, pour commencer, nous devons distribuer des flux vidéo aux téléspectateurs européens, tandis que jusqu'à 5 000 utilisateurs doivent être pris en charge. Supposons que la source des flux se trouve également en Europe.
Nous déployons trois serveurs dans le centre de données européen. Nous utiliserons Flashphoner WebCallServer (serveur de streaming vidéo WebRTC) comme éléments pour construire un 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
La messagerie entre les nœuds CDN dynamiques se produit via Websocket et, bien sûr, Secure Websocket est également pris en charge.
À l'intérieur du CDN, les flux sont diffusés via WebRTC. En règle générale, UDP est utilisé comme transport, mais vous pouvez basculer vers TCP si vous avez besoin d'assurer la qualité de la diffusion avec un canal pas très bon entre les serveurs. Hélas, dans ce cas les délais augmentent.
Nous redémarrons les serveurs, ouvrons l'exemple de streaming bidirectionnel sur le o-eu1 , publions une vidéo cyclique avec un compte à rebours de 10 minutes à 0
Ouvrez l'exemple Player sur le e-eu1 , lisez le flux
Et faites de même sur e-eu2
CDN fonctionne! Comme vous pouvez le voir sur les captures d'écran, le temps dans la vidéo coïncide du côté de la publication et des téléspectateurs jusqu'à une seconde, grâce à WebRTC et à de bonnes chaînes.
Plus loin partout: connecter l'Amérique
Nous allons maintenant diffuser des streams aux téléspectateurs du continent américain, et nous n'oublierons pas la publication.
Sans désactiver la partie européenne du CDN, nous déployons trois serveurs dans le centre de données américain
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
On redémarre les serveurs américains, on vérifie la publication
et reproduction
Dans le même temps, le segment européen continue de fonctionner. Vérifiez si les abonnés américains verront le flux publié depuis l'Europe. Nous publions le flux test_eu sur le o-eu1
et jouez sur e-us1
Et ça marche aussi! En ce qui concerne le retard, dans les captures d'écran, nous observons à nouveau la coïncidence du minuteur dans la vidéo côté publication et dans les téléspectateurs jusqu'à une seconde.
Veuillez noter que les flux publiés sur un autre serveur Origin ne peuvent pas être lus directement depuis le serveur Origin par défaut, mais si vous en avez besoin, vous pouvez le configurer comme ceci
cdn_origin_to_origin_route_propagation=true
À suivre
Nous avons donc 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 le même temps, nous n'avons pas modifié les paramètres des flux pendant la lecture, ce qui est souvent requis dans la vie réelle: tous les téléspectateurs ont des canaux différents, et afin de maintenir la qualité de la diffusion, il est nécessaire, par exemple, de réduire la résolution ou le débit binaire. C'est ce que nous ferons dans la partie suivante ...
Les références
Le CDN de streaming WebRTC à faible latence est un réseau de distribution de contenu basé sur le serveur d'appels Web.