Hace un par de semanas, activamos discretamente la compatibilidad con el túnel TCP de doble extremo en la nube vLine, convirtiéndonos en los primeros Proveedor de infraestructura WebRTC para permitir la conexión a través de cortafuegos que bloquean UDP. Esto puede no parecer interesante ni importante, pero en realidad marca la diferencia entre tener un servicio que "suele conectarse" y uno que "simplemente funciona". Permítanos explicarle:
Una de las muchas cosas geniales de WebRTC es que es relativamente fácil empezar. Abra una instancia de acuerdo Para la señalización, solo hay que copiar y pegar algo de JavaScript y, ¡listo!, ya puedes hacer videollamadas en tu aplicación (en realidad, es un poco más complicado, pero un buen desarrollador web puede tener fácilmente una demostración de chat de vídeo funcionando en uno o dos días).
Lamentablemente, el camino desde la demostración hasta el servicio de producción puede ser más complicado de lo que uno espera (¡y más caro!). Así es como suele ser:
Nivel 1: ATURDIMIENTO
Empiezas haciendo tus primeras llamadas a través de una red de área local, y todo funciona de maravilla. ¡Hurra! Luego intentas hacer una llamada a alguien fuera de tu firewall, y ocurrirá una de dos cosas.
1) Si por casualidad copiaste y pegaste la dirección del servidor STUN de Google del código fuente de apprtc, tu llamada se realizará y estarás contento (aunque es posible que tengas algunas dudas sobre si está bien usar un servicio no documentado que Google no ha dado permiso explícito a desarrolladores externos para usar. Ten en cuenta el silencio de Google sobre este hilo).
2) Si no tiene configurado un servidor STUN, su llamada fallará. Una pequeña investigación revelará que STUN es un protocolo que el navegador utiliza para determinar su dirección IP pública y abrir un agujero en el cortafuegos. Por lo tanto, si quieres conectarte a través de un cortafuegos, necesitarás un servidor STUN. Unas horas más tarde tendrás un servidor de código abierto funcionando en EC2. Una instancia pequeña debería ser suficiente ($43,92 al mes), pero probablemente querrás ejecutar al menos dos para mayor disponibilidad, preferiblemente en diferentes regiones (es decir, $87,84 al mes).
Nivel 2: TURNO
Haces algunas llamadas de prueba más y todas funcionan. Todo parece ir bien. Luego intentas hacer una llamada entre dos redes corporativas y falla. Grrr. Mientras investigabas sobre STUN, leíste sobre otro protocolo llamado TURN Se utiliza para transmitir datos cuando el navegador no puede establecer una conexión punto a punto. No estabas seguro de si era estrictamente necesario, pero una investigación más a fondo revela que STUN solo es suficiente para conectar aproximadamente 801 TP41T de llamadas. Si eso no te basta (y probablemente no lo sea), necesitarás un servidor TURN.
Algunos hilos de la lista de correo Más tarde, tendrás un servidor TURN funcionando en tu instancia EC2. En realidad, el rendimiento de la red en una instancia pequeña puede ser bastante impredecible si alguien más está usando tu interfaz de red compartida, por lo que deberías pensar en obtener una instancia más grande. Una instancia mediana ($87.84 por mes) funciona bastante bien, pero para obtener la mayor previsibilidad y la menor fluctuación, querrás una extra grande ($351.36 por mes), que te dará “alto rendimiento de la red”. En realidad, son dos ($703.52 por mes), por disponibilidad.
Por supuesto, dado que estás retransmitiendo vídeo, también tendrás que tener en cuenta los costes de ancho de banda. El precio base en EC2 es $0,12 por GB. Mientras haces los cálculos, puede que empieces a preguntarte qué impide que otra persona utilice ese servidor público que acabas de configurar y aumente tus facturas de ancho de banda. Aquí tienes una buena idea. Hilo de la lista de correo Sobre este tema. Resumen: no hay una buena manera de evitar esto dada la forma en que funciona el protocolo TURN y que las credenciales TURN deben estar presentes en su JavaScript, donde cualquiera puede encontrarlas.
Pero no nos detengamos en los detalles. Ahora puedes llamar a tus amigos de otras empresas tecnológicas. ¡Genial! Luego intentas llamar a alguien de una gran corporación que no es del sector tecnológico, y falla. ¡Maldita sea! Creías que TURN te lo ponía fácil.
20 minutos después, tras una pequeña investigación más, descubres que la implementación de asignación TURN de Chrome solo admite el reenvío de paquetes UDP. Chrome 28 añadirá soporte para asignación Un servidor TURN sobre TCP, pero los paquetes seguirán siendo retransmitidos a través de UDP. Vaya, eso no resuelve el problema cuando el cortafuegos bloquea el tráfico UDP.
Nivel 3: Nube vLine
Aquí es donde entra en juego nuestra nueva compatibilidad con túneles TCP. No depende de la implementación TURN de Chrome, por lo que funciona en Chrome hoy mismo. Además, funciona incluso si ambas partes se encuentran detrás de cortafuegos que bloquean UDP. Lo único que se requiere es acceso a internet a través del puerto 443 (el puerto HTTPS), que la gran mayoría de los cortafuegos permiten.
No necesita hacer nada especial para habilitar el túnel TCP en su servicio vLine. Simplemente use vline.js para crear su aplicación y nos conectaremos utilizando el mejor método disponible para cada llamada. Ejecutamos un red global de servidores de alta disponibilidad, Así, brindaremos la mejor calidad de llamada posible a todos sus usuarios, en cualquier parte del mundo, incluso detrás de cortafuegos que bloquean todo excepto el tráfico TCP a través del puerto HTTPS. Por si se lo pregunta, seguimos utilizando DTLS de extremo a extremo, por lo que nuestros servidores nunca ven sus transmisiones multimedia sin cifrar.
Nuestro objetivo es una tasa de conexión de 100%. Si tiene una red donde las llamadas no se conectan, por favor háznoslo saber.
Nota 1: Si desea probar esto usted mismo bloqueando UDP en su firewall, recuerde dejar abierto el puerto DNS (53).
Nota 2: Algunos cortafuegos ultrarrestrictivos que realizan inspección de paquetes con estado aún pueden bloquear las conexiones, ya que, aunque el navegador utilice el puerto HTTPS, en realidad no está implementando SSL/TLS (nunca nos hemos encontrado con un cortafuegos así en la práctica, pero existen). Chrome pronto admitirá conexiones WebRTC a través de TLS, momento en el que también podremos sortear estos cortafuegos.