Lors du SFHTML5 Tout sur WebRTC Lors de la réunion MeetUp qui s'est tenue en début de semaine (notre PDG, Ben Strong, y a pris la parole), une question est revenue sans cesse : si WebRTC est un système pair-à-pair, pourquoi a-t-on besoin de serveurs STUN et TURN ?
WebRTC doit fonctionner 100 % du temps.
WebRTC pourrait bien être la solution miracle pour les communications. Quoi de mieux que des connexions pair-à-pair pour la vidéo, l'audio et les données, basées sur un code source ouvert ?
De nombreux développeurs ont créé des applications WebRTC sans serveurs STUN ni TURN. Et elles fonctionnent bien… la plupart du temps. C'est le “ reste du temps ” qui suscite des interrogations. À moins d'être certain que votre solution WebRTC fonctionne dans toutes les situations, il est difficile de s'y fier comme système principal.
C'est là qu'interviennent les serveurs.
Vous devez vous connecter à différents réseaux ? Il vous faudra un serveur.
WebRTC fonctionne à merveille pour connecter des navigateurs au sein d'un même réseau local. Mais dès que vous tentez d'accéder à des données hors de votre réseau – à travers un pare-feu d'entreprise, par exemple – vous aurez besoin de bien plus de puissance de calcul.
Les configurations de pare-feu bloquent WebRTC sans l'utilisation des protocoles STUN (Session Traversal Utilities for NAT) ou TURN (Traversal Using Relays around NAT). C'est pourquoi un serveur est nécessaire.
Le protocole STUN tente d'ouvrir une brèche dans le pare-feu pour permettre à votre appel de passer. Ce protocole fonctionne la plupart du temps. Une connexion établie via STUN crée une connexion pair à pair. C'est un avantage considérable, car une connexion STUN ne sollicite pas fortement le processeur ni le réseau du serveur.
Lorsque le protocole STUN ne suffit pas, le protocole TURN est nécessaire. Avec TURN, la connexion est relayée par le serveur et n'est pas directe. Cette connexion relayée sollicite la puissance de réseau et de traitement du serveur, ce qui limite le nombre de connexions simultanées qu'un seul serveur peut gérer. (Et si vous avez besoin de nombreuses connexions, il vous faudra plusieurs serveurs.)
Comment le système détermine-t-il ce qui est nécessaire ?
ICE est le protocole utilisé pour déterminer le chemin à emprunter, du plus simple : l’hôte, utilisé lorsque la connexion WebRTC se trouve sur le même réseau local, aux plus complexes : les protocoles STUN puis TURN, qui nécessitent tous deux des serveurs.
OK, il me faut donc un serveur. Que faire maintenant ?
Si vous avez décidé d'utiliser WebRTC et que la fiabilité du 100% est ce dont vous avez besoin, vous êtes dans le domaine des serveurs.
Quels sont les points importants à prendre en compte concernant vos serveurs ? Selon nous, trois priorités sont à considérer :
- Latence
- Sauvegarde et redondance
- Équilibrage de charge (réseau et processeur)
Plusieurs options s'offrent à vous pour construire votre infrastructure serveur. Le choix de la solution la plus adaptée dépend de vos compétences en développement, du temps dont vous disposez et de votre budget.
Première option : AWS. De nombreux détails concernant l'utilisation d'AWS, y compris certaines implications en matière de tarification, sont présentés dans notre article de juin., Tunnelisation de WebRTC sur TCP (et pourquoi c'est important). Il est important de noter qu'avec AWS, vous pouvez définir vos propres priorités en matière de latence et de redondance.
Deuxième option : Serveur TURN open source. (Un exemple est disponible ici.) ici.De nombreux puristes, soucieux de créer leur propre solution, envisageront cette option. Votre rôle consistera alors à déployer les serveurs dans des emplacements géographiquement distribués, garantissant une faible latence pour tous les utilisateurs, et à vous assurer de leur capacité à supporter la charge.
Troisième option : vLine pour les développeurs. Nous avons consacré plus de deux ans exclusivement à la création d'une plateforme WebRTC fonctionnelle. 100% du temps. Pour ceux d'entre vous qui souhaitent ajouter des fonctionnalités WebRTC à leur site, mais qui préfèrent investir leurs ressources dans le reste de leur activité plutôt que de suivre le rythme effréné de l'écosystème WebRTC.
Un moyen rapide de se faire une idée de la qualité de notre plateforme est de l'utiliser Lien vLine, qui repose sur la même plateforme mondiale que celle que vous pouvez utiliser pour votre solution.
Nous sommes toujours heureux de répondre à vos questions. Veuillez nous envoyer un courriel à [email protected] ou retrouvez-nous @vlineinc.