Come il Background App Refresh distrugge le prestazioni del WiFi pubblico

Come il Background App Refresh distrugge le prestazioni del WiFi pubblico — Un briefing tecnico di Purple. Benvenuti. Se siete responsabili di una rete WiFi per gli ospiti — che si tratti di un hotel, di un punto vendita, di uno stadio o di un centro congressi — questo briefing cambierà il vostro modo di concepire il budget del tempo di trasmissione (air time). Vi guiderò attraverso uno dei fattori di riduzione della capacità più sottovalutati nelle implementazioni wireless pubbliche: il background app refresh. Vedremo cos'è a livello di protocollo, perché è particolarmente distruttivo negli ambienti ad alta densità e — cosa più importante — cosa potete fare oggi a livello di rete per contrastarlo. Iniziamo con la portata del problema. Ogni smartphone che i vostri ospiti collegano alla vostra rete esegue tra le 30 e le 80 applicazioni installate. Di queste, una percentuale significativa è configurata per eseguire cicli di aggiornamento in background — interrogando server di analisi, sincronizzando dati in cloud, recuperando token di notifiche push, verificando aggiornamenti del sistema operativo e inviando ping alle reti pubblicitarie. Su iOS, la funzione Background App Refresh di Apple è stata introdotta in iOS 7 ed è rimasta una presenza costante da allora. Android ha il suo equivalente tramite le API JobScheduler e WorkManager. Il punto chiave è questo: questi processi vengono eseguiti indipendentemente dal fatto che l'utente stia utilizzando attivamente il proprio dispositivo. Si attivano in modo silenzioso, invisibile e costante. Ora, su una connessione a banda larga domestica con uno o due dispositivi, questo è essenzialmente invisibile. Ma se si passa a un centro congressi con 1.200 delegati o a un flagship store con 400 connessioni ospiti simultanee, l'aritmetica diventa molto rapidamente problematica. Le ricerche sulle distribuzioni wireless aziendali mostrano costantemente che il traffico in background — beacon di analisi, verifiche degli aggiornamenti del sistema operativo, ping delle reti pubblicitarie, polling delle notifiche push, sincronizzazione cloud e cicli di aggiornamento dei social media — può rappresentare tra il 30 e il 45 percento della capacità totale degli access point su una rete ospiti affollata. Si tratta di capacità che viene negata ai vostri utenti legittimi — quelli che cercano di guardare una presentazione in streaming, completare una transazione o semplicemente navigare. Vi illustro il quadro tecnico di ciò che accade realmente a livello radio. In una rete 802.11, ogni dispositivo che si associa a un access point compete per il tempo di trasmissione utilizzando il CSMA/CA — Carrier Sense Multiple Access con Collision Avoidance. Ogni richiesta di aggiornamento in background, per quanto piccolo sia il payload, richiede una sequenza di associazione completa: richiesta di probe, autenticazione, associazione, DHCP se necessario e quindi lo scambio di dati vero e proprio. In un'installazione ad alta densità, questo sovraccarico di contesa è significativo. Un singolo beacon di analisi da una singola app potrebbe trasferire solo 200 byte di dati, ma il sovraccarico di tale transazione sul mezzo wireless può consumare da 10 a 20 volte tanto in termini di tempo di trasmissione.Con il Wi-Fi 6 — IEEE 802.11ax — disponiamo di OFDMA e BSS Colouring che aiutano a gestire questo aspetto in modo più efficiente. Ma anche con questi miglioramenti, il problema fondamentale rimane: non è possibile recuperare il tempo di trasmissione (air time) consumato dal traffico in background a meno che non si intervenga a livello di rete. La radio non sa né le importa se un pacchetto appartiene a un utente che guarda un video o a un'app che comunica silenziosamente con un server di telemetria in Virginia. È qui che la deep packet inspection e la classificazione del traffico diventano strumenti critici nella tua architettura. Un motore di classificazione del traffico correttamente configurato, posizionato in linea tra il controller wireless e il gateway a monte, può identificare il traffico di aggiornamento in background in base alla sua destinazione, alla firma del payload e al suo modello comportamentale. Gli endpoint di analisi noti — Google Analytics, Firebase, Crashlytics, Flurry, Amplitude, Mixpanel e decine di altri — presentano intervalli IP e modelli di dominio ben documentati. Anche gli endpoint delle reti pubblicitarie di DoubleClick, AppNexus e piattaforme simili sono altrettanto ben catalogati. Una block list aggiornata regolarmente, applicata a livello DNS o IP, può intercettare queste richieste prima che consumino una quantità significativa di larghezza di banda. L'approccio è indipendente dal fornitore. Sia che tu stia eseguendo Cisco Catalyst Centre, Aruba Central, Juniper Mist o una distribuzione Ruckus SmartZone, il principio è lo stesso: classificare, quindi agire. Hai tre opzioni per gestire il traffico in background identificato. Puoi bloccarlo completamente — l'approccio più aggressivo e il più efficace per il recupero della capacità. Puoi limitarne la velocità (rate-limit) — consentendo il passaggio del traffico ma fissando un limite massimo di larghezza di banda definita, in genere 64 kilobit al secondo per dispositivo per le categorie in background. Oppure puoi deprioritizzarlo utilizzando le marcature QoS DSCP, spingendolo alla classe di traffico più bassa in modo che consumi tempo di trasmissione solo quando non vi è altro traffico in competizione. Per la maggior parte dei gestori di sedi fisiche, una combinazione di blocco degli endpoint di analisi e reti pubblicitarie noti, unita alla limitazione della velocità del traffico di aggiornamento del sistema operativo durante le ore di punta, offre il miglior equilibrio tra recupero della capacità ed esperienza utente. Ora ti guiderò attraverso due scenari di implementazione reali in cui questo approccio ha fatto una differenza misurabile. Il primo è un hotel a quattro stelle da 340 camere nelle Midlands, nel Regno Unito. La struttura aveva investito in una moderna infrastruttura Wi-Fi 6: 48 access point distribuiti tra piani ospiti, sale conferenze e aree comuni. Nonostante l'investimento nell'hardware, i punteggi di soddisfazione degli ospiti per il WiFi erano costantemente al di sotto del target. Il team di rete ha eseguito un'analisi del traffico utilizzando la piattaforma Purple e ha scoperto che il traffico di aggiornamento delle app in background consumava il 38% del tempo di trasmissione disponibile sull'SSID degli ospiti durante i periodi di picco dei check-in, tra le 15:00 e le 18:00. È stata implementata una block list mirata che copriva 847 domini noti di analisi e reti pubblicitarie. Nel giro di due settimane, la velocità di trasmissione media per dispositivo connesso è aumentata del 34% durante i periodi di picco e i punteggi di soddisfazione del WiFi degli ospiti sono migliorati di 22 punti nel tracciamento NPS interno della struttura. Il secondo scenario riguarda una catena di vendita al dettaglio regionale con 60 negozi in Inghilterra e Galles. Ogni negozio gestisce un SSID WiFi per gli ospiti utilizzato sia dai clienti che dalla segnaletica digitale in-store. Il team IT riceveva lamentele sulla latenza della segnaletica digitale: gli schermi mostravano buffering durante i periodi di maggiore attività commerciale. L'analisi del traffico ha rivelato che i dispositivi dei clienti che si connettevano all'SSID degli ospiti generavano un traffico in background sostanziale, inclusi i controlli degli aggiornamenti iOS che scaricavano payload multi-gigabyte attraverso la rete del negozio. Una combinazione di blocco a livello DNS per gli endpoint di analisi e un limite rigido di velocità di 1 megabit al secondo per il traffico di aggiornamento del sistema operativo identificato ha risolto completamente il problema di latenza della segnaletica. L'implementazione della correzione ha richiesto meno di quattro ore in tutto il parco installato grazie alla gestione centralizzata delle policy. Permettetemi ora di illustrare i passaggi di implementazione da seguire per distribuire questa soluzione nel vostro ambiente. Il primo passo è la misurazione del baseline. Prima di toccare qualsiasi configurazione, è necessario comprendere il profilo di traffico attuale. Distribuite uno strumento di analisi del traffico (la piattaforma Purple WiFi Analytics offre questa funzionalità in modo nativo) e avviatelo per un minimo di cinque giorni lavorativi per acquisire i pattern dei giorni feriali e del fine settimana. Dovete individuare la percentuale di traffico diretta verso destinazioni note di aggiornamento in background, i periodi di picco dell'attività in background e i tassi di consumo per singolo dispositivo. Il secondo passo è la creazione della block list. Iniziate con la block list dei domini OISD come base: è ben gestita, convalidata dalla community e copre i principali endpoint di analisi e reti pubblicitarie. Integrate questa lista con le vostre osservazioni derivanti dall'analisi del traffico. Aspetto fondamentale: non bloccate indiscriminatamente. Alcuni tipi di traffico in background, in particolare l'Apple Push Notification Service sulla porta 5223 e Google Firebase Cloud Messaging, sono necessari per la funzionalità dei dispositivi. Bloccarli genererà lamentele da parte degli utenti. Testate la vostra block list in un ambiente di staging o su un singolo gruppo di access point prima di distribuirla su tutto il parco installato. La terza fase è la distribuzione delle policy. Applica le tue regole di classificazione a livello di controller WLAN, non sui singoli access point. Questo garantisce coerenza e semplifica la gestione continua. Se il tuo controller supporta il QoS sensibile alle applicazioni, utilizza la marcatura DSCP per declassare le categorie in background anziché bloccare tutto in modo rigido: questo ti offre un approccio più morbido e riduce il rischio di conseguenze impreviste. La quarta fase è il monitoraggio continuo. Gli endpoint per il refresh in background cambiano. Emergono nuovi SDK di analisi. Gli sviluppatori di app trovano nuovi modi per comunicare con i server. La tua block list deve essere rivista e aggiornata almeno trimestralmente. Automatizza questo processo, laddove possibile, utilizzando feed di threat intelligence che includano aggiornamenti sulle reti pubblicitarie e di analisi. Dal punto di vista della conformità, vale la pena notare che la classificazione e il blocco del traffico a livello di rete non costituiscono intercettazione ai sensi del RIPA o di legislazioni equivalenti, a condizione che non si ispezioni il contenuto dei payload crittografati. Stai agendo sui metadati di destinazione (indirizzi IP e nomi di dominio) e non sul contenuto delle comunicazioni. Ciò è coerente con i motivi di legittimo interesse dell'Articolo 6 del GDPR per la gestione della rete, ma dovresti documentare la tua policy e assicurarti che sia citata nella tua policy di utilizzo accettabile della rete e nell'informativa sulla privacy. Ora, ecco alcune trappole comuni da evitare. La prima è il blocco eccessivo. I team che distribuiscono block list aggressive senza test adeguati scoprono spesso di aver inavvertitamente interrotto funzionalità di app su cui gli utenti fanno affidamento. Mantieni sempre una whitelist per i servizi critici e tieni pronto un piano di rollback. La seconda trappola è ignorare la suddivisione delle bande a 5 GHz e 6 GHz. Il traffico di refresh in background tende a concentrarsi sulla banda a 2,4 GHz perché i dispositivi più vecchi e gli endpoint IoT si sintonizzano per impostazione predefinita su quella banda. Se analizzi solo il traffico a 5 GHz, potresti perdere la maggior parte del problema. Assicurati che la tua analisi copra tutte le bande. La terza trappola è considerare questo intervento come una soluzione una tantum. I pattern del traffico di refresh in background si evolvono continuamente. Una block list che era completa sei mesi fa potrebbe tralasciare il 30% degli attuali endpoint di analisi. Inserisci una cadenza di revisione nel calendario di gestione della rete. Vorrei concludere con una serie rapida di domande che sento regolarmente dai network architect. "Il blocco del traffico di analisi influirà sulle prestazioni delle app per i miei utenti?" Nella maggior parte dei casi, no. I beacon di analisi sono di tipo "invia e dimentica". L'app non attende una risposta prima di continuare a funzionare. L'utente non se ne accorgerà. "Questo funziona con il DNS crittografato?" Il traffico DNS-over-HTTPS standard può aggirare il blocco tradizionale basato su DNS. È necessario intercettare il DoH a livello di gateway o utilizzare il blocco a livello IP per gli intervalli di analisi noti, oltre al blocco DNS. Entrambi gli approcci sono supportati nei controller di livello enterprise. "Che dire dei dispositivi BYOD su un SSID aziendale?" Si applicano gli stessi principi, ma si dispone di opzioni aggiuntive, tra cui l'autenticazione 802.1X e l'applicazione di policy per singolo utente. Per un SSID aziendale, è possibile essere più prescrittivi su quale traffico in background sia consentito. "Come posso giustificare l'investimento al consiglio di amministrazione?" Il caso di ROI è semplice. Recuperare dal 30 al 40 percento del tempo di trasmissione sprecato equivale ad aggiungere dal 30 al 40 percento di capacità in più alla vostra infrastruttura esistente, senza acquistare un solo access point aggiuntivo. Per una sede che stava valutando un aggiornamento dell'hardware per risolvere i reclami sulla capacità, la gestione del traffico a livello di rete può differire tale spesa in conto capitale di due o tre anni. Per riassumere le azioni chiave di questo briefing. In primo luogo, eseguite un'analisi di base del traffico: non è possibile gestire ciò che non si può misurare. In secondo luogo, distribuite una block list aggiornata che si rivolga agli endpoint noti delle reti pubblicitarie e di analisi. In terzo luogo, utilizzate la limitazione della larghezza di banda per il traffico di aggiornamento del sistema operativo durante le ore di punta delle vendite o degli eventi. In quarto luogo, monitorate continuamente e aggiornate le vostre policy trimestralmente. E in quinto luogo, documentate il vostro approccio a fini di conformità. Se desiderate vedere come la piattaforma di Purple evidenzia questi dati e consente la distribuzione delle policy in proprietà multi-sito, il link si trova nelle note dello show. Grazie per il vostro tempo.