Anteriormente, analizando las posibilidades de las configuraciones de servidor estándar en Digital Ocean desde el punto de vista de la transmisión WebRTC, notamos que un servidor puede servir hasta 2000 espectadores. En la vida real, a menudo hay casos en los que un servidor no es suficiente.
Digamos que los fanáticos de la emoción en Alemania miran carreras de caballos en tiempo real en Australia. Dado que las carreras de caballos no son solo deportes ecuestres, sino también grandes victorias, con apuestas hechas a tiempo, el video debe entregarse con el menor retraso posible.
Otro ejemplo. Una corporación global, uno de los líderes en el mercado de FCMG con filiales en Europa, Rusia y el sudeste asiático, está organizando seminarios web para capacitar a los gerentes de ventas con traducción desde la sede en el Mediterráneo. Los espectadores deben ver y escuchar al presentador en tiempo real.
Estos ejemplos combinan los requisitos: entregar transmisiones de medios a un gran número de espectadores con baja latencia. Para hacer esto, debe implementar una red de entrega de contenido: CDN.
Tenga en cuenta que la tecnología clásica de transmisión de flujo utilizando HLS no es adecuada, ya que puede generar demoras de hasta 30 segundos, y esto es fundamental para espectáculos en tiempo real. Imagine que los caballos ya han llegado a la meta, los resultados se publican en el sitio y los fanáticos aún están inspeccionando la carrera. Este inconveniente está privado de la tecnología WebRTC, que puede proporcionar demoras en 1 segundo, con canales de comunicación modernos, esto es posible incluso entre continentes.
Primero, veamos cómo implementar el CDN más simple para entregar transmisiones WebRTC y luego escalarlo.
Estructura CDN
Un servidor en un CDN puede realizar una de las siguientes funciones:
- Origin es un servidor para publicar transmisiones de medios. Distribuye transmisiones a otros servidores, también puede distribuir a los suscriptores.
- Transcodificador: un servidor dedicado a la transcodificación de secuencias. Recoge las transmisiones de los servidores de Origin y distribuye las transmisiones transcodificadas a Edge. Nos ocuparemos de este papel en la próxima parte.
- Edge: un servidor diseñado para distribuir transmisiones a los suscriptores. Toma secuencias de los servidores de origen o transcodificador, no distribuye secuencias a otros servidores CDN.
Puede publicar secuencias de WebRTC y RTMP en el servidor de Origin, o capturar secuencias de otras fuentes a través de RTMP, RTSP y otros métodos posibles.
Los suscriptores pueden reproducir transmisiones desde servidores Edge a través de WebRTC, RTMP, RTSP, HLS
Entre los servidores CDN, es deseable transmitir a través de WebRTC para reducir la latencia.
Una CDN estática se describe completamente en la etapa de configuración. De hecho, la configuración de un CDN estático es similar a la configuración de un equilibrador de carga: todos los receptores se enumeran en la configuración del servidor de origen de transmisión.
Por ejemplo, tenemos un servidor Origin en Frankfurt, uno Edge en Nueva York y uno en Singapur.
En este caso, Origin está configurado de forma similar a esto:
<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í está el primer problema con una CDN estática: para agregar un nuevo servidor Edge a dicha CDN, o para eliminar el servidor de la CDN, debe cambiar la configuración y reiniciar todos los servidores de Origin.
Las transmisiones publicadas en Origin se transmiten a todos los servidores enumerados en la configuración de Edge. La decisión sobre a cuál de los servidores Edge se conectará el suscriptor también se toma en el servidor Origin. Aquí está el segundo problema: si no hay espectadores o muy pocos, por ejemplo, en Singapur una tarde temprana, y en Nueva York una noche profunda, las transmisiones todavía se transmiten a Edge 1. El tráfico se gasta inactivo, y no es gratis.
Dynamic CDN puede resolver estos dos problemas.
Por lo tanto, queremos configurar CDN sin reiniciar todos los servidores de Origin, y no queremos transferir transmisiones a esos servidores Edge donde no hay suscriptores. En este caso, no necesita mantener la lista completa de servidores CDN en algún lugar de la configuración. Cada servidor debe crear una lista de este tipo y, para ello, debe conocer el estado actual de los otros servidores en cualquier momento.
Idealmente, en la configuración debería ser suficiente para especificar el punto de entrada, el servidor desde el cual se inicia el CDN. En este punto de entrada, cada servidor al inicio debe enviar una solicitud y recibir una lista de nodos CDN y una lista de secuencias publicadas en respuesta. Si el punto de entrada no está disponible, el servidor debe esperar mensajes de otros servidores.
El servidor debe enviar cualquier cambio en su estado a otros servidores en el CDN.
El CDN más simple: en el centro de Europa.
Entonces, intentemos configurar y ejecutar un CDN dinámico. Supongamos que, para empezar, necesitamos distribuir transmisiones de video a los espectadores europeos, mientras que hasta 5,000 usuarios deben ser compatibles. Supongamos que la fuente de los flujos también se encuentra en Europa.
Implementamos tres servidores en el centro de datos europeo. Utilizaremos Flashphoner WebCallServer (servidor de video de transmisión WebRTC) como elementos para construir una 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
La mensajería entre nodos CDN dinámicos se realiza a través de Websocket y, por supuesto, también se admite Secure Websocket.
Dentro de la CDN, las transmisiones se transmiten a través de WebRTC. Como regla general, UDP se usa como transporte, pero puede cambiar a TCP si necesita garantizar la calidad de transmisión con un canal no muy bueno entre servidores. Por desgracia, en este caso aumentan los retrasos.
Reiniciamos los servidores, abrimos el ejemplo de transmisión bidireccional en el o-eu1 , publicamos un video cíclico con un temporizador de cuenta regresiva de 10 minutos a 0
Abra el ejemplo del reproductor en el e-eu1 , reproduzca la transmisión
Y haz lo mismo en e-eu2
CDN funciona! Como puede ver en las capturas de pantalla, el tiempo en el video coincide en el lado editorial y en los espectadores hasta un segundo, gracias a WebRTC y buenos canales.
Más allá en todas partes: conectando América
Ahora entregaremos transmisiones a los espectadores en el continente americano, y no nos olvidaremos de la publicación.
Sin deshabilitar la parte europea de la CDN, implementamos tres servidores en el centro de datos estadounidense
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
Reiniciamos los servidores estadounidenses, verificamos la publicación.
y reproducción
Al mismo tiempo, el segmento europeo continúa trabajando. Verifique si los suscriptores estadounidenses verán la transmisión publicada desde Europa. Publicamos la transmisión test_eu en el o-eu1
y juega en e-us1
¡Y también funciona! En cuanto a la demora, en las capturas de pantalla nuevamente observamos la coincidencia del temporizador en el video en el lado editorial y en los espectadores hasta un segundo.
Tenga en cuenta que las transmisiones publicadas en otro servidor de Origin no se pueden reproducir directamente desde el servidor de Origin de forma predeterminada, pero si lo necesita, puede configurarlo de esta manera
cdn_origin_to_origin_route_propagation=true
Para continuar
Entonces, implementamos un CDN simple y luego lo escalamos con éxito en dos continentes, publicando y reproduciendo transmisiones WebRTC de baja latencia. Al mismo tiempo, no cambiamos los parámetros de las transmisiones durante la reproducción, lo que a menudo se requiere en la vida real: todos los espectadores tienen canales diferentes, y para mantener la calidad de la transmisión, por ejemplo, es necesario reducir la resolución o la tasa de bits. Esto lo haremos en la siguiente parte ...
Referencias
Baja transmisión de WebRTC de baja latencia CDN es una red de entrega de contenido basada en Web Call Server.