1. Qui a besoin du WebRTC côté serveur?
Comme nous le savons tous, WebRTC est une technologie peer-to-peer qui implémente un canal de communication entre deux navigateurs pour transférer l'audio, la vidéo et toute autre donnée avec une faible latence. La technologie est entièrement gratuite, et si votre application doit établir une communication dans les navigateurs pour deux participants distants, vous pouvez ajouter le code JavaScript approprié aux pages Web et le problème est résolu. Les navigateurs communiqueront directement, aucun serveur n'est requis.
Le WebRTC côté serveur entre en scène lorsqu'il est nécessaire qu'il y ait plus de deux participants et que les données d'un participant sont transmises à plusieurs autres participants à la fois.
Dans ce cas, l'un des participants peut être un serveur qui établira une communication individuelle avec le premier participant, recevra des données de sa part, puis établira la communication, également en mode individuel
avec les autres participants et leur enverra ces données. Ceux. le serveur contient de nombreux canaux de communication peer-to-peer et copie simplement les données sur tous ces canaux. Dans la terminologie WebRTC, un tel serveur sert d'unité de transmission sélective (SFU).
Cependant, la communication de groupe n'est pas seulement possible avec la SFU. Vous pouvez vous demander pourquoi tout le monde ne peut pas envoyer de données à tout le monde, sans aucun serveur, et vous aurez tout à fait raison. Cela s'appelle MESH - communication.
Il y a deux points clés ici:
- Dans le schéma MESH, chaque participant envoie et reçoit N-1 flux de données, où N est la taille du groupe. Ceux. Les exigences de vitesse de téléchargement pour chaque participant au système MESH augmentent avec la croissance du groupe. Alors que dans le schéma SFU, chaque participant envoie toujours un seul flux. Tous les participants n'ont pas une vitesse de connexion réseau capable de gérer l'envoi de flux N-1.
- , MESH - . , , - . MESH , , VP8/VP9/H264 4 . WebRTC – , . , (PeerConnection). , 720p 30% , . .
En raison de ces deux points clés, le schéma MESH devient mal implémenté avec un nombre croissant de participants et le schéma SFU doit être utilisé.
Ainsi, avec un grand nombre de participants à la communication, un serveur (SFU) est nécessaire.
Donnons des exemples de telles applications où un serveur est nécessaire:
- Vidéoconférences avec de nombreux participants (Zoom bien-aimé de tous utilise le serveur WebRTC, comme tous les services similaires).
- Surveillance vidéo en direct, lorsque la vidéo est envoyée d'une caméra à plusieurs téléspectateurs et appareils d'enregistrement. Systèmes de sécurité, surveillance.
- Systèmes interactifs tels que: enchères en ligne, applications éducatives et autres applications Web où une faible latence audio / vidéo est requise.
2. Si vous avez toujours besoin de WebRTC côté serveur, que pouvez-vous utiliser en 2020?
Service cloud ou seul?
Voici, dans un premier temps, les arguments informatiques habituels en faveur de l'un ou de l'autre: le cloud va fournir et économiser des coûts informatiques pour les serveurs, la configuration, l'évolutivité. Mais par vous-même, si tout fonctionne (il n'y a aucune garantie), cela reviendra beaucoup moins cher. Après tout, vous devez payer mensuellement pour un service cloud.
Passons maintenant aux arguments spécifiques aux applications décrites ci-dessus. Si vous avez un public mondial et énorme, dans différents pays et régions, alors seul, il vous sera difficile de tout mettre en place. Par exemple, un service cloud convient à une vente aux enchères Sotheby's. Mais si vous avez 2-3 succursales d'entreprise dans différentes villes, 200-500 utilisateurs, et que vous devez organiser un webinaire / conférence / formation, etc. pour eux, vous pouvez alors louer plusieurs serveurs vous-même sur AWS ou des plates-formes d'hébergement similaires, installez-y logiciel serveur WebRTC, et tout fonctionnera. Les serveurs peuvent même être dans votre entreprise, si la vitesse de la connexion Internet le permet. Eh bien, pour toutes les solutions à plus petite échelle, tout peut être fait par vous-même.
Pour le moment, deux services cloud WebRTC sont bien connus et testés: Millicast et Phenix... Les deux ont une couverture mondiale, une bonne connectivité entre les serveurs sur différents continents (en avez-vous besoin?) Et effectivement une latence vidéo (latence) d'une demi-seconde ou moins.
Parlons maintenant de «nous-mêmes».
Vous aurez besoin du logiciel serveur WebRTC ici. Il existe 3 façons d'obtenir un tel serveur.
- Faites-le vous-même en utilisant une API ouverte. Le plus célèbre d'entre eux est l' API Google c ++ WebRTC . Vous pouvez également utiliser l' API GStreamer . Une implémentation intéressante dans Go: Pion WebRTC . Vous aurez besoin de programmeurs C ++ qualifiés et de beaucoup de patience et de temps pour déboguer. J'ai écrit en détail sur les difficultés de cette approche dans mon précédent article .
- . Ant Media Server, Kurento, Janus, Jitsi. , , , . github , . , , , . , c++ . . , .
- . , , . Red5 Pro, Flashphoner Unreal Media Server.
WebRTC .
C'est le sujet le plus problématique. Supposons que votre entreprise publie un logiciel dans lequel vous devez implémenter un serveur WebRTC. Que ce soit un système d'enregistrement et de surveillance vidéo pour les terminaux d'aéroport, les gares, les hubs de transport. Ou un équipement médical avec le logiciel d'accompagnement déjà existant pour la diffusion et l'enregistrement de vidéo à partir d'endoscopes, qui doit être étendu avant de diffuser cette vidéo vers un navigateur. Soit un système de simulation de vol, dans lequel il est nécessaire de mettre en œuvre la possibilité de visualisation dans un navigateur et / ou d'interaction avec un utilisateur distant. Nous sommes constamment confrontés à des exigences similaires. Votre système existant présente de nombreuses limitations. L'accès Internet peut ne pas être disponible. Pas de nuages. Vous ne pouvez pas ouvrir les ports sur le serveur. Windows uniquement ou Linux uniquement. Parfois même seulement une certaine version de Windows, car le produit existant est affûté pour cela. Serveur WebRTC,ce qui s'ajoute à un tel système doit être adapté à toutes ces restrictions.
Ici, vous n'aurez peut-être pas d'autre choix que de prendre un serveur open source comme Ant Media Server ou Janus et de le changer. C'est la situation sous Linux. Pour Windows, Unreal Media Server convient - il s'agit d'un logiciel écrit et optimisé uniquement pour le système d'exploitation Windows.
Le serveur WebRTC est très gourmand en ressources
Gardez cela à l'esprit lors de la planification de vos ressources. Les raisons d'une telle intensification des ressources sont décrites par moi dans un article précédent , mais la conclusion est que l'évolutivité est obtenue par un processeur très puissant ou en ajoutant des serveurs physiques.
Voici un diagramme des tests effectués avec Unreal Media Server v13.0 sur une instance AWS EC2 m4.2xlarge: Processeur Intel Xeon 8 cœurs E5-2686 v4 à 2,30 GHz, 32 Go de RAM, Windows Server 2016.
Comme vous pouvez le voir sur le diagramme, avec 1000 lecteurs Web simultanés pour cette caméra IP , la charge du processeur est de 5% avec le protocole RTMP, et de 75% avec le protocole WebRTC, soit WebRTC est plus de 10 fois plus gourmand en ressources que RTMP.