Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O objetivo deste documento é fornecer às equipes técnicas que gerenciam plataformas corporativas de webcasting instruções sobre como usar a ferramenta de Teste Silencioso eCDN da Microsoft para auditar sua(s) rede(s) corporativa(s) em preparação para eventos reais.
A estrutura de Teste Silencioso eCDN da Microsoft permite que simulações sejam executadas em vários dispositivos facilmente para emular e examinar como uma determinada rede se comporta sob a carga de um evento de vídeo.
Um teste silencioso é uma sessão de vídeo real que é executada em segundo plano (sem som) em um dispositivo do usuário final. O usuário pode continuar trabalhando em seu computador sem saber que o teste está sendo executado, embora possa ocorrer uma desaceleração na conectividade de rede relacionada à largura de banda do vídeo.
Observação
O conteúdo de evento simulado do teste silencioso é hospedado no domínio eCDN da Microsoft. Dessa forma, o teste silencioso não deve ser usado como um teste holístico para reuniões gerais ou qualquer outro produto de evento ao vivo.
A estrutura compreende três componentes principais:
- Dispositivos de executor
- Painel de Gerenciamento
- Análise
Esses componentes são explicados um por um nas seções a seguir.
Dispositivos de executor
Cada dispositivo que se conecta à estrutura é considerado um "corredor". Cada executor simula um único visualizador e se comunica com o back-end da eCDN da Microsoft para obter instruções sobre qual teste deve ser executado. Na maioria das vezes, não há testes em execução, caso em que o executor espera ocioso até que um teste seja iniciado. Em vez de implantar um aplicativo de agente designado em cada computador para atuar como um executor, o Microsoft eCDN aproveita o software existente que é comumente instalado nas máquinas dos usuários finais para iniciar executores em segundo plano.
Como o executor é essencialmente uma página da web, ele pode ser aberto em qualquer navegador ou ambiente semelhante ao navegador. Há duas maneiras de instanciar um executor.
Importante
O Microsoft Edge ou o Google Chrome devem ser instalados no computador do usuário final. Além disso, o dispositivo deve estar ligado e conectado à Internet para participar de testes silenciosos.
Executor Direto
Abrir manualmente a página do executor com a URL a seguir, tomando cuidado para substituir o espaço reservado TENANT_ID_HERE pela ID do locatário em um navegador, é considerado um "executor direto".
https://st-sdk.ecdn.teams.microsoft.com/?customerId=TENANT_ID_HERE&adapterId=Direct
Cuidado
Enquanto um Silent Runner é instanciado com os argumentos necessários para expor o endereço IP do computador ao serviço eCDN da Microsoft, um Direct Runner usa as configurações globais do computador. Dessa forma, se você ainda não tiver desabilitado a ofuscação de IP do mDNS, é improvável que o Direct Runner faça o peering.
Corredor Silencioso
Fornecemos scripts PowerShell & Bash que iniciam um navegador Chromium headless em segundo plano com a página do corredor, que é considerado um "executor silencioso". O script pode então ser executado em um grupo de usuários para conectá-los à estrutura.
Para obter mais informações, consulte Apêndice B: Integrando executores usando o navegador headless
Dashboard de gerenciamento
O dashboard de gerenciamento permite que os testes sejam agendados, modificados e cancelados, e também mostra o número de executores conectados. A janela principal lista testes pendentes, testes em andamento e testes anteriores que já terminaram. Os testes concluídos são mostrados por 24 horas e depois ficam ocultos da lista.
Importante
O número de dispositivos que executam um teste agendado depende do número de executores online no momento do início programado do teste, não no momento de seu agendamento. Certifique-se de que os corredores estejam online antes do início do teste.
Observação
Um executor não adota configurações atualizadas de mapeamento de sub-rede para testes subsequentes. Para aplicar um novo mapeamento de sub-rede, os executores devem ser reiniciados.
Análise
Quando um teste é agendado, ele é definido para o modo "pendente". Quando o horário de início é atingido, 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 (mudo) começa a ser reproduzido na janela oculta. O SDK da eCDN da Microsoft coleta métricas de rede e experiência do usuário que são apresentadas em vários gráficos disponíveis no dashboard do Analytics. As análises são relatadas enquanto o teste está em execução para que os administradores possam marcar o status antes mesmo do término do teste.
Simultaneidade
O gráfico de simultaneidade mostra o número de usuários ativos ao longo do tempo. Para ser considerado ativo, um usuário deve estar reproduzindo vídeo.
Velocidade HTTP + P2P
O gráfico de taxa de transferência de rede mostra um detalhamento do consumo de rede em HTTP e P2P.
| Representado como | Descrição | Eixo |
|---|---|---|
| Barras azuis escuras | Largura de banda HTTP | left |
| Barras de laranja | Largura de banda P2P | left |
| Linha pontilhada verde | Rácio de P2P em relação ao total em percentagem | para a direita |
Por exemplo, uma taxa P2P de 90% significa que apenas 10% do tráfego foi baixado via HTTP e o restante foi emparelhado entre usuários.
Se o P2P for menor que o esperado, isso significa que a simultaneidade do usuário não foi alta o suficiente ou a rede requer mais otimização. Para solução de problemas, consulte a documentação Solução de problemas de baixa eficiência de emparelhamento .
Experiência do usuário
O gráfico de experiência do usuário mostra o tempo combinado gasto jogando vs tempo gasto rebuffering (vídeo congelado).
| Representado como | Descrição | Eixo |
|---|---|---|
| Barras verdes | Tempo agregado gasto jogando em minutos | left |
| Barras vermelhas | Tempo combinado gasto no rebuffering em minutos | left |
| Linha pontilhada azul | Taxa de rebuffering do tempo total como uma porcentagem | para a direita |
Por exemplo, uma taxa de rebuffering de 2% significa que o vídeo foi reproduzido corretamente por 98% do tempo, enquanto em 2% do tempo o vídeo ficou travado.
O ideal é que o rebuffering fique abaixo de 1%. Números altos ou picos no rebuffering podem sugerir congestionamento de rede, sobrecarga do servidor ou conteúdo mal configurado.
Requisitos de rede
A estrutura de teste silencioso usa os seguintes domínios e portas:
| Nome do host | Portas | Protocolo | Descrição |
|---|---|---|---|
| *.ecdn.teams.microsoft.com | 443 | HTTPS | Página do executor & recursos |
| *.ecdn.teams.microsoft.com | 443 | WSS | Conexão WebSocket com o back-end da eCDN da Microsoft |
| *.ecdn.teams.cloud.microsoft | 443 | HTTPS / WSS | Próximo domínio unificado. Veja as descrições dos dois acima. |
| qualquer | Portas altas 10.000 + | SCTP | Isso é exigido pelas conexões de par WebRTC. Pode ser limitado apenas à LAN. |
Importante
Começamos a migrar domínios do teams.microsoft.com para teams.cloud.microsoft de acordo com a iniciativa Domínios Unificados . Pedimos aos clientes que adicionem os novos domínios a seus filtros de tráfego de rede e políticas (firewall, proxy, políticas, VPN) o mais rápido possível e que mantenham os domínios herdados até indicação em contrário.
Segurança
A estrutura de teste silencioso opera atribuindo testes aos executores. Embora o executor seja uma página estática que se conecta ao back-end da eCDN da Microsoft, 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 da Web que é protegida pelo navegador e depende de mecanismos de segurança integrados aos navegadores modernos. Independentemente da integração (excluindo integrações personalizadas), a página de destino é sempre executada em um contexto seguro e limpo usando um iframe.
As permissões de rede também são limitadas pelo navegador e limitadas a APIs Web comuns, incluindo HTTP, WebSocket, WebRTC e assim por diante.
Enquanto aguardam a execução dos testes, os executores mantêm uma conexão WebSocket persistente em uma conexão TLS segura (WSS).
Apêndice
Apêndice A: Como agendar um teste silencioso
Ir para o seu dashboard de Teste Silencioso
Selecione o símbolo +
Preencha os campos obrigatórios
Nome - Nome arbitrário de sua escolha.
Time & Date - 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 - uma URL disponível publicamente da página do evento que reproduz vídeo durante o evento simulado. Você pode usar nossa página integrada ou criar a sua própria.
Stream interno - O Microsoft eCDN inclui uma página interna já integrada com um fluxo ao vivo que inclui várias representações e protocolos de streaming personalizáveis.
Custom Stream - Talvez você queira fornecer apenas uma transmissão ao vivo própria e usar a página integrada automaticamente da eCDN da Microsoft. O fluxo deve estar disponível publicamente e incluir cabeçalhos CORS para que os executores possam carregá-lo. O fluxo é reproduzido automaticamente quando o teste começa.
Página Personalizada - Uma página personalizada sua. A página precisa incluir um player e uma transmissão ao vivo e ser integrada à eCDN da Microsoft. O player DEVE começar a reproduzir o vídeo automaticamente, pois durante o teste não há interação do usuário. Alguns navegadores limitam a capacidade de reprodução automática de vídeos. Por esse motivo, é recomendável silenciar o áudio, o que alivia a limitação. As páginas internas estão silenciadas por padrão.
Filtros de dispositivo - Limite um teste a um grupo específico de dispositivos. Em alguns casos, talvez você queira executar um teste em um subconjunto dos dispositivos conectados. Por exemplo, para executar apenas um teste em escritórios nos EUA ou apenas em dispositivos de executor direto.
Filtro de países - Inclua apenas dispositivos de determinados países/regiões (GeoIP).
Filtro de integração - Inclua apenas dispositivos conectados por meio de uma determinada integração.
Filtro de ID do dispositivo - Execute um teste somente em IDs de dispositivo específicos. Esse filtro é usado principalmente para fins de depuração local.
Selecione Agendar e o teste é criado.
Quando a hora de início do teste silencioso for atingida, o teste será executado nos dispositivos conectados atribuídos.
Apêndice B: Integrando executores usando o navegador sem periféricos
O eCDN da Microsoft fornece um script de executor de testador silencioso sem instalação.
Esse script inicia um navegador baseado em chromium (Microsoft Edge ou Google Chrome) em segundo plano em uma página específica por uma duração especificada e, em seguida, fecha o processo do navegador em segundo plano.
Além disso, o Microsoft eCDN fornece um script de invocação para executar o script do executor do testador silencioso em computadores remotos listados no Active Directory.
Observação
Reiniciar uma máquina não restaurará automaticamente o executor e o navegador precisará ser iniciado novamente usando o script.
Instruções para o ambiente do Windows
Baixe o scriptsilent-tester-runner-windows.ps1 do PowerShell.
Edite o seguinte dentro do script:
$TenantID- Substitua
TENANT_IDpela ID do locatário da Microsoft.$TestID- Substitui
TEST_IDpor uma cadeia de caracteres de ID exclusiva. Essa cadeia de caracteres é usada na criação de arquivos de log, permitindo que os administradores de teste silencioso identifiquem exclusivamente os resultados do teste.
Importante
Cada teste deve ter um $TestID exclusivo. Se o script detectar que ele havia sido executado anteriormente com o mesmo $TestID que a instância atual, ele será encerrado sem instanciar o executor silencioso.
(Opcional) $scenarioDuration - Define a duração do tempo de atividade do navegador para o valor desejado em segundos. Você pode executar testes silenciosos nos computadores de destino durante esse período. Como o navegador está ocioso, não há problema em aumentar esse valor para vários dias para permitir mais flexibilidade na execução de testes. Esse processo não sobrevive a uma reinicialização do sistema. O padrão é 86.400 segundos (24 horas).
(Opcional) $customChromePath – Caso o Microsoft Edge ou o Google Chrome não estejam instalados no caminho padrão (
C:\Program FilesouC:\Program Files (x86)), defina essa variável como o caminho do executável do navegador. Por exemplo:C:\Custom Path\Edge\msedge.exe
Execute o script nos computadores de destino usando o método de sua escolha, como uma das opções a seguir.
Usando GPO
Usar o SCCM
ou manualmente de um controlador de domínio. Para sua conveniência, oferecemos um exemplo de script de invocação.
Baixar remote-invocation.ps1 – um script do PowerShell que executa o script do executor em todos os computadores no Active Directory.
(opcional) Edite o script para restringir o escopo de sua consulta do Active Directory a um grupo limitado de computadores com base em suas necessidades. Consulte a documentação do
Get-ADComputercmdlet para filtragem avançada.
Observação
Certifique-se de que o script do executor esteja no mesmo diretório no qual você está executando o script de invocação.
Cuidado
Para obter melhores resultados, execute o script do executor em um contexto de usuário. Não é recomendável executar o script do executor na conta SYSTEM.
Vá para o dashboard de teste silencioso e certifique-se de que as máquinas de destino agora apareçam como executores online.
Instruções de execução para o ambiente Mac
Baixe silent-tester-runner-mac.sh - um script Bash que inicia o Google Chrome em segundo plano por 24 horas.
Editar silent-tester-runner-mac.sh:
ecdnCustomerId - Substitua
CUSTOMER_IDpela ID do locatário da Microsoft.(Opcional) scenarioDuration - define a duração do tempo de atividade do navegador para o valor desejado em segundos. Você pode executar testes silenciosos nos computadores de destino durante esse período. Como o navegador está ocioso, não há problema em aumentar esse valor para vários dias para permitir mais flexibilidade na execução de testes. O padrão é 86.400 segundos (24 horas).
Dependendo da ferramenta utilizada para gerenciar os dispositivos no local, Jamf Pro, por exemplo, existem diferentes maneiras de executar o script em diferentes máquinas.