Reduzir a Latência em Redes WiFi de Alta Densidade

GUIÃO DE PODCAST — "Reducing Latency on High-Density WiFi Networks" Tempo de duração: aproximadamente 10 minutos Voz: Inglês do Reino Unido, masculino, tom de consultor sénior — confiante, conversacional, autoritário. --- [INTRODUÇÃO — aproximadamente 1 minuto] Bem-vindos de volta. Hoje vou direto ao assunto, porque este é um daqueles tópicos em que a diferença entre o que a maioria das equipas está a fazer e o que deveriam estar a fazer está genuinamente a custar-lhes dinheiro. Estamos a falar de latência em redes WiFi de alta densidade — e, especificamente, de como o DNS é o culpado oculto para o qual quase ninguém está a olhar. Se gere WiFi num hotel, num estádio, num centro de conferências ou numa grande rede de retalho, quase de certeza que já teve esta conversa: "A rede está lenta." E o instinto é sempre olhar para a densidade dos pontos de acesso, utilização de canais ou capacidade de backhaul. Isso é importante. Mas há uma camada abaixo de tudo isso — a camada de DNS — onde pode estar a perder latência em cada dispositivo, em cada carregamento de página, antes mesmo de um único byte de conteúdo real ter sido transferido. É isso que vamos analisar hoje. Vou guiar-vos pela mecânica técnica, apresentar dois cenários concretos de implementação e deixar-vos com um conjunto claro de ações que podem levar para a vossa equipa ainda esta semana. --- [ANÁLISE TÉCNICA DETALHADA — aproximadamente 5 minutos] Vamos começar pelo básico. Quando um dispositivo se liga ao seu WiFi e um utilizador abre um navegador ou uma aplicação, o que acontece realmente primeiro? Antes de qualquer conteúdo ser obtido, o dispositivo precisa de traduzir nomes de domínio em endereços IP. Isso é o DNS. E num smartphone moderno, o carregamento de uma única página — por exemplo, um artigo de notícias ou uma página de reserva de hotel — pode desencadear entre 20 a 70 consultas de DNS. Não porque a página em si tenha 70 domínios, mas porque a página está carregada com píxeis de rastreio de terceiros, scripts de publicidade, beacons de análise e widgets de redes sociais. Cada um deles dispara uma consulta de DNS. Num ambiente doméstico ou de escritório normal, com um punhado de dispositivos, isto é praticamente invisível. O resolvedor de DNS trata do assunto, a cache TTL faz o seu trabalho e o impacto é insignificante. Mas coloque 500 dispositivos no mesmo cluster de pontos de acesso numa conferência, ou 3.000 hóspedes num hotel na hora de ponta do check-in, e terá uma tempestade de consultas de DNS. O seu resolvedor local — se é que tem um — está a processar dezenas de milhares de consultas por minuto, uma proporção significativa das quais está a ir para a internet pública para resolver domínios de redes de anúncios e serviços de rastreio que nunca chegarão a carregar conteúdo que interesse ao utilizador. Aqui está a perspetiva crítica: cada uma dessas pesquisas de DNS desnecessárias adiciona latência à experiência percebida pelo utilizador. Não estamos a falar do tempo de carregamento do conteúdo — estamos a falar do tempo de resolução pré-carregamento. Numa rede congestionada, uma única consulta de DNS a um resolvedor externo pode demorar entre 80 a 150 milissegundos. Se uma página disparar 15 pesquisas de domínios de monitorização antes de começar a carregar o conteúdo real, acabou de adicionar mais de um segundo de atraso invisível antes que o utilizador veja o que quer que seja. Isso não é um problema de backhaul. Isso é um problema de DNS. A solução tem duas componentes. Primeiro, implementar um resolvedor de DNS local — idealmente on-premises ou na periferia (edge) da sua rede — com caching agressivo. O Unbound, o Pi-hole em modo empresarial ou equivalentes comerciais de fornecedores como a Cisco Umbrella ou a Infoblox funcionam todos bem aqui. O objetivo é resolver a maioria das consultas a partir da cache, em menos de 5 milissegundos, sem sequer aceder à internet pública. Para um local de alta densidade, deve visar uma taxa de acerto na cache (cache hit rate) superior a 70 por cento para uma operação em estado estacionário. Segundo, e é daqui que vêm os ganhos reais: implementar filtragem de DNS para descartar consultas de domínios conhecidos de monitorização, publicidade e telemetria ao nível do resolvedor. Quando chega uma consulta para um domínio de rede de anúncios conhecido, o resolvedor devolve instantaneamente NXDOMAIN — domínio não encontrado — em menos de um milissegundo. O dispositivo obtém a sua resposta, para de esperar e avança para a pesquisa seguinte. Eliminou completamente a viagem de ida e volta à internet pública. Multiplique isso por 15 domínios de monitorização por carregamento de página, em 500 dispositivos simultâneos, e a redução agregada no volume de consultas de DNS — e, portanto, na latência — é substancial. Existe aqui uma nuance importante em relação ao DNS over HTTPS, ou DoH. Os navegadores e sistemas operativos modernos estão a contornar cada vez mais o seu resolvedor local, enviando consultas de DNS diretamente para fornecedores de DoH como a Cloudflare ou a Google através de HTTPS encriptado. Isto é excelente para a privacidade em contextos de consumo, mas prejudica totalmente a sua estratégia de caching e filtragem local num ambiente de local gerido. Precisa de intercetar ou redirecionar o tráfego DoH ao nível da firewall, ou implementar o seu próprio resolvedor DoH para o qual os dispositivos possam ser direcionados através da opção DHCP 6 e de políticas de rede. Esta é uma área de complexidade crescente — se quiser aprofundar especificamente as implicações do DoH, a Purple tem um guia dedicado sobre DNS over HTTPS para filtragem de WiFi público que vale a pena ler. Agora, vamos analisar a vertente de RF, porque a otimização de DNS não existe num vácuo. Numa implementação de alta densidade, normalmente utiliza-se o padrão 802.11ax — WiFi 6 ou WiFi 6E — com OFDMA e BSS Colouring para gerir a interferência de canal partilhado. A razão pela qual o DNS é ainda mais importante nestes ambientes é que os ganhos de eficiência do OFDMA baseiam-se no pressuposto de que o meio de rádio está a ser utilizado para a transferência real de dados, e não para a sobrecarga de processamento da resolução de centenas de nomes de domínio desnecessários. Cada consulta de DNS enviada para a internet é um pequeno pacote que ocupa uma oportunidade de transmissão. À escala, essa sobrecarga é mensurável em termos de taxa de transferência (throughput). A combinação de cache de DNS local, filtragem de domínios de rastreio e um ambiente de rádio 802.11ax bem ajustado é onde se começam a notar melhorias disruptivas. Estamos a falar de reduzir a latência percebida no carregamento de páginas em 60 a 87 por cento em implementações reais, e não em condições de laboratório. --- [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos] Muito bem, passemos à prática. Se estiver a planear isto para uma implementação, eis como eu abordaria a questão. Comece com uma auditoria de DNS. Antes de alterar o que quer que seja, monitorize o seu resolvedor existente — ou implemente um tap de DNS passivo — e registe os logs de consultas durante 24 a 48 horas. Irá quase de certeza descobrir que 30 a 50 por cento do seu volume de consultas se destina a um conjunto relativamente pequeno de domínios de rastreio e publicidade. Esse é o seu ponto de partida mais fácil. Em seguida, implemente um resolvedor local com uma lista de bloqueio selecionada. Recomendo começar com uma lista conservadora — algo como a lista consolidada de hosts do Steven Black ou um equivalente comercial — em vez de uma lista agressiva. Deve evitar bloquear domínios dos quais dependem aplicações legítimas. Teste numa VLAN de testes antes de avançar para a produção. Para a interceção de DoH, terá de trabalhar ao nível da firewall. Bloqueie as portas TCP e UDP 443 de saída para gamas de IP de fornecedores de DoH conhecidos — o 1.1.1.1 da Cloudflare, o 8.8.8.8 da Google — e redirecione essas consultas para o seu resolvedor de DoH local. Isto requer coordenação com a sua equipa de segurança, especialmente se estiver num ambiente sensível ao PCI DSS ou ao GDPR, porque está efetivamente a realizar uma forma de inspeção de DNS. Documente o processo, obtenha a aprovação e certifique-se de que os termos de serviço do seu Captive Portal refletem a política de filtragem. O maior erro que vejo é as equipas implementarem a filtragem de forma demasiado agressiva e depois receberem chamadas de suporte porque uma aplicação específica deixou de funcionar. Crie um processo de resposta rápida para pedidos de lista de permissões (whitelist) de domínios e monitorize as suas taxas de resposta NXDOMAIN. Se estas dispararem subitamente, algo mudou nas dependências de DNS de uma aplicação legítima. O segundo erro é tratar isto como uma configuração única e não como uma tarefa operacional contínua. Os domínios de rastreio mudam. Surgem novas redes de publicidade. A sua lista de bloqueio precisa de ser atualizada regularmente — no mínimo mensalmente, idealmente todas as semanas através de um feed automatizado. --- [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Algumas perguntas que me fazem regularmente sobre este tema. "A filtragem de DNS afeta a conformidade com o GDPR?" — Na verdade, pode ajudar. Ao impedir a resolução de domínios de rastreio, está a reduzir os dados que as redes de anúncios de terceiros podem recolher sobre os seus convidados. Dito isto, documente a sua política de filtragem e inclua-a no seu aviso de privacidade. "E quanto ao split DNS para recursos internos?" — Absolutamente necessário. O seu resolvedor local deve ter zonas autoritárias para quaisquer nomes de host internos, e estes nunca devem ser reencaminhados externamente. Prática padrão, mas que vale a pena referir. "Posso fazer isto numa plataforma de WiFi gerida na nuvem?" — Sim, a maioria das plataformas empresariais — Cisco Meraki, Juniper Mist, Aruba Central — suporta a atribuição de servidores DNS personalizados via DHCP. Aponta os dispositivos para o seu resolvedor local e a filtragem acontece aí, independentemente de qual plataforma de nuvem gere os seus APs. "Qual é o caso de ROI para isto?" — Pontuações de satisfação dos convidados, redução do volume de pedidos de suporte por reclamações de WiFi lento e melhorias mensuráveis nos tempos de carregamento do Captive Portal. Para um hotel, isso traduz-se diretamente em pontuações de avaliações. Para um espaço de conferências, é a diferença entre uma nova reserva e um cliente perdido. --- [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para concluir: a intervenção de maior impacto e menor custo que pode fazer para reduzir a latência do WiFi num espaço de alta densidade é implementar um resolvedor DNS local com filtragem de domínios de rastreio. Esta aborda a causa raiz de uma proporção significativa da latência percebida — não o ambiente de RF, não o backhaul, mas a tempestade de consultas DNS gerada por cada dispositivo na sua rede a resolver domínios para conteúdos que nunca irão carregar. A sua lista de ações: realize uma auditoria de DNS esta semana, planeie a implementação de um resolvedor local e defina uma estratégia de lista de bloqueio com a sua equipa de segurança. Se estiver a lidar com o desvio de DoH, essa é a próxima camada a abordar. A plataforma de [Guest WiFi] e as ferramentas de [WiFi Analytics] da Purple foram desenvolvidas exatamente com este tipo de inteligência de rede em mente — se quiser ver como a otimização de DNS se enquadra numa estratégia mais ampla de WiFi para espaços físicos, vale a pena conversar com a equipa da Purple. Obrigado por ouvir. Até à próxima. --- FIM DO GUIÃO