1. ¿Quién necesita WebRTC del lado del servidor?
Como todos sabemos, WebRTC es una tecnología peer-to-peer que implementa un canal de comunicación entre dos navegadores para transferir audio, video y cualquier otro dato con baja latencia. La tecnología es completamente gratuita, y si su aplicación necesita establecer comunicación en navegadores para dos participantes remotos, entonces puede agregar el código javascript apropiado a las páginas web y el problema estará resuelto. Los navegadores se comunicarán directamente, no se requiere servidor.
WebRTC del lado del servidor entra en escena cuando se necesitan más de dos participantes y los datos de un participante se transmiten a varios otros participantes a la vez.
En este caso, uno de los participantes puede ser el servidor, el cual establecerá comunicación uno a uno con el primer participante, recibirá datos de él, luego establecerá comunicación, también en modo
uno a uno con otros participantes y les enviará estos datos. Aquellos. el servidor tiene muchos canales de comunicación peer-to-peer y simplemente copia los datos en todos estos canales. En la terminología de WebRTC, dicho servidor sirve como una Unidad de reenvío selectivo (SFU).
Sin embargo, la comunicación grupal no solo es posible con la SFU. Puede preguntar por qué no todo el mundo puede enviar datos a todo el mundo, sin ningún servidor, y tendrá toda la razón. Esto se llama MESH - comunicación.
Aquí hay dos puntos clave:
- En el esquema MESH, cada participante envía y recibe N-1 flujos de datos, donde N es el tamaño del grupo. Aquellos. Los requisitos de velocidad de carga para cada participante en el esquema MESH aumentan con el crecimiento del grupo. Mientras que en el esquema SFU, cada participante siempre envía solo un flujo. No todos los participantes tienen una velocidad de conexión de red que pueda manejar el envío de transmisiones N-1.
- , MESH - . , , - . MESH , , VP8/VP9/H264 4 . WebRTC – , . , (PeerConnection). , 720p 30% , . .
Debido a estos dos puntos clave, el esquema MESH se implementa deficientemente con un número creciente de participantes y el esquema SFU tiene que ser utilizado.
Entonces, con una gran cantidad de participantes en la comunicación, se requiere un servidor (SFU).
Demos ejemplos de tales aplicaciones donde se necesita un servidor:
- Videoconferencias con muchos participantes (el querido Zoom de todos usa el servidor WebRTC, como todos los servicios similares).
- Videovigilancia en vivo, cuando el video se envía desde una cámara a múltiples espectadores y dispositivos de grabación. Sistemas de seguridad, vigilancia.
- Sistemas interactivos como subastas en línea, tutoriales y otras aplicaciones web que requieren baja latencia de audio / video.
2. Si aún necesita WebRTC del lado del servidor, ¿qué puede usar en 2020?
¿Servicio en la nube o por su cuenta?
Aquí, al principio, los argumentos habituales de TI a favor de uno u otro: la nube proporcionará y ahorrará costos de TI para servidores, configuración, escalabilidad. Pero por tu cuenta, si todo sale bien (no hay garantía), te saldrá mucho más barato. Después de todo, debe pagar mensualmente por un servicio en la nube.
Ahora, para los argumentos específicos de las aplicaciones descritas anteriormente. Si tiene una gran audiencia global, en diferentes países y regiones, entonces por su cuenta será difícil para usted juntar todo. Por ejemplo, un servicio en la nube es adecuado para una subasta de Sotheby's. Pero si tiene 2-3 sucursales de la empresa en diferentes ciudades, 200-500 usuarios, y necesita organizar un seminario web / conferencia / capacitación, etc. para ellos, entonces puede alquilar varios servidores usted mismo en AWS o plataformas de alojamiento similares, instalar allí. software servidor WebRTC, y todo saldrá bien. Los servidores pueden incluso estar en su empresa, si la velocidad de la conexión a Internet lo permite. Bueno, para todas las soluciones de menor escala, todo se puede hacer por su cuenta.
Por el momento, dos servicios WebRTC en la nube son bien conocidos y probados: Millicast y Phenix... Ambos tienen cobertura global, buena conectividad entre servidores en diferentes continentes (¿la necesita?) Y, de hecho, latencia de video (latencia) de medio segundo o menos.
Ahora hablemos de "por nuestra cuenta".
Necesitará el software del servidor WebRTC aquí. Hay 3 formas de conseguir un servidor de este tipo.
- Hágalo usted mismo utilizando una API abierta. El más famoso de ellos es Google c ++ WebRTC API . También puede utilizar la API de GStreamer . Una implementación interesante en Go: Pion WebRTC . Necesitará programadores expertos en C ++ y mucha paciencia y tiempo para depurar. Escribí sobre las dificultades de este enfoque en detalle en mi artículo anterior .
- . Ant Media Server, Kurento, Janus, Jitsi. , , , . github , . , , , . , c++ . . , .
- . , , . Red5 Pro, Flashphoner Unreal Media Server.
WebRTC .
Este es el tema más problemático. Suponga que su empresa está lanzando un producto de software en el que necesita implementar un servidor WebRTC. Sea un sistema de grabación y vigilancia de video para terminales de aeropuertos, estaciones de ferrocarril, centros de transporte. O equipo médico con software de acompañamiento ya existente para transmitir y grabar video desde endoscopios, que debe expandirse antes de transmitir este video a un navegador. O un sistema de simulación de vuelo, en el que se debe implementar la capacidad de visualizar en un navegador y / o interactuar con un usuario remoto. Constantemente nos enfrentamos a requisitos similares. Su sistema actual tiene muchas limitaciones. Es posible que el acceso a Internet no esté disponible. Sin nubes. No puede abrir puertos en el servidor. Solo Windows o solo Linux. A veces, incluso solo una determinada versión de Windows, porque el producto existente está perfeccionado para ello. Servidor WebRTC,lo que se agrega a tal sistema debe ajustarse a todas estas restricciones.
Aquí, es posible que no tenga más remedio que tomar un servidor de código abierto como Ant Media Server o Janus y cambiarlo. Esta es la situación en Linux. Para Windows, Unreal Media Server es adecuado : este es un software escrito y optimizado solo para el sistema operativo Windows.
El servidor WebRTC consume muchos recursos
Tenga esto en cuenta al planificar sus recursos. Las razones de tal uso intensivo de recursos las describo en un artículo anterior , pero la conclusión es que la escalabilidad se logra mediante un procesador muy fuerte o agregando servidores físicos.
A continuación se muestra un diagrama de las pruebas realizadas con Unreal Media Server v13.0 en una instancia AWS EC2 m4.2xlarge: Intel Xeon 8 núcleos CPU E5-2686 v4 @ 2.30 GHz, 32 Gb de RAM, Windows Server 2016.
Como puede ver en el diagrama, con 1000 reproductores web simultáneos para esta cámara IP , la carga del procesador es del 5% con el protocolo RTMP y del 75% con el protocolo WebRTC, es decir, WebRTC requiere más de 10 veces más recursos que RTMP.