Riduzione della latenza su reti WiFi ad alta densità

SCRIPT PER PODCAST — "Ridurre la latenza sulle reti WiFi ad alta densità" Tempo di esecuzione: circa 10 minuti Voce: inglese britannico, maschile, tono da consulente senior — fiducioso, colloquiale, autorevole. --- [INTRODUZIONE — circa 1 minuto] Bentornati. Oggi andrò dritto al punto, perché questo è uno di quei temi in cui il divario tra ciò che la maggior parte dei team sta facendo e ciò che dovrebbe fare ha un costo reale per l'azienda. Parliamo di latenza sulle reti WiFi ad alta densità — e in particolare, del perché il DNS sia il colpevole nascosto che quasi nessuno prende in considerazione. Se gestite il WiFi in un hotel, in uno stadio, in un centro congressi o in un grande punto vendita, vi sarà sicuramente capitato di sentire la frase: "La rete è lenta". E l'istinto è sempre quello di controllare la densità degli access point, l'utilizzo dei canali o la capacità di backhaul. Elementi importanti, certo. Ma c'è un livello sottostante a tutto questo — il livello DNS — in cui si rischia di perdere latenza su ogni singolo dispositivo, per ogni singolo caricamento di pagina, prima ancora che venga trasferito un solo byte di contenuto effettivo. Questo è ciò che analizzeremo oggi. Vi guiderò attraverso i meccanismi tecnici, vi presenterò due scenari di implementazione concreti e vi lascerò con una serie di azioni chiare che potrete proporre al vostro team già questa settimana. --- [APPROFONDIMENTO TECNICO — circa 5 minuti] Partiamo dalle basi. Quando un dispositivo si connette al vostro WiFi e un utente apre un browser o un'app, cosa succede in realtà come prima cosa? Prima di recuperare qualsiasi contenuto, il dispositivo deve risolvere i nomi di dominio in indirizzi IP. Questo è il DNS. E su un moderno smartphone, il caricamento di una singola pagina — ad esempio, un articolo di giornale o la pagina di prenotazione di un hotel — può attivare tra le 20 e le 70 query DNS. Non perché la pagina stessa contenga 70 domini, ma perché è ricca di pixel di tracciamento di terze parti, script pubblicitari, beacon di analisi e widget di social media. Ognuno di questi elementi avvia una query DNS. Ora, in un normale ambiente domestico o d'ufficio con una manciata di dispositivi, tutto questo è praticamente invisibile. Il resolver DNS gestisce la richiesta, la cache TTL fa il suo lavoro e il sovraccarico è trascurabile. Ma provate a mettere 500 dispositivi sullo stesso cluster di access point durante una conferenza, o 3.000 ospiti in un hotel nell'ora di punta del check-in, e vi troverete di fronte a una tempesta di query DNS. Il vostro resolver locale — ammesso che ne abbiate uno — si troverà a gestire decine di migliaia di query al minuto, una percentuale significativa delle quali si dirigerà verso l'internet pubblico per risolvere domini di reti pubblicitarie e servizi di tracciamento che non caricheranno mai contenuti di reale interesse per l'utente. Ecco l'intuizione fondamentale: ognuna di queste ricerche DNS non necessarie aggiunge latenza all'esperienza percepita dall'utente. Non stiamo parlando del tempo di caricamento del contenuto, bensì del tempo di risoluzione pre-caricamento. Su una rete congestionata, una singola query DNS a un risolutore esterno può richiedere da 80 a 150 millisecondi. Se una pagina avvia 15 ricerche di domini di tracciamento prima di iniziare a caricare il contenuto effettivo, hai appena aggiunto oltre un secondo di ritardo invisibile prima che l'utente veda qualcosa. Questo non è un problema di backhaul. Questo è un problema di DNS. La soluzione prevede due componenti. In primo luogo, distribuisci un risolutore DNS locale - idealmente on-premises o all'edge della tua rete - con un caching aggressivo. In questo caso funzionano bene Unbound, Pi-hole in modalità enterprise o equivalenti commerciali di fornitori come Cisco Umbrella o Infoblox. L'obiettivo è risolvere la maggior parte delle query dalla cache, in meno di 5 millisecondi, senza passare affatto per l'internet pubblico. Per una sede ad alta densità, dovresti puntare a un tasso di successo della cache superiore al 70 percento per il funzionamento a regime. In secondo luogo, ed è qui che si ottengono i vantaggi reali: implementa il filtraggio DNS per eliminare le query per domini di tracciamento, pubblicità e telemetria noti a livello di risolutore. Quando arriva una query per un dominio di una rete pubblicitaria nota, il risolutore restituisce istantaneamente NXDOMAIN - dominio non trovato - in meno di un millisecondo. Il dispositivo riceve la sua risposta, smette di aspettare e passa alla ricerca successiva. Hai eliminato completamente il viaggio di andata e ritorno verso l'internet pubblico. Moltiplica questo valore per 15 domini di tracciamento per ogni caricamento di pagina, su 500 dispositivi simultanei, e la riduzione complessiva del volume di query DNS - e quindi della latenza - diventa sostanziale. C'è una sfumatura importante da considerare riguardo al DNS over HTTPS, o DoH. I browser e i sistemi operativi moderni aggirano sempre più spesso il tuo risolutore locale inviando query DNS direttamente a provider DoH come Cloudflare o Google tramite HTTPS crittografato. Questo è eccellente per la privacy in contesti consumer, ma mina completamente la tua strategia di caching e filtraggio locale in un ambiente gestito. È necessario intercettare o reindirizzare il traffico DoH a livello di firewall, o distribuire il proprio risolutore DoH a cui indirizzare i dispositivi tramite l'opzione DHCP 6 e le policy di rete. Questa è un'area di crescente complessità - se desideri approfondire specificamente le implicazioni del DoH, Purple offre una guida dedicata al DNS over HTTPS per il filtraggio del WiFi pubblico che vale la pena leggere. Ora consideriamo l'aspetto RF, perché l'ottimizzazione del DNS non esiste in un vuoto. In un deployment ad alta densità, in genere si utilizza lo standard 802.11ax - WiFi 6 o WiFi 6E - con OFDMA e BSS Colouring per gestire l'interferenza co-canale. Il motivo per cui il DNS è ancora più importante in questi ambienti è che i guadagni di efficienza di OFDMA si basano sul presupposto che il mezzo radio venga utilizzato per il trasferimento effettivo di dati, non per il sovraccarico dovuto alla risoluzione di centinaia di nomi di dominio non necessari. Ogni query DNS che va verso Internet è un piccolo pacchetto che occupa un'opportunità di trasmissione. Su larga scala, questo sovraccarico è misurabile in termini di throughput. La combinazione di caching DNS locale, filtraggio dei domini di tracciamento e un ambiente radio 802.11ax ben sintonizzato è il punto in cui si iniziano a vedere miglioramenti di svolta. Parliamo di ridurre la latenza percepita nel caricamento delle pagine dal 60 all'87 percento nei deployment reali, non in condizioni di laboratorio. --- [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI - circa 2 minuti] Bene, passiamo alla pratica. Se state pianificando questo intervento per un deployment, ecco come vi consiglierei di procedere. Iniziate con un audit del DNS. Prima di toccare qualsiasi cosa, analizzate il vostro resolver esistente - o implementate un tap DNS passivo - e acquisite i log delle query per un periodo da 24 a 48 ore. Troverete quasi certamente che dal 30 al 50 percento del volume delle query è diretto verso un set relativamente ristretto di domini di tracciamento e pubblicitari. Questo è il vostro punto di partenza ideale. Successivamente, implementate un resolver locale con una blocklist curata. Consiglierei di iniziare con un elenco conservativo - qualcosa come la lista di host consolidata di Steven Black o un equivalente commerciale - piuttosto che con uno aggressivo. Dovete evitare di bloccare domini da cui dipendono applicazioni legittime. Effettuate i test in una VLAN di staging prima di passare alla produzione. Per l'intercettazione del DoH, dovrete operare a livello di firewall. Bloccate le porte TCP e UDP 443 in uscita verso gli intervalli IP dei provider DoH noti - come 1.1.1.1 di Cloudflare o 8.8.8.8 di Google - e reindirizzate quelle query al vostro resolver DoH locale. Questo richiede il coordinamento con il vostro team di sicurezza, in particolare se vi trovate in un ambiente sensibile alle normative PCI DSS o GDPR, perché di fatto state eseguendo una forma di ispezione DNS. Documentate il processo, ottenete l'approvazione e assicuratevi che i termini di servizio del vostro Captive Portal riflettano la policy di filtraggio. La trappola più grande che vedo è l'adozione di un filtraggio troppo aggressivo da parte dei team, con conseguente aumento delle chiamate di supporto perché una specifica applicazione ha smesso di funzionare. Predisponete un processo di risposta rapida per le richieste di whitelist dei domini e monitorate i tassi di risposta NXDOMAIN. Se si impennano improvvisamente, significa che qualcosa è cambiato nelle dipendenze DNS di un'applicazione legittima. La seconda trappola è considerare questa configurazione come un'attività una tantum anziché come un'attività operativa continua. I domini di tracciamento cambiano. Emergono nuove reti pubblicitarie. La vostra blocklist deve essere aggiornata regolarmente - come minimo mensilmente, idealmente ogni settimana tramite un feed automatizzato. --- [Q&A RAPIDO - circa 1 minuto] Alcune domande che mi vengono poste regolarmente su questo argomento. "Il filtraggio DNS influisce sulla conformità al GDPR?" - In realtà può essere d'aiuto. Impedendo la risoluzione dei domini di tracciamento, si riducono i dati che le reti pubblicitarie di terze parti possono raccogliere sui vostri ospiti. Detto questo, documentate la vostra politica di filtraggio e inseritela nella vostra informativa sulla privacy. "E per quanto riguarda lo split DNS per le risorse interne?" - Assolutamente necessario. Il vostro resolver locale dovrebbe avere zone autorevoli per qualsiasi hostname interno, e questi non dovrebbero mai essere inoltrati all'esterno. Pratica standard, ma vale la pena ricordarlo. "Posso farlo su una piattaforma WiFi gestita in cloud?" - Sì, la maggior parte delle piattaforme enterprise - Cisco Meraki, Juniper Mist, Aruba Central - supporta l'assegnazione di server DNS personalizzati tramite DHCP. Indirizzate i dispositivi verso il vostro resolver locale e il filtraggio avviene lì, indipendentemente da quale piattaforma cloud gestisca i vostri AP. "Qual è il ROI di tutto questo?" - Punteggi di soddisfazione degli ospiti più elevati, riduzione del volume di ticket di assistenza per reclami su WiFi lento e miglioramenti misurabili nei tempi di caricamento del Captive Portal. Per un hotel, questo si traduce direttamente in migliori punteggi nelle recensioni. Per un centro congressi, fa la differenza tra una nuova prenotazione e un cliente perso. --- [RIASSUNTO E PROSSIMI PASSI - circa 1 minuto] Per riassumere: l'intervento singolo a più alto impatto e minor costo che si possa fare per ridurre la latenza del WiFi in un luogo ad alta densità è implementare un resolver DNS locale con filtraggio dei domini di tracciamento. Questo affronta la causa principale di una percentuale significativa della latenza percepita - non l'ambiente RF, non il backhaul, ma la tempesta di query DNS generata da ogni dispositivo sulla rete che risolve domini per contenuti che non verranno mai caricati. La vostra lista d'azione: eseguite un audit DNS questa settimana, pianificate l'implementazione di un resolver locale e concordate una strategia di blocklist con il vostro team di sicurezza. Se dovete gestire il bypass DoH, questo sarà il livello successivo da affrontare. La piattaforma [Guest WiFi] e gli strumenti di [WiFi Analytics] di Purple sono progettati esattamente con questo tipo di intelligenza di rete in mente - se volete vedere come l'ottimizzazione DNS si inserisce in una strategia WiFi più ampia per le vostre strutture, vale la pena fare una chiacchierata con il team di Purple. Grazie per l'ascolto. Alla prossima. --- FINE DELLO SCRIPT