Arquitetura de teste silenciosa

O objetivo deste documento é fornecer às equipas técnicas que gerem as plataformas de webcasting empresariais instruções sobre como utilizar a ferramenta de Teste Silencioso da Microsoft eCDN para auditar as respetivas redes empresariais em preparação para eventos reais.

A arquitetura de Testes Silenciosos da Microsoft eCDN permite que as simulações sejam executadas em vários dispositivos facilmente para emular e examinar o comportamento de uma determinada rede sob a carga de um evento de vídeo.

Um teste silencioso é uma sessão de vídeo real que é executada em segundo plano (desativada) num dispositivo de utilizador final. O utilizador pode continuar a trabalhar no computador sem saber que o teste está em execução, embora possa ocorrer um abrandamento da conectividade de rede, respetivamente, com a largura de banda do vídeo.

Observação

O conteúdo de evento simulado de teste silencioso está alojado no *.ecdn.teams.microsoft.com domínio. Como tal, os testes silenciosos não devem ser utilizados como um teste holístico para câmaras municipais ou quaisquer outros produtos de eventos em direto.

A estrutura é composta por três componentes main:

  • Dispositivos Runner
  • Dashboard de Gestão
  • Análise

Estes componentes são explicados um a um nas secções seguintes.

Dispositivos runner

Cada dispositivo que se liga à arquitetura é considerado um "runner". Cada corredor simula um único visualizador e comunica com o back-end da Microsoft eCDN para obter instruções sobre o teste que deve ser executado. Na maioria das vezes, não existem testes em execução, caso em que o corredor aguarda inativo até que um teste seja iniciado. Em vez de implementar uma aplicação de agente designada em todos os computadores para atuar como um runner, a Microsoft eCDN tira partido do software existente que é normalmente instalado em máquinas de utilizador final para iniciar corredores em segundo plano.

Uma vez que o runner é essencialmente uma página Web, pode ser aberto em qualquer browser ou ambiente semelhante ao browser. Há duas maneiras de instanciar um corredor.

Importante

O Microsoft Edge ou o Google Chrome têm de estar instalados no computador do utilizador final. Além disso, o dispositivo tem de estar ligado e ligado à Internet para participar em testes silenciosos.

Direct Runner

Abrir manualmente a página de execução com o seguinte URL, tendo o cuidado de substituir o marcador TENANT_ID_HERE de posição pelo ID do seu inquilino num browser, é considerado um "direct runner".

https://st-sdk.ecdn.teams.microsoft.com/?customerId=TENANT_ID_HERE&adapterId=Direct

Cuidado

Enquanto um Silent Runner é instânciado com os argumentos necessários para expor o endereço IP da máquina ao serviço Microsoft eCDN, um Direct Runner utiliza as definições globais da máquina. Como tal, se ainda não tiver desativado a obfuscação do IP do mDNS, é pouco provável que o Direct Runner crie um peering.

Silent Runner

Fornecemos scripts do PowerShell & Bash que iniciam um browser de Chromium sem cabeça em segundo plano com a página de execução, que é considerada um "corredor silencioso". Em seguida, o script pode ser executado num grupo de utilizadores para os ligar à arquitetura.

Para obter mais informações, consulte Apêndice B: Integrar Corredores Com o Browser Sem Cabeça

Dashboard de gestão

A dashboard de gestão permite que os testes sejam agendados, modificados e cancelados e também mostra o número de corredores ligados. A janela main lista os testes pendentes, os testes em curso e os testes anteriores que já terminaram. Os testes concluídos são apresentados durante 24 horas e, em seguida, são ocultados da lista.

Imagem da gestão de Testes Silenciosos dashboard IU.

Análise

Quando um teste é agendado, está definido como modo "pendente". Assim que a hora de início for atingida, o teste é ativado e todos os corredores online recebem um sinal de ativação. A página de destino é então iniciada por cada corredor e o vídeo (desativado) começa a ser reproduzido na janela oculta. O SDK da Microsoft eCDN recolhe métricas de rede e UX que são apresentadas em vários gráficos e gráficos disponíveis no dashboard De análise. As análises são comunicadas enquanto o teste está em execução para que os administradores possam marcar o status mesmo antes de o teste terminar.

Simultaneidade

Gráfico de exemplo intitulado Visualizadores Exclusivos. Ao longo do tempo, o gráfico apresenta duas séries, o peering ativado e o peering desativa os visualizadores em azul e cinzento, respetivamente.

O gráfico Simultaneidade mostra o número de utilizadores ativos ao longo do tempo. Para ser considerado ativo, um utilizador tem de estar a reproduzir vídeo.

VELOCIDADE HTTP + P2P

Gráfico de exemplo intitulado Débito de Rede. Gráfico de barras ao longo do tempo a apresentar três séries, dados HTTP consumidos, dados P2P consumidos e percentagem de rações P2P em linha verde escura azul, laranja e pontilhada, respetivamente.

O gráfico de débito de rede mostra uma discriminação do consumo de rede em HTTP e P2P.

Representado como Descrição Eixo
Barras azuis escuras Largura de banda HTTP left
Barras cor de laranja Largura de banda P2P left
Linha pontilhada verde Rácio de P2P fora do total como uma percentagem Certo

Por exemplo, um rácio P2P de 90% significa que apenas 10% do tráfego foi transferido através de HTTP e o resto foi peering entre os utilizadores.

Se o P2P for inferior ao esperado, significa que a simultaneidade do utilizador não era suficientemente elevada ou a rede requer mais otimização. Para resolução de problemas, veja a documentação Resolução de problemas de baixa eficiência do peering .

Experiência do usuário

Gráfico de exemplo intitulado Tempo de Reprodução e Rejeição. Ao longo do tempo, o gráfico apresenta três séries, Played, Rebuffer e Rejeitor Ratio em linha pontilhada verde escura, vermelha e azul, respetivamente.

O gráfico de experiência de utilizador mostra o tempo combinado despendido a reproduzir vs. tempo despendido a rejeitar (vídeo congelado).

Representado como Descrição Eixo
Barras verdes Tempo agregado despendido a reproduzir em minutos left
Barras vermelhas Tempo combinado gasto a rejeitar em minutos left
Linha pontilhada azul Proporção de rejeição do tempo total como percentagem Certo

Por exemplo, uma taxa de rejeição de 2% significa que o vídeo estava a ser reproduzido corretamente durante 98% das vezes, enquanto durante 2% do tempo o vídeo ficou bloqueado.

A rejeição deve ser idealmente inferior a 1%. Números ou picos elevados na rejeição podem sugerir congestionamento de rede, sobrecarga do servidor ou conteúdo configurado incorretamente.

Requisitos de rede

A arquitetura de teste Silencioso utiliza os seguintes domínios e portas:

Nome do host Portas Protocolo Descrição
*.ecdn.teams.microsoft.com 443 HTTPS Recursos de & de páginas de corredor
*.ecdn.teams.microsoft.com 443 WSS Ligação WebSocket ao back-end da Microsoft eCDN
qualquer Portas altas 10 000 + SCTP Isto é necessário para ligações de elemento da rede WebRTC. Pode ser limitado apenas a LAN. 

Segurança

A arquitetura de teste silencioso funciona ao atribuir testes a corredores. Embora o runner seja uma página estática que liga ao back-end da Microsoft eCDN, um teste executado é dinâmico e pode executar qualquer página de destino. Por esse motivo, os corredores são executados dentro de uma página Web em sandbox pelo browser e baseiam-se em mecanismos de segurança incorporados em browsers modernos. Independentemente da integração (excluindo integrações personalizadas), a página de destino é sempre executada num contexto seguro limpo com um iframe.

As permissões de rede também são limitadas pelo browser e limitadas a APIs Web comuns, incluindo HTTP, WebSocket, WebRTC, entre outros.

Enquanto aguardam que os testes sejam executados, os corredores mantêm uma ligação WebSocket persistente através de uma ligação TLS segura (WSS).

Apêndice

Apêndice A: Como agendar um teste silencioso

  1. Aceda ao seu dashboard de Testes Silenciosos

  2. Selecione o símbolo +

    IU do Teste Silencioso

  3. Preencher os campos necessários

    Imagem da IU das opções de Teste Silencioso.

    • Nome – nome arbitrário à sua escolha.

    • Hora & Data - Hora específica em que o teste começa.

    • Duração – a duração do teste. Recomendamos, pelo menos, 20 minutos para permitir uma simulação adequada.

    • URL de destino – um URL disponível publicamente da página do evento que reproduz o vídeo durante o evento simulado. Pode utilizar a nossa página incorporada ou criar a sua própria página.

      • Stream incorporado – a Microsoft eCDN inclui uma página incorporada já integrada com uma transmissão em fluxo em direto que inclui várias representações e protocolos de transmissão em fluxo personalizáveis.

      • Stream personalizadas – poderá querer fornecer apenas uma transmissão em direto própria e utilizar a página autointegrada da Microsoft eCDN. O fluxo tem de estar publicamente disponível e incluir cabeçalhos CORS para que os corredores possam carregá-lo. O fluxo é reproduzido automaticamente quando o teste é iniciado.

      • Página Personalizada – uma página personalizada própria. A página tem de incluir um leitor e uma transmissão em fluxo em direto e ser integrada com a Microsoft eCDN. O leitor TEM de começar a reproduzir o vídeo automaticamente, uma vez que durante o teste não existe interação do utilizador. Alguns browsers limitam a capacidade de reproduzir vídeo automaticamente. Por esse motivo, é recomendado desativar o som, o que facilita a limitação. As páginas incorporadas são desativadas por predefinição.

    • Filtros de Dispositivo – limite um teste a um grupo específico de dispositivos. Em alguns casos, poderá querer executar um teste num subconjunto dos dispositivos ligados. Por exemplo, para executar apenas um teste em escritórios nos EUA ou apenas em dispositivos Direct Runner.

      • Filtro de Países - inclua apenas dispositivos de determinados países/regiões (GeoIP).

      • Filtro de Integração - inclua apenas dispositivos ligados através de uma determinada integração.

      • Filtro de ID do Dispositivo – execute um teste apenas em IDs de dispositivo específicos. Este filtro é utilizado principalmente para fins de depuração locais.

  4. Selecione Agenda e o teste é criado.

  5. Quando a hora de início do teste silencioso for atingida, o teste será executado nos dispositivos ligados atribuídos.

Apêndice B: Integrar corredores com um browser sem cabeça

A Microsoft eCDN fornece um script de teste silencioso sem instalação.

Este script inicia um browser chromium em segundo plano das máquinas numa página específica durante uma duração especificada e, em seguida, fecha o processo do browser em segundo plano.

Além disso, a Microsoft eCDN fornece um script para executar o teste silencioso em máquinas remotas listadas no Active Directory.

Observação

Reiniciar uma máquina virtual não irá restaurar automaticamente a execução e o browser terá de ser iniciado novamente com o script.

Executar instruções para o ambiente do Windows

  1. Transfira silent-tester-runner-windows.ps1 - um script do PowerShell que inicia um browser baseado em chromium (Microsoft Edge ou Google Chrome se o Edge não for encontrado) em segundo plano durante 24 horas.

  2. Editarsilent-tester-runner-windows.ps1:

    • $TenantID- Substitua pelo TENANT_ID seu ID de inquilino da Microsoft.

    • $TestID- Substitua por TEST_ID uma cadeia de ID exclusiva. Esta cadeia é utilizada na criação de ficheiros de registo, permitindo que os administradores de teste silenciosos identifiquem exclusivamente os resultados dos testes.

    Importante

    Cada teste tem de ter um $TestID exclusivo. Se o script detetar que foi executado anteriormente com o mesmo $TestID que a instância atual, sairá sem executar o teste silencioso.

    • (Opcional) $scenarioDuration - Defina a duração do tempo de atividade do browser para o valor pretendido em segundos. Pode executar testes silenciosos nas máquinas de destino durante esta duração. Uma vez que o browser está inativo, não há qualquer problema em aumentar este valor para vários dias para permitir mais flexibilidade na execução de testes. Este processo não sobrevive a um reinício do sistema. A predefinição é 86 400 segundos (24 horas).

    • (Opcional) $customChromePath - Caso o Microsoft Edge ou o Google Chrome não estejam instalados no caminho predefinido (C:\Program Files ou C:\Program Files (x86)) defina esta variável para o caminho do executável do browser. Por exemplo: C:\Custom Path\Edge\msedge.exe

  3. Execute o script em computadores de destino com o método de eleição, como uma das seguintes opções.

    • Utilizar o GPO

    • Utilizar SCCM

    • Ou Manualmente a partir de um Controlador de Domínio. Para sua comodidade, oferecemos um exemplo de script de invocação.

      1. Transferir remote-invocation.ps1 - um script do PowerShell que executa silent-tester-runner-windows.ps1 em todos os computadores no Active Directory

      2. (opcional) Edite o script para limitar a consulta do Active Directory a um determinado grupo de computadores com base nas suas necessidades. Consulte a documentação do Get-ADComputer cmdlet para obter a filtragem avançada.

      Observação

      Certifique-se de que silent-tester-runner-windows.ps1 está no mesmo diretório a partir do qual está a executar o script de invocação.

      Cuidado

      Para obter os melhores resultados, execute o script de execução num contexto de utilizador. A execução do script de execução na conta SYSTEM é desencorajada.

  4. Aceda ao teste silencioso dashboard e certifique-se de que as máquinas de destino são agora apresentadas como corredores online.

Exemplo de imagem a apresentar quatro corredores online.

Executar instruções para o ambiente Mac

  1. Transfira silent-tester-runner-mac.sh - um script bash que inicia o Google Chrome em segundo plano durante 24 horas.

  2. Editar silent-tester-runner-mac.sh:

    1. ecdnCustomerId – substitua pelo CUSTOMER_ID seu ID de inquilino da Microsoft.

    2. (Opcional) scenarioDuration - Defina a duração do tempo de atividade do browser para o valor pretendido em segundos. Pode executar testes silenciosos nas máquinas de destino durante esta duração. Uma vez que o browser está inativo, não há qualquer problema em aumentar este valor para vários dias para permitir mais flexibilidade na execução de testes. A predefinição é 86 400 segundos (24 horas).

  3. Consoante a ferramenta utilizada para gerir os dispositivos no site, o Jamf Pro, por exemplo, existem diferentes formas de executar o script em diferentes computadores.