Como o Background App Refresh Prejudica o Desempenho do WiFi Público

Como o Background App Refresh Prejudica o Desempenho do WiFi Público — Um Briefing Técnico da Purple. Bem-vindo. Se é responsável por uma rede WiFi de convidados — seja um hotel, uma infraestrutura de retalho, um estádio ou um centro de conferências — este briefing vai mudar a forma como pensa sobre o seu orçamento de tempo de antena. Vou orientá-lo através de um dos assassinos de capacidade mais subestimados em implementações sem fios públicas: o background app refresh. Vamos abordar o que é ao nível do protocolo, por que razão é particularmente destrutivo em ambientes de alta densidade e — mais importante — o que pode fazer hoje a esse respeito na camada de rede. Comecemos pela escala do problema. Cada smartphone que os seus convidados trazem para a sua rede está a executar entre 30 e 80 aplicações instaladas. Dessas, uma proporção significativa está configurada para executar ciclos de background refresh — consultando servidores de analítica, sincronizando dados na nuvem, procurando tokens de notificações push, verificando atualizações do SO e enviando pings para redes de publicidade. No iOS, a funcionalidade Background App Refresh da Apple foi introduzida no iOS 7 e tem sido uma presença constante desde então. O Android tem o seu próprio equivalente através das API JobScheduler e WorkManager. O ponto-chave é este: estes processos são executados independentemente de o utilizador estar a utilizar ativamente o seu dispositivo. Eles disparam silenciosamente, de forma invisível e constante. Numa ligação de banda larga doméstica com um ou dois dispositivos, isto é essencialmente invisível. Mas aumente essa escala para um centro de conferências com 1.200 delegados, ou uma loja principal de retalho com 400 ligações simultâneas de convidados, e a aritmética torna-se desconfortável muito rapidamente. A investigação em implementações sem fios empresariais mostra consistentemente que o tráfego de fundo — beacons de analítica, verificações de atualizações do SO, pings de redes de publicidade, consultas de notificações push, sincronização na nuvem e ciclos de atualização de redes sociais — pode representar entre 30 e 45 por cento da capacidade total do ponto de acesso numa rede de convidados movimentada. Essa é uma capacidade que está a ser negada aos seus utilizadores legítimos — aqueles que tentam transmitir uma apresentação, concluir uma transação ou simplesmente navegar. Deixe-me dar-lhe a imagem técnica do que está realmente a acontecer na camada de rádio. Numa rede 802.11, cada dispositivo que se associa a um ponto de acesso compete pelo tempo de antena utilizando CSMA/CA — Carrier Sense Multiple Access with Collision Avoidance. Cada pedido de background refresh, por mais pequeno que seja o payload, requer uma sequência de associação completa: pedido de sonda, autenticação, associação, DHCP se necessário, e depois a própria troca de dados. Numa implementação de alta densidade, esta sobrecarga de contenção é significativa. Um único beacon de analítica de uma única aplicação pode transferir apenas 200 bytes de dados, mas a sobrecarga dessa transação no meio sem fios pode consumir 10 a 20 vezes mais em tempo de antena. Com o Wi-Fi 6 — IEEE 802.11ax — temos OFDMA e BSS Colouring que ajudam a gerir isto de forma mais eficiente. Mas mesmo com estas melhorias, o problema fundamental permanece: não pode recuperar o tempo de antena consumido pelo tráfego de fundo a menos que intervenha na camada de rede. O rádio não sabe nem quer saber se um pacote é um utilizador a ver um vídeo ou uma aplicação a ligar silenciosamente para um servidor de telemetria na Virgínia. É aqui que a inspeção profunda de pacotes e a classificação de tráfego se tornam ferramentas críticas na sua arquitetura. Um motor de classificação de tráfego devidamente configurado, posicionado em linha entre o seu controlador sem fios e o seu gateway a montante, pode identificar o tráfego de background refresh pelo seu destino, pela sua assinatura de payload e pelo seu padrão de comportamento. Endpoints de analítica conhecidos — Google Analytics, Firebase, Crashlytics, Flurry, Amplitude, Mixpanel e dezenas de outros — têm gamas de IP e padrões de domínio bem documentados. Os endpoints de redes de publicidade da DoubleClick, AppNexus e plataformas semelhantes estão igualmente bem catalogados. Uma lista de bloqueio atualizada regularmente, aplicada na camada de DNS ou IP, pode intercetar estes pedidos antes que consumam qualquer largura de banda significativa. A abordagem é neutra em relação ao fornecedor. Quer esteja a executar o Cisco Catalyst Centre, o Aruba Central, o Juniper Mist ou uma implementação Ruckus SmartZone, o princípio é o mesmo: classificar, depois agir. Tem três opções sobre o que fazer com o tráfego de fundo identificado. Pode bloqueá-lo totalmente — a abordagem mais agressiva e a mais eficaz para a recuperação de capacidade. Pode limitar a sua largura de banda — permitindo a passagem do tráfego, mas limitando-o a um teto de largura de banda definido, normalmente 64 kilobits por segundo por dispositivo para categorias de fundo. Ou pode despriorizá-lo utilizando marcações QoS DSCP, empurrando-o para a classe de tráfego mais baixa para que apenas consuma tempo de antena quando nenhum outro tráfego estiver a competir. Para a maioria dos operadores de locais, uma combinação de bloqueio de endpoints conhecidos de analítica e redes de publicidade, combinada com a limitação de largura de banda do tráfego de atualizações do SO durante as horas de pico, proporciona o melhor equilíbrio entre recuperação de capacidade e experiência do utilizador. Agora, deixe-me orientá-lo através de dois cenários de implementação no mundo real onde isto fez uma diferença mensurável. O primeiro é um hotel de quatro estrelas com 340 quartos nas Midlands do Reino Unido. A propriedade tinha investido numa infraestrutura moderna de Wi-Fi 6 — 48 pontos de acesso nos pisos dos hóspedes, salas de conferências e áreas públicas. Apesar do investimento em hardware, as pontuações de satisfação dos hóspedes com o WiFi estavam consistentemente abaixo da meta. A equipa de rede realizou uma análise de tráfego utilizando a plataforma Purple e descobriu que o tráfego de background app refresh estava a consumir 38 por cento do tempo de antena disponível no SSID de convidados durante os períodos de pico de check-in, entre as 15:00 e as 18:00. Foi implementada uma lista de bloqueio direcionada cobrindo 847 domínios conhecidos de analítica e redes de publicidade. Em duas semanas, o débito médio por dispositivo ligado aumentou 34 por cento durante os períodos de pico, e as pontuações de satisfação com o WiFi dos convidados melhoraram 22 pontos no acompanhamento interno de NPS da propriedade. O segundo cenário é uma cadeia de retalho regional com 60 lojas em Inglaterra e no País de Gales. Cada loja executa um SSID de WiFi de convidados utilizado tanto por clientes como pela sinalização digital interna. A equipa de TI vinha a receber reclamações sobre a latência da sinalização digital — os ecrãs ficavam em buffering durante os períodos de maior atividade comercial. A análise de tráfego revelou que os dispositivos dos clientes que se ligavam ao SSID de convidados estavam a gerar um tráfego de fundo substancial, incluindo verificações de atualizações do iOS que estavam a descarregar payloads de vários gigabytes através da rede da loja. Uma combinação de bloqueio ao nível de DNS para endpoints de analítica e um limite estrito de largura de banda de 1 megabit por segundo para o tráfego identificado de atualizações do SO resolveu inteiramente o problema de latência da sinalização. A correção demorou menos de quatro horas a ser implementada em toda a infraestrutura utilizando a gestão centralizada de políticas. Deixe-me agora abordar os passos de implementação que precisa de seguir para implementar isto no seu próprio ambiente. O passo um é a medição da linha de base. Antes de tocar em qualquer configuração, precisa de compreender o seu perfil de tráfego atual. Implemente uma ferramenta de análise de tráfego — a plataforma WiFi Analytics da Purple fornece isto nativamente — e execute-a durante um mínimo de cinco dias úteis para capturar padrões de dias de semana e fins de semana. Procura a proporção de tráfego destinado a destinos conhecidos de background-refresh, os períodos de pico de atividade de fundo e as taxas de consumo por dispositivo. O passo dois é construir a sua lista de bloqueio. Comece com a lista de bloqueio de domínios OISD como base — é bem mantida, validada pela comunidade e cobre os principais endpoints de analítica e redes de publicidade. Complemente isto com as suas próprias observações da análise de tráfego. Criticamente, não bloqueie indiscriminadamente. Determinado tráfego de fundo — particularmente o Apple Push Notification Service na porta 5223 e o Google Firebase Cloud Messaging — é necessário para a funcionalidade do dispositivo. Bloquear estes serviços irá gerar reclamações dos utilizadores. Teste a sua lista de bloqueio num ambiente de testes ou num único grupo de pontos de acesso antes de a implementar em toda a infraestrutura. O passo três é a implementação de políticas. Aplique as suas regras de classificação ao nível do controlador WLAN, não nos pontos de acesso individuais. Isto garante a consistência e simplifica a gestão contínua. Se o seu controlador suportar QoS com deteção de aplicações, utilize a marcação DSCP para despriorizar as categorias de fundo em vez de bloquear rigidamente tudo — isto dá-lhe uma transição mais suave e reduz o risco de consequências indesejadas. O passo quatro é a monitorização contínua. Os endpoints de background refresh mudam. Surgem novos SDK de analítica. Os programadores de aplicações encontram novas formas de comunicar com os servidores. A sua lista de bloqueio precisa de ser revista e atualizada, no mínimo, trimestralmente. Automatize isto sempre que possível utilizando feeds de inteligência de ameaças que incluam atualizações de redes de publicidade e analítica. Do ponto de vista da conformidade, vale a pena notar que a classificação e o bloqueio de tráfego na camada de rede não constituem interceção ao abrigo do RIPA ou legislação equivalente, desde que não esteja a inspecionar o conteúdo de payloads encriptados. Está a agir sobre metadados de destino — endereços IP e nomes de domínio — e não sobre o conteúdo das comunicações. Isto é consistente com os fundamentos de interesses legítimos do Artigo 6.º do GDPR para a gestão de redes, mas deve documentar a sua política e garantir que a mesma é referenciada na sua política de utilização aceitável da rede e no aviso de privacidade. Agora, alguns erros comuns a evitar. O primeiro é o bloqueio excessivo. As equipas que implementam listas de bloqueio agressivas sem testes adequados descobrem frequentemente que quebraram inadvertidamente funcionalidades de aplicações em que os utilizadores confiam. Mantenha sempre uma lista de permissões para serviços críticos e tenha um plano de reversão preparado. O segundo erro é ignorar a divisão das bandas de 5 GHz e 6 GHz. O tráfego de background refresh tende a agrupar-se em 2.4 GHz porque os dispositivos mais antigos e os endpoints de IoT utilizam essa banda por predefinição. Se apenas estiver a analisar o tráfego de 5 GHz, poderá estar a perder a maior parte do problema. Certifique-se de que a sua análise cobre todas as bandas. O terceiro erro é tratar isto como uma correção única. Os padrões de tráfego de background refresh evoluem continuamente. Uma lista de bloqueio que era abrangente há seis meses pode estar a falhar 30 por cento dos endpoints de analítica atuais. Integre uma cadência de revisão no seu calendário de gestão de rede. Deixe-me terminar com um conjunto rápido de perguntas que ouço regularmente de arquitetos de rede. "O bloqueio do tráfego de analítica afetará o desempenho das aplicações para os meus utilizadores?" Na maioria dos casos, não. Os beacons de analítica funcionam no modelo "enviar e esquecer". A aplicação não espera por uma resposta antes de continuar a funcionar. O utilizador não irá notar. "Isto funciona com DNS encriptado?" O tráfego padrão de DNS-over-HTTPS pode contornar o bloqueio tradicional baseado em DNS. Precisa de intercetar o DoH no gateway ou utilizar o bloqueio ao nível de IP para gamas de analítica conhecidas, além do bloqueio de DNS. Ambas as abordagens são suportadas em controladores de classe empresarial. "E quanto aos dispositivos BYOD num SSID corporativo?" Aplicam-se os mesmos princípios, mas tem opções adicionais, incluindo autenticação 802.1X e aplicação de políticas por utilizador. Para um SSID corporativo, pode ser mais prescritivo sobre qual o tráfego de fundo permitido. "Como justifico o investimento à administração?" O caso de ROI é simples. Recuperar 30 a 40 por cento do tempo de antena desperdiçado é equivalente a adicionar 30 a 40 por cento mais capacidade à sua infraestrutura existente — sem comprar um único ponto de acesso adicional. Para um local que estava a considerar uma atualização de hardware para resolver reclamações de capacidade, a gestão de tráfego ao nível da rede pode adiar essa despesa de capital em dois a três anos. Para resumir as principais ações deste briefing. Primeiro, execute uma análise de linha de base do tráfego — não pode gerir o que não pode medir. Segundo, implemente uma lista de bloqueio mantida que vise endpoints conhecidos de analítica e redes de publicidade. Terceiro, utilize a limitação de largura de banda para o tráfego de atualizações do SO durante as horas de pico de comércio ou eventos. Quarto, monitorize continuamente e atualize as suas políticas trimestralmente. E quinto, documente a sua abordagem para fins de conformidade. Se quiser ver como a plataforma da Purple apresenta estes dados e permite a implementação de políticas em infraestruturas multi-site, o link está nas notas do programa. Obrigado pelo seu tempo.