Habiendo analizado anteriormente la capacidad de las configuraciones de servidor estándar en Digital Ocean en términos de transmisión WebRTC, hemos notado que un servidor puede cubrir hasta 2000 espectadores. En la vida real, los casos en que un servidor es insuficiente no son infrecuentes.
Suponga que los aficionados al juego en Alemania están viendo carreras de caballos en tiempo real en Australia. Dado que las carreras de caballos no son solo un juego deportivo, sino que también implican grandes ganancias con la condición de que las apuestas de campo se realicen en el momento adecuado, el video debe entregarse con la latencia más baja posible.
Otro ejemplo: una corporación global, uno de los líderes del mercado de FCMG con subsidiarias en Europa, Rusia y el sudeste asiático, está organizando seminarios web de capacitación para gerentes de ventas con transmisión en vivo desde la sede en el Mediterráneo. Los espectadores deben poder ver y escuchar al presentador en tiempo real.
Estos ejemplos presentan el mismo requisito: entregar transmisiones de medios de baja latencia a un gran número de espectadores. Esto requerirá implementar una red de entrega de contenido: CDN.
Cabe señalar que la tecnología de entrega de flujo convencional que utiliza HLS no es adecuada, ya que puede agregar retrasos de hasta 30 segundos, que son críticos para un espectáculo en tiempo real. Imagina que los caballos ya han terminado, los resultados se han publicado en el sitio web, mientras los fanáticos todavía están viendo el final de la carrera. La tecnología WebRTC está libre de esta desventaja y puede garantizar retrasos de menos de 1 segundo, lo que es posible incluso en todos los continentes gracias a los canales de comunicación modernos.
Para comenzar, veremos cómo implementar el CDN más simple para entregar transmisiones WebRTC y cómo escalarlo después.
Principios de CDN
Un servidor en CDN puede desempeñar uno de los siguientes roles:
- Origin es el servidor creado para publicar transmisiones de medios. Comparte transmisiones a otros servidores, así como a los usuarios.
- Transcoder es el servidor dedicado para transcodificar flujos. Extrae secuencias del servidor de origen y pasa secuencias transcodificadas a Edge. Veremos este papel en la siguiente parte.
- Edge es el servidor diseñado para compartir transmisiones a los usuarios. Extrae transmisiones de los servidores de origen o transcodificador y no las pasa a otros servidores CDN.
El servidor Origin permite publicar transmisiones WebRTC y RTMP o capturar transmisiones de otras fuentes a través de RTMP, RTSP u otros métodos disponibles.
Los usuarios pueden reproducir transmisiones desde servidores Edge a través de WebRTC, RTMP, RTSP, HLS.
Para minimizar la latencia, es deseable transmitir transmisiones entre servidores CDN utilizando WebRTC.
La CDN estática se describe completamente en la etapa de configuración. De hecho, la configuración de un CDN estática es similar a la configuración de un equilibrador de carga: todos los receptores se enumeran en la configuración del servidor de origen corriente.
Por ejemplo, tenemos un servidor Origin en Frankfurt, un Edge en Nueva York y uno en Singapur.
En este caso, Origin se configurará más o menos así:
<loadbalancer mode="roundrobin" stream_distribution="webrtc"> <node id="1"> <ip>edge1.thestaticcdn.com</ip> <wss>443</wss> </node> <node id="2"> <ip>edge2.thestaticcdn.com</ip> <wss>443</wss> </node> </loadbalancer>
Aquí viene el primer problema con el CDN estático: para incluir en este tipo de CDN un nuevo servidor Edge o excluir un servidor de un CDN, es necesario modificar la configuración y reiniciar todos los servidores de Origin.
Las transmisiones publicadas en Origin se transmiten a todos los servidores Edge enumerados en la configuración. La decisión sobre a qué servidor Edge se conectará el usuario también se toma en el servidor Origin. Aquí viene el segundo problema: si hay pocos o ningún espectador, por ejemplo, en Singapur es temprano en la noche, mientras que en Nueva York es la mitad de la noche, las transmisiones se transmitirán a Edge 1 de todos modos. El tráfico se está desperdiciando sin ningún propósito, y no es gratuito.
Estos dos problemas se pueden resolver con Dynamic CDN.
Ahora, queremos configurar el CDN sin reiniciar todos los servidores de Origin y no queremos transmitir transmisiones a servidores Edge sin usuarios conectados. En este caso, no es necesario mantener la lista completa de servidores CDN en algún lugar de la configuración. Cada servidor debe crear dicha lista de forma independiente. Para hacer esto, debe conocer el estado actual de los otros servidores en cualquier momento específico.
Idealmente, especificar el punto de entrada (el servidor que comienza el CDN) en la configuración debería ser suficiente. Durante el inicio, cada servidor debe enviar una solicitud a este punto de entrada y obtener en respuesta la lista de nodos CDN y secuencias publicadas. Si no se puede acceder al punto de entrada, el servidor debe esperar los mensajes de otros servidores.
El servidor debe comunicar cualquier cambio en su estado a otros servidores en la CDN.
El CDN más simple: en el centro de Europa.
Ahora vamos a intentar configurar e iniciar un CDN dinámico. Supongamos primero que necesitamos entregar transmisiones de medios a los espectadores en Europa que cubren hasta 5000 usuarios. Supongamos que la fuente de transmisión también se encuentra en Europa
Vamos a implementar tres servidores en un centro de datos con sede en Europa. Utilizaremos instancias de Flashphoner WebCallServer (servidor de video de transmisión WebRTC) como componentes de ensamblaje de CDN
Configuración:
cdn_enabled=true cdn_ip=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
El intercambio de mensajes entre nodos dinámicos de CDN se implementa a través de Websocket, y Secure Websocket ciertamente también es compatible.
Las transmisiones dentro de CDN se transmiten a través de WebRTC. Por lo general, UDP se usa como transporte, pero si es necesario garantizar una buena calidad de transmisión con el canal entre los servidores no tan bueno, es posible cambiar a TCP. Desafortunadamente, en este caso, la latencia aumenta.
Reinicie los servidores, abra el ejemplo de transmisión bidireccional en el servidor o-eu1 , publique el video cíclico del temporizador de cuenta regresiva de 10 minutos a 0
Abra el ejemplo del reproductor en el servidor e-eu1 , reproduzca la transmisión
y hacer lo mismo en e-eu2
¡El CDN está funcionando! Como puede ver en las capturas de pantalla, el tiempo en el video coincide con el segundo tanto en la parte de publicación como en la parte de visualización gracias a WebRTC y buenos canales.
Y más allá vamos: conectando América
Ahora vamos a entregar transmisiones a los espectadores en el continente americano teniendo en cuenta también la publicación
Implementaremos tres servidores en un centro de datos estadounidense sin cerrar la parte europea de CDN
Configuración:
cdn_enabled=true cdn_ip=o-us1.flashponer.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
Reinicie los servidores estadounidenses, verifique la publicación
y la reproducción
Tenga en cuenta que el segmento europeo sigue funcionando. Vamos a verificar si los usuarios estadounidenses podrán ver la transmisión publicada desde Europa. Publicación de la secuencia test_eu en el servidor o-eu1
y jugarlo en e-us1
¡Y esto también está funcionando! En cuanto a la latencia, las capturas de pantalla demuestran nuevamente la sincronía del temporizador en el video en la parte de publicación y en la parte de visualización al segundo.
Tenga en cuenta que reproducir en un servidor de Origin las transmisiones publicadas en otro servidor de Origin no es posible de manera predeterminada, pero si es necesario, esto se puede configurar en consecuencia.
cdn_origin_to_origin_route_propagation=true
Para continuar
En resumen, hemos implementado un CDN simple y luego lo hemos escalado con éxito a dos continentes publicando y reproduciendo transmisiones WebRTC de baja latencia. Para este propósito, no modificamos los parámetros de transmisión en la reproducción, que a menudo se necesita en la vida real: todos los espectadores tienen canales diferentes, y para mantener la calidad de transmisión se necesita, por ejemplo, para reducir la resolución o la tasa de bits Nos ocuparemos de esto en la siguiente parte ...
Imagen de Flashphoner WebCallServer en DigitalOcean Marketplace : imagen de Web Call Server en DigitalOcean.
CDN para transmisión WebRTC de baja latencia : red de entrega de contenido basada en Web Call Server.