O Impacto dos Anúncios de Vídeo no Desempenho da Rede de Convidados

O IMPACTO DOS ANÚNCIOS DE VÍDEO NO RENDIMENTO DA REDE DE CONVIDADOS Um Podcast de Inteligência Purple WiFi - Briefing de Consultor Sénior Duração: aproximadamente 10 minutos - - - INTRODUÇÃO E CONTEXTO - aproximadamente 1 minuto Bem-vindo de volta. Hoje estamos a abordar algo que se situa na interseção entre a engenharia de redes e as realidades comerciais da gestão de um local de alta densidade - e é um problema que a maioria das equipas de TI descobre da forma mais difícil, geralmente durante um evento de pico, quando tudo para por completo. O tema são os anúncios de vídeo em redes WiFi de convidados. Especificamente, como os anúncios de vídeo de reprodução automática incorporados em websites padrão estão a consumir silenciosamente a maior parte do rendimento disponível na sua rede de convidados - e o que pode fazer a nível da infraestrutura, hoje mesmo, sem esperar por um ciclo de atualização de hardware. Se é um arquiteto de redes responsável por um hotel, uma propriedade de retalho, um estádio ou um centro de conferências, este briefing é diretamente relevante para a sua implementação atual. Vamos cobrir a mecânica técnica, a arquitetura da solução e os resultados de negócio mensuráveis que deve esperar. Vamos a isso. - - - MERGULHO TÉCNICO PROFUNDO - aproximadamente 5 minutos Vamos começar com a física do problema, porque é importante compreender por que razão o tráfego de anúncios de vídeo é tão desproporcionalmente destrutivo num meio sem fios partilhado. Quando um convidado se liga à sua rede WiFi e abre um site de notícias, um feed de redes sociais ou praticamente qualquer propriedade web suportada por anúncios, o seu navegador não carrega apenas o conteúdo da página. Inicia simultaneamente ligações para entre oito e quarenta domínios de terceiros separados. Estes incluem redes de anúncios, plataformas de compra de publicidade, redes de distribuição de anúncios de vídeo, pixéis de rastreio e beacons de análise. A maioria destes é completamente invisível para o utilizador final. Agora, é aqui que se torna tecnicamente interessante. Os anúncios em vídeo antes e durante a reprodução - do tipo fornecido por plataformas como o DoubleClick da Google, Magnite ou The Trade Desk - são normalmente distribuídos como fluxos de taxa de bits adaptável. Isso significa que a CDN de distribuição de anúncios irá testar a largura de banda disponível e, em seguida, fornecer o fluxo de maior qualidade que conseguir sustentar. Numa ligação rápida, isso traduz-se frequentemente em 1080p a 4 a 8 megabits por segundo, por dispositivo, por impressão de anúncio. Dimensione isto para 500 utilizadores simultâneos num recinto de um estádio, todos a navegar nos seus telemóveis durante o intervalo, e estamos a falar de um potencial de 2 a 4 gigabits por segundo de procura agregada - apenas de tráfego de anúncios de vídeo - a atingir uma ligação de rede que pode estar dimensionada para uma fração disso. O padrão IEEE 802.11ax - Wi-Fi 6 - introduziu o OFDMA e o BSS Colouring especificamente para melhorar a eficiência espetral em ambientes de alta densidade. Mas mesmo o Wi-Fi 6 não consegue conjurar largura de banda que não existe na camada da rede de transporte. A tecnologia de rádio não é o gargalo. O gargalo é o puro volume de dados de vídeo não solicitados a serem descarregados por todos os dispositivos ligados em simultâneo. Existe um efeito secundário que é igualmente prejudicial, e que é o consumo de tempo de antena (airtime). Num meio sem fios partilhado, cada dispositivo que está ativamente a receber uma transmissão de vídeo com uma taxa de bits elevada está a ocupar tempo de antena no rádio do ponto de acesso. Isto reduz diretamente o número de outros dispositivos que podem transmitir ou receber durante essa janela. Assim, mesmo os dispositivos que não estão a carregar anúncios em vídeo sofrem degradação - o seu débito real cai porque o meio está saturado. A terceira camada do problema é a latência de resolução de DNS. As redes de anúncios utilizam normalmente cadeias complexas de redirecionamento - uma única impressão de anúncio pode envolver de seis a doze consultas de DNS antes de a transmissão de vídeo sequer começar. Cada uma dessas consultas adiciona latência e, num ambiente de alta densidade onde o resolvedor de DNS já está sob carga, isto transforma-se numa degradação percetível do carregamento de páginas para todos os utilizadores na rede. Agora, a solução de arquitetura. A intervenção mais eficaz é a filtragem de DNS na periferia (edge) - bloqueando os domínios de redes de anúncios ao nível do resolvedor antes de qualquer ligação TCP ser estabelecida. Isto é fundamentalmente diferente da filtragem ao nível da aplicação ou da inspeção profunda de pacotes. A filtragem de DNS opera na Camada 3 e 4, é stateless (sem estado), escala de forma linear e adiciona uma latência insignificante - normalmente inferior a dois milissegundos por consulta. O funcionamento é simples. Implementa um resolvedor de DNS recursivo - localmente ou como um serviço alojado na nuvem - que faz referência a uma lista de bloqueio curada de domínios conhecidos de redes de anúncios. Quando um dispositivo de convidado consulta, por exemplo, um servidor de anúncios de vídeo da DoubleClick, o resolvedor devolve NXDOMAIN ou uma rota nula. O navegador não recebe qualquer resposta, a ligação TCP nunca é iniciada e a transmissão de vídeo nunca é solicitada. A largura de banda nunca é consumida. O que torna isto particularmente elegante do ponto de vista da arquitetura é que funciona de forma totalmente transparente para o utilizador final. A página carrega - o conteúdo carrega - mas os espaços publicitários ficam vazios ou são substituídos por um espaço em branco. A experiência do utilizador é efetivamente melhorada porque os tempos de carregamento das páginas diminuem significativamente quando se eliminam quarenta pedidos concorrentes de terceiros. Do ponto de vista da conformidade com as normas, esta abordagem é compatível com o Artigo 25 do GDPR - privacidade desde a conceção - porque está a impedir, à partida, que os domínios de rastreamento de terceiros recebam quaisquer dados sobre os seus convidados. Também se alinha com os requisitos do PCI-DSS em torno da segmentação de rede, uma vez que está a impor uma separação clara entre o tráfego da sua rede de convidados e as infraestruturas conhecidas de recolha comercial de dados. Para os locais que já implementaram a plataforma de Guest WiFi da Purple, esta funcionalidade integra-se diretamente com a camada de políticas de rede. A plataforma de análise oferece-lhe visibilidade em tempo real sobre quais os domínios que estão a ser bloqueados, quanta largura de banda está a ser recuperada e como isso se traduz em métricas melhoradas de débito por utilizador. Esse é o tipo de dados de que o seu CTO precisa para justificar o investimento na infraestrutura. - RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aproximadamente 2 minutos Permita-me apresentar a sequência de implementação que recomendaria a qualquer arquiteto de rede que esteja a implementar isto pela primeira vez. Primeiro, meça antes de agir. Implemente o registo passivo de DNS na sua rede de convidados durante um período mínimo de 48 horas num período de tráfego representativo. Precisa de compreender o seu perfil de tráfego real - quais os domínios que estão a ser consultados, em que volume e a que horas. Esta linha de base é crítica tanto para dimensionar a sua infraestrutura de filtragem como para medir a melhoria subsequente. Segundo, comece com uma lista de bloqueio conservadora. As principais listas de bloqueio de redes de publicidade - as listas predefinidas do Pi-hole, o ficheiro de hosts consolidado de Steven Black ou as soluções de nível empresarial - contêm todas dezenas de milhares de domínios. Não as implemente todas no primeiro dia. Comece com os 500 principais domínios de distribuição de publicidade em vídeo, valide se nada de crítico está a ser bloqueado inadvertidamente e expanda a partir daí. Uma implementação faseada ao longo de duas a três semanas é muito preferível a uma transição única que quebre algo inesperado. Terceiro, implemente split-horizon DNS. A sua rede corporativa e a sua rede de convidados devem efetuar a resolução através de infraestruturas de DNS separadas. Isto é higiene básica de rede, mas é surpreendente a quantidade de locais que ainda utilizam uma rede plana onde o tráfego de convidados e o tráfego operacional partilham o mesmo resolvedor. Se estiver a bloquear domínios de publicidade ao nível do resolvedor, precisa de garantir que isso se limita apenas à VLAN de convidados. Quarto, monitorize a desatualização da lista de bloqueio. As redes de publicidade não são estáticas - estas rodam domínios, criam novos endpoints de CDN e utilizam algoritmos de geração de domínios para contornar listas de bloqueio estáticas. A sua infraestrutura de filtragem precisa de obter feeds de listas de bloqueio atualizados pelo menos diariamente, idealmente a cada quatro horas. O erro que vejo com mais frequência é o bloqueio excessivo. As equipas tornam-se agressivas com as suas listas de bloqueio e começam a bloquear inadvertidamente domínios de CDN que são partilhados entre a distribuição de publicidade e a distribuição de conteúdos legítimos. A Akamai, a Cloudflare e a Fastly servem tanto conteúdos publicitários como ativos web legítimos a partir da mesma infraestrutura. Precisa de uma solução que funcione ao nível do subdomínio, e não apenas ao nível do domínio raiz, para evitar isto. - PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto Muito bem, vamos fazer uma sessão rápida de perguntas e respostas sobre as questões que me colocam com mais frequência. Isto afeta o tráfego HTTPS? Não. A filtragem de DNS funciona antes do handshake TLS. A consulta de domínio não é encriptada, independentemente de o destino utilizar HTTPS. Os convidados vão notar? Vão notar que as páginas carregam mais rápido. Não vão notar a ausência de anúncios em vídeo, a menos que estejam especificamente à procura deles. Isto cria alguma exposição legal? Na maioria das jurisdições, não. Está a operar uma rede privada e tem o direito de determinar que tráfego passa por ela. No entanto, recomendo uma breve divulgação nos termos de serviço do seu captive portal - algo como "esta rede filtra domínios de publicidade conhecidos para melhorar o desempenho." E em relação ao DNS over HTTPS - DoH? Este é o único desafio técnico real. Se os dispositivos dos convidados estiverem configurados para usar os seus próprios resolvers DoH - ignorando completamente o resolver da sua rede - a sua filtragem será ineficaz. A mitigação passa por bloquear a porta de saída 443 para gamas de IP de fornecedores de DoH conhecidos e forçar todo o tráfego DNS através do seu resolver. É um passo de configuração adicional, mas está bem documentado. - - - RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto Para resumir: o tráfego de anúncios em vídeo não é um pequeno inconveniente na sua rede de convidados - é um problema estrutural de taxa de transferência que pode consumir de 50 a 70 por cento da sua largura de banda disponível durante os períodos de pico. A solução é a filtragem de DNS na periferia, implementada ao nível do resolver, direcionada para a sua VLAN de convidados, com uma lista de bloqueio atualizada e arquitetura de DNS split-horizon. O caso de negócio é simples: melhor experiência de WiFi de convidados, custos de backhaul reduzidos, melhor postura de conformidade e dados mensuráveis que pode apresentar à sua equipa de liderança. Se quiser aprofundar as especificações de implementação, a Purple tem um guia detalhado sobre como melhorar as velocidades de WiFi bloqueando redes de anúncios na periferia - recomendo começar por aí. E se estiver a avaliar a capacidade da sua plataforma de WiFi de convidados atual para suportar este tipo de aplicação de políticas de rede, a plataforma Purple WiFi Analytics oferece-lhe a camada de visibilidade necessária para que isto funcione à escala. Obrigado pelo seu tempo. Até à próxima. - - - FIM DO SCRIPT