En SFHTML5 Todo sobre WebRTC En la reunión que tuvimos a principios de esta semana (nuestro director ejecutivo, Ben Strong, habló en el evento), surgió una pregunta recurrente: si WebRTC es peer-to-peer, ¿por qué se necesitan servidores STUN y TURN?
WebRTC necesita funcionar el 100% del tiempo.
WebRTC puede ser la tierra prometida de las comunicaciones. ¿Qué podría ser mejor que conexiones de vídeo, audio y datos punto a punto basadas en código abierto?
Muchos desarrolladores han creado aplicaciones WebRTC sin servidores STUN ni TURN. Y funcionan bien. La mayor parte del tiempo. Es el resto del tiempo lo que genera dudas. A menos que sepas con certeza que tu solución WebRTC funciona en TODAS las situaciones, es difícil confiar en ella como sistema principal.
Aquí es donde entran en juego los servidores.
¿Necesitas conectarte a través de redes? Necesitarás un servidor.
WebRTC funciona de maravilla al conectar navegadores dentro de la misma red local. Pero en cuanto empiezas a acceder a contenido fuera de tu red, por ejemplo, a través de un cortafuegos corporativo, vas a necesitar algo más de potencia.
Las configuraciones del firewall no permiten el acceso a WebRTC sin usar el protocolo STUN (Session Traversal Utilities for NAT) o TURN (Traversal Using Relays around NAT). Por eso necesitarás un servidor.
STUN intenta abrir una brecha en el cortafuegos para que tu llamada pueda pasar. Este protocolo suele funcionar. Si se establece una conexión mediante STUN, habrás creado una conexión punto a punto. Esto es muy útil porque una conexión basada en STUN no consume muchos recursos de CPU ni de red del servidor.
Cuando STUN no es suficiente, se requiere el protocolo TURN. Al usar TURN, la conexión se retransmite a través del servidor y no es punto a punto. Esta conexión retransmitida consume recursos de red y de procesamiento del servidor, lo que limita la cantidad de conexiones que puede gestionar un solo servidor simultáneamente. (Y si necesita muchas conexiones, necesitará muchos servidores).
¿Cómo determina el sistema lo que se necesita?
ICE es el protocolo que se sigue para determinar qué ruta usar, desde la menos complicada: el host, que se usa cuando la conexión WebRTC está en la misma red local, hasta las progresivamente más complicadas: los protocolos STUN y TURN, los cuales requieren servidores.
Vale, entonces necesito un servidor. ¿Y ahora qué?
Si has decidido utilizar WebRTC y la fiabilidad 100% es lo que necesitas, estás en el terreno de los servidores.
¿Qué es importante tener en cuenta al pensar en tus servidores? Creemos que deberías tener tres prioridades:
- Estado latente
- Copias de seguridad y redundancia
- Balanceo de carga (red y CPU)
Existen varias opciones para configurar la infraestructura de tu servidor. La que mejor se adapte a ti dependerá de tus habilidades de desarrollo, el tiempo disponible y tu presupuesto.
Opción uno: AWS. Muchos detalles sobre el uso de AWS, incluidas algunas implicaciones de precios, se describen en nuestra publicación de junio, Túnel WebRTC sobre TCP (y por qué es importante). Un aspecto a tener en cuenta sobre AWS es que puedes seleccionar tus propias prioridades en cuanto a latencia y redundancia.
Opción dos: Servidor TURN de código abierto. (Se puede encontrar un ejemplo) aquí.Muchos puristas decididos a crear su propia solución considerarán esta opción. Su tarea consistirá en lograr que los servidores funcionen en ubicaciones con baja latencia para todos los usuarios (distribuidos geográficamente) y asegurarse de que dichos servidores puedan escalar para gestionar la carga.
Opción tres: vLine para desarrolladores. Hemos dedicado más de dos años exclusivamente a crear una plataforma WebRTC que funcione. 100% del tiempo. Para aquellos que buscan agregar funcionalidades basadas en WebRTC a su sitio, pero prefieren invertir sus recursos en el resto de su negocio, en lugar de mantenerse al día con el vertiginoso desarrollo de WebRTC.
Una forma rápida de hacerse una idea de la calidad de nuestra plataforma es utilizar Enlace vLine, que se basa en la misma plataforma global que puede utilizar para su solución.
Siempre estaremos encantados de responder a sus preguntas. Por favor, envíenos un correo electrónico a [email protected] o encuéntranos @vlineinc.