Il y a quelques semaines, nous avons discrètement activé la prise en charge du tunneling TCP bilatéral dans le cloud vLine, devenant ainsi les premiers fournisseur d'infrastructure WebRTC pour permettre la connexion à travers les pare-feu bloquant le protocole UDP. Cela peut paraître anodin, mais c'est ce qui fait toute la différence entre un service qui “ se connecte généralement ” et un service qui “ fonctionne tout simplement ”. Explications :
L'un des nombreux avantages de WebRTC est sa relative simplicité de prise en main. Il suffit de lancer une instance de apprtc Pour le backend de signalisation, copiez-collez du JavaScript, et voilà, vous pouvez passer des appels vidéo dans votre application (en réalité, c'est un peu plus compliqué que cela, mais un bon développeur web peut facilement mettre en place une démonstration de chat vidéo en un jour ou deux).
Malheureusement, le passage de la démo à un service opérationnel peut s'avérer plus complexe (et plus coûteux !) que prévu. Voici comment cela se déroule généralement :
Niveau 1 : Étourdissement
Vous commencez par passer vos premiers appels sur un réseau local, et tout fonctionne à merveille. Hourra ! Ensuite, vous essayez d'appeler quelqu'un en dehors de votre pare-feu, et deux choses peuvent se produire.
1) Si vous avez copié-collé par erreur l'adresse du serveur STUN de Google depuis le code source d'apprtc, votre appel aboutira et vous serez ravi (même si vous pourriez avoir quelques doutes quant à la pertinence d'utiliser un service non documenté pour lequel Google n'a pas explicitement autorisé les développeurs tiers). Notez le silence de Google à ce sujet. ce fil de discussion).
2) Si vous n'avez pas configuré de serveur STUN, votre appel échouera. Une petite recherche vous montrera que STUN est un protocole Le navigateur utilise cette adresse pour déterminer son adresse IP publique et tenter de contourner le pare-feu. Par conséquent, pour se connecter malgré un pare-feu, un serveur STUN est nécessaire. Quelques heures plus tard, votre serveur open source est opérationnel sur EC2. Une petite instance suffit amplement (1 TP42T43,92 par mois), mais il est conseillé d'en exécuter au moins deux pour garantir la disponibilité, de préférence dans des régions différentes (comptez alors 1 TP42T87,84 par mois).
Niveau 2 : TOUR
Vous effectuez quelques appels tests supplémentaires, et ils fonctionnent tous. Tout semble bien se dérouler. Puis vous tentez d'établir un appel entre deux réseaux d'entreprise, et là, ça ne marche pas. Grrr. Pendant vos recherches sur STUN, vous avez lu… un autre protocole appelé TURN Ce protocole sert à relayer les données lorsque le navigateur ne parvient pas à établir une connexion directe. Vous n'étiez pas certain de son utilité, mais des recherches complémentaires indiquent que STUN ne suffit que pour environ 801 041 téléphones. Si cela ne vous suffit pas (et c'est probablement le cas), vous aurez besoin d'un serveur TURN.
Quelques fils de discussion de la liste de diffusion Plus tard, vous aurez un serveur TURN opérationnel sur votre instance EC2. En réalité, le débit réseau sur une petite instance peut être assez imprévisible si d'autres utilisateurs partagent votre interface réseau. Il est donc conseillé d'opter pour une instance plus puissante. Une instance moyenne ($87,84 par mois) convient parfaitement, mais pour une prévisibilité optimale et une gigue minimale, il vous faudra une instance extra-large ($351,36 par mois), qui vous offrira…“performances réseau élevées”En fait, il s'agit plutôt de deux ($703.52 par mois), pour des raisons de disponibilité.
Bien sûr, puisque vous diffusez de la vidéo, vous devrez également prendre en compte les coûts de bande passante. Le prix de base d'EC2 est de : $0,12 par Go. Pendant que vous faites vos calculs, vous vous demandez peut-être ce qui empêche quelqu'un d'autre d'utiliser ce serveur public que vous venez de configurer et de faire exploser votre facture de bande passante. Voici une bonne explication. fil de discussion de la liste de diffusion À ce sujet. En résumé : il n’existe pas de solution idéale pour empêcher cela étant donné le fonctionnement du protocole TURN et le fait que les identifiants TURN doivent être présents dans votre code JavaScript, où n’importe qui peut les trouver.
Mais ne nous attardons pas sur les détails financiers. Vous pouvez désormais appeler vos amis travaillant dans d'autres entreprises technologiques. Génial ! Puis vous essayez d'appeler quelqu'un dans une grande entreprise traditionnelle, et ça ne marche pas. Zut ! Vous pensiez que TURN avait pensé à tout.
Vingt minutes plus tard, après quelques recherches supplémentaires, vous découvrez que l'implémentation d'allocation TURN de Chrome ne prend en charge que le relais des paquets UDP. Chrome 28 ajoutera la prise en charge de allouer Un serveur TURN utilise TCP, mais les paquets seront toujours relayés via UDP. Zut ! Cela ne résout toujours pas votre problème lorsque le pare-feu bloque le trafic UDP.
Niveau 3 : Nuage vLine
C'est là que notre nouvelle prise en charge du tunneling TCP entre en jeu. Elle ne dépend pas de l'implémentation TURN de Chrome et fonctionne donc dès aujourd'hui. De plus, elle fonctionne même si les deux parties sont protégées par des pare-feu bloquant le protocole UDP. Il suffit d'un accès à Internet via le port 443 (le port HTTPS), autorisé par la grande majorité des pare-feu.
Vous n'avez rien de particulier à faire pour activer le tunneling TCP dans votre service vLine. Utilisez simplement vline.js pour créer votre application, et nous nous connecterons en utilisant la meilleure méthode disponible pour chaque appel. Nous exécutons un réseau mondial de serveurs à haute disponibilité, Nous garantissons ainsi la meilleure qualité d'appel possible à tous vos utilisateurs, partout dans le monde, même derrière des pare-feu bloquant tout trafic autre que TCP sur le port HTTPS. Pour information, nous utilisons toujours le protocole DTLS de bout en bout : nos serveurs n'ont donc jamais accès à vos flux multimédias non chiffrés.
Notre objectif est un taux de connexion de 100%. Si vous rencontrez des problèmes de connexion sur votre réseau, veuillez nous contacter. Faites-nous savoir.
Note 1 : Si vous souhaitez tester cela vous-même en bloquant UDP sur votre pare-feu, n'oubliez pas de laisser le port DNS (53) ouvert.
Note 2 : Certains pare-feu ultra-restrictifs effectuant une inspection dynamique des paquets peuvent bloquer les connexions car, même si le navigateur utilise le port HTTPS, il n’établit pas de connexion SSL/TLS (nous n’avons jamais rencontré de pare-feu de ce type en conditions réelles, mais ils existent). Chrome prendra bientôt en charge les connexions WebRTC via TLS ; nous pourrons alors également contourner ces pare-feu.