Tendo analisado anteriormente a capacidade das configurações de servidor padrão no Digital Ocean em termos de streaming WebRTC, notamos que um servidor pode cobrir até 2.000 visualizadores. Na vida real, casos em que um servidor é insuficiente não são incomuns.
Suponha que amadores de jogos de azar na Alemanha estejam assistindo corridas de cavalos em tempo real na Austrália. Dado que as corridas de cavalos não são apenas um jogo de esportes, mas também implicam grandes ganhos na condição de que as apostas em campo sejam feitas no momento certo, o vídeo deve ser entregue com a menor latência possível.
Outro exemplo: uma corporação global, uma das líderes de mercado da FCMG com subsidiárias na Europa, Rússia e Sudeste Asiático, está organizando seminários on-line para treinamento de gerentes de vendas com transmissão ao vivo a partir da sede no Mediterrâneo. Os espectadores devem poder ver e ouvir o apresentador em tempo real.
Esses exemplos apresentam o mesmo requisito: fornecer fluxos de mídia de baixa latência para um grande número de espectadores. Isso exigirá a implantação de uma rede de entrega de conteúdo - CDN.
Deve-se notar que a tecnologia convencional de entrega de fluxo usando HLS não é adequada, pois pode adicionar atrasos de até 30 segundos, que são críticos para uma exibição em tempo real. Imagine que os cavalos já terminaram, os resultados foram publicados no site, enquanto os fãs ainda estão assistindo o final da corrida. A tecnologia WebRTC está livre dessa desvantagem e pode garantir menos de 1 segundo de atraso, o que é possível mesmo em todos os continentes, graças aos modernos canais de comunicação.
Para começar, veremos como implantar a CDN mais simples para fornecer fluxos WebRTC e como escalá-lo posteriormente.
Princípios do CDN
Um servidor na CDN pode desempenhar uma das seguintes funções:
- Origin é o servidor criado para publicar fluxos de mídia. Ele compartilha fluxos para outros servidores e usuários.
- Transcoder é o servidor dedicado à transcodificação de fluxos. Ele extrai fluxos do servidor Origin e passa fluxos transcodificados para o Edge. Veremos esse papel na parte a seguir.
- Edge é o servidor projetado para compartilhar fluxos para os usuários. Ele extrai fluxos de servidores Origin ou Transcoder e não os transmite para outros servidores CDN.
O servidor de origem permite publicar fluxos WebRTC e RTMP ou capturar fluxos de outras fontes via RTMP, RTSP ou outros métodos disponíveis.
Os usuários podem reproduzir fluxos de servidores de borda via WebRTC, RTMP, RTSP, HLS.
Para minimizar a latência, é desejável transmitir fluxos entre servidores CDN usando o WebRTC.
A 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 um em Cingapura
Nesse caso, o Origin será configurado mais ou menos assim:
<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>
Aí vem o primeiro problema com a CDN estática: para incluir nesse tipo de CDN um novo servidor de Borda ou excluir um servidor de uma CDN, é necessário modificar as configurações e reiniciar todos os servidores Origin.
Os fluxos publicados no Origin são transmitidos para todos os servidores de Borda listados nas configurações. A decisão em qual servidor de borda o usuário se conectará também é tomada no servidor Origin. Aí vem a segunda edição: se houver poucos ou nenhum espectador - por exemplo, em Cingapura é início da noite, enquanto em Nova York é o meio da noite - os fluxos serão transmitidos para o Edge 1 de qualquer maneira. O tráfego está sendo desperdiçado sem propósito e não é gratuito.
Esses dois problemas podem ser resolvidos usando o Dynamic CDN.
Agora, queremos configurar a CDN sem reiniciar todos os servidores Origin e não queremos transmitir fluxos para os servidores Edge sem usuários conectados. Nesse caso, não há necessidade de manter toda a lista de servidores CDN em algum lugar nas configurações. Cada servidor deve criar essa lista independentemente. Para fazer isso, ele deve saber o status atual dos outros servidores a qualquer momento específico.
Idealmente, especificar o ponto de entrada - o servidor que inicia a CDN - nas configurações deve ser suficiente. Durante a inicialização, cada servidor deve enviar uma solicitação a este ponto de entrada e responder à lista de nós CDN e fluxos publicados. Se o ponto de entrada não puder ser acessado, o servidor deverá aguardar mensagens de outros servidores.
O servidor deve comunicar quaisquer alterações em seu status a outros servidores na CDN.
A CDN mais simples: no centro da Europa
Agora vamos tentar configurar e iniciar uma CDN dinâmica. Suponhamos primeiro que precisamos fornecer fluxos de mídia para os espectadores na Europa, cobrindo até 5.000 usuários. Suponha que a fonte de fluxo também esteja localizada na Europa
Vamos implantar três servidores em um data center com sede na Europa. Usaremos instâncias do Flashphoner WebCallServer (servidor de vídeo em fluxo WebRTC) como componentes de montagem da 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
A troca de mensagens entre nós CDN dinâmicos é implementada via Websocket, e o Secure Websocket também é certamente suportado.
Os fluxos dentro da CDN são transmitidos via WebRTC. Normalmente, o UDP é usado como transporte, mas se for necessário garantir uma boa qualidade de streaming, com o canal entre os servidores não sendo tão bom, é possível mudar para o TCP. Infelizmente, neste caso, a latência aumenta.
Reinicie os servidores, abra o exemplo de transmissão em dois sentidos no servidor o-eu1 , publique o vídeo cíclico de 10 minutos a 0 do temporizador de contagem regressiva
Abra o exemplo do Player no servidor e-eu1 , reproduza o fluxo
e faça o mesmo no e-eu2
A CDN está funcionando! Como você pode ver nas capturas de tela, o tempo do vídeo coincide com o segundo na parte de publicação e na parte de visualização, graças ao WebRTC e a bons canais.
E mais além: conectando a América
Agora, forneceremos transmissões para os telespectadores no continente americano, tendo em mente também as publicações
Implementaremos três servidores em um data center americano sem desligar a parte européia da CDN
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
Reinicie os servidores americanos, verifique a publicação
e a reprodução
Observe que o segmento europeu continua funcionando. Vamos verificar se os usuários americanos poderão ver o fluxo publicado na Europa. Publicando o fluxo test_eu no servidor o-eu1
e jogando no e-us1
E isso também está funcionando! Quanto à latência, as capturas de tela demonstram novamente a sincronia do cronômetro no vídeo na parte de publicação e na parte de visualização da segunda.
Observe que a reprodução em um servidor Origin dos fluxos publicados em outro servidor Origin não é possível por padrão, mas se necessariamente necessário, isso pode ser configurado adequadamente.
cdn_origin_to_origin_route_propagation=true
Para ser continuado
Em resumo, implantamos uma CDN simples e a escalamos com sucesso para dois continentes, publicando e reproduzindo fluxos WebRTC de baixa latência. Para esse fim, não modificamos os parâmetros do fluxo na reprodução, o que é muitas vezes necessário na vida real: todos os espectadores têm canais diferentes e, para manter a qualidade do fluxo, é necessário, por exemplo, reduzir a resolução ou a taxa de bits. Trataremos disso na parte seguinte ...
Imagem do Flashphoner WebCallServer no DigitalOcean Marketplace - imagem do Web Call Server no DigitalOcean.
CDN para streaming WebRTC de baixa latência - rede de entrega de conteúdo baseada em Web Call Server.