Antes, analisando as possibilidades de configurações de servidor padrão no Digital Ocean do ponto de vista do streaming WebRTC, observamos que um servidor pode atender até 2.000 espectadores. Na vida real, geralmente há casos em que um servidor não é suficiente.
Digamos que os fãs de emoção na Alemanha assistam a corridas de cavalos em tempo real na Austrália. Como as corridas de cavalos não são apenas esportes equestres, mas também grandes vitórias, com apostas pontuais, o vídeo deve ser entregue com o menor atraso possível.
Outro exemplo Uma corporação global, uma das líderes no mercado FCMG com subsidiárias na Europa, Rússia e Sudeste Asiático, está organizando seminários on-line para treinar gerentes de vendas transmitidos a partir da sede no Mediterrâneo. Os espectadores devem ver e ouvir o apresentador em tempo real.
Esses exemplos combinam os requisitos: forneça fluxos de mídia para um grande número de espectadores com baixa latência. Para fazer isso, você precisa implantar uma rede de entrega de conteúdo - CDN.
Observe que a tecnologia clássica de entrega de fluxo usando HLS não é adequada, pois pode causar atrasos de até 30 segundos, e isso é crítico para shows em tempo real. Imagine que os cavalos já chegaram à linha de chegada, os resultados são publicados no site e os fãs ainda estão inspecionando a corrida. Essa desvantagem é privada da tecnologia WebRTC, que pode fornecer atrasos em 1 segundo. Com os canais de comunicação modernos, isso é possível mesmo entre continentes.
Primeiro, vamos ver como implantar a CDN mais simples para fornecer fluxos WebRTC e depois escalá-la.
Estrutura CDN
Um servidor em uma CDN pode executar uma das seguintes funções:
- Origin é um servidor para publicar fluxos de mídia. Distribui fluxos para outros servidores, mas também pode distribuir para assinantes.
- Transcoder - um servidor dedicado à transcodificação de fluxos. Recolhe fluxos dos servidores Origin e distribui fluxos transcodificados para o Edge. Lidaremos com esse papel na próxima parte.
- Edge - um servidor projetado para distribuir fluxos para assinantes. Leva fluxos de servidores Origin ou Transcoder, não distribui fluxos para outros servidores CDN.
Você pode publicar fluxos WebRTC e RTMP no servidor Origin ou capturar fluxos de outras fontes via RTMP, RTSP e outros métodos possíveis.
Os assinantes podem reproduzir fluxos de servidores de borda via WebRTC, RTMP, RTSP, HLS
Entre os servidores CDN, é desejável transmitir por WebRTC para reduzir a latência.
Uma CDN estática é totalmente descrita no estágio de configuração. De fato, a configuração de uma CDN estática é semelhante à configuração de um balanceador de carga: todos os receptores são listados nas configurações do servidor de origem do fluxo.
Por exemplo, temos um servidor Origin em Frankfurt, um Edge em Nova York e outro em Cingapura
Nesse caso, o Origin está configurado da seguinte forma:
<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>
Aqui está o primeiro problema com uma CDN estática: para adicionar um novo servidor de Borda a uma CDN ou remover o servidor da CDN, é necessário alterar as configurações e reiniciar todos os servidores Origin.
Os fluxos publicados no Origin são transmitidos para todos os servidores listados nas configurações do Edge. A decisão sobre a qual servidor de borda o assinante se conectará também é tomada no servidor Origin. Aqui está o segundo problema: se não há espectadores ou pouquíssimos, por exemplo, em Cingapura no início da noite e em Nova York no meio da noite, os fluxos ainda são transmitidos para o Edge 1. O tráfego é gasto ocioso, e nem de graça.
CDN dinâmico pode resolver esses dois problemas.
Portanto, queremos configurar a CDN sem reiniciar todos os servidores Origin e não queremos transferir fluxos para os servidores Edge em que não há assinantes. Nesse caso, você não precisa manter a lista inteira de servidores CDN em algum lugar nas configurações. Cada servidor em si deve criar essa lista e, para isso, deve saber o status atual dos outros servidores a qualquer momento.
Idealmente, nas configurações, deve ser suficiente especificar o ponto de entrada, o servidor a partir do qual a CDN é iniciada. Nesse ponto de entrada, cada servidor na inicialização deve enviar uma solicitação e receber uma lista de nós CDN e uma lista de fluxos publicados em resposta. Se o ponto de entrada não estiver disponível, o servidor deverá esperar mensagens de outros servidores.
O servidor deve enviar quaisquer alterações ao seu status para outros servidores na CDN.
A CDN mais simples: no centro da Europa
Então, vamos tentar configurar e executar uma CDN dinâmica. Suponhamos que, para começar, precisamos distribuir fluxos de vídeo para os espectadores europeus, enquanto até 5.000 usuários devem ser suportados. Suponha que a fonte dos fluxos também esteja na Europa.
Implementamos três servidores no data center europeu. Usaremos o Flashphoner WebCallServer (servidor de streaming de vídeo WebRTC) como elementos para a construção de uma CDN.
Configuração:
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
As mensagens entre nós CDN dinâmicos ocorrem através do Websocket e, é claro, o Secure Websocket também é suportado.
Dentro da CDN, os fluxos são transmitidos via WebRTC. Como regra, o UDP é usado como transporte, mas você pode mudar para o TCP se precisar garantir a qualidade da transmissão com um canal não muito bom entre os servidores. Infelizmente, neste caso, os atrasos aumentam.
Reiniciamos os servidores, abrimos o exemplo de transmissão bidirecional no o-eu1 , publicamos um vídeo cíclico com uma contagem regressiva de 10 minutos a 0
Abra o exemplo do Player no e-eu1 , reproduza o fluxo
E faça o mesmo no e-eu2
CDN funciona! Como você pode ver nas capturas de tela, o tempo no vídeo coincide no lado da publicação e nos espectadores por um segundo, graças ao WebRTC e a bons canais.
Em todos os lugares: conectando a América
Agora, enviaremos transmissões para os telespectadores no continente americano e não esqueceremos a publicação.
Sem desativar a parte européia da CDN, implantamos três servidores no data center americano
Configuração:
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 os servidores americanos, verificamos a publicação
e reprodução
Ao mesmo tempo, o segmento europeu continua trabalhando. Verifique se os assinantes americanos verão o fluxo publicado na Europa. Publicamos o fluxo test_eu no o-eu1
e jogue no e-us1
E isso também funciona! Quanto ao atraso, nas capturas de tela, observamos novamente a coincidência do cronômetro no vídeo no lado da publicação e nos espectadores por um segundo.
Observe que os fluxos publicados em outro servidor Origin não podem ser reproduzidos diretamente do servidor Origin por padrão, mas se você precisar, poderá configurá-lo desta maneira
cdn_origin_to_origin_route_propagation=true
Para ser continuado
Então, implantamos uma CDN simples e a escalamos com sucesso para dois continentes, publicando e reproduzindo fluxos WebRTC de baixa latência. Ao mesmo tempo, não alteramos os parâmetros dos fluxos durante a reprodução, o que na vida real é necessário com bastante frequência: todos os espectadores têm canais diferentes e, para manter a qualidade da transmissão, é necessário, por exemplo, diminuir a resolução ou taxa de bits. Isso faremos na próxima parte ...
Referências
A CDN de streaming WebRTC de baixa latência é uma rede de entrega de conteúdo baseada em servidor de chamadas da Web.