Cómo el Background App Refresh destruye el rendimiento del WiFi público

Cómo el Background App Refresh destruye el rendimiento del WiFi público — Un informe técnico de Purple. Bienvenido. Si es responsable de una red WiFi de invitados, ya sea en un hotel, un complejo de retail, un estadio o un centro de conferencias, este informe cambiará su forma de pensar sobre su presupuesto de tiempo de aire. Le guiaré a través de uno de los destructores de capacidad más subestimados en las implementaciones inalámbricas públicas: el background app refresh. Analizaremos qué es a nivel de protocolo, por qué es particularmente destructivo en entornos de alta densidad y, lo más importante, qué puede hacer al respecto en la capa de red hoy mismo. Comencemos con la magnitud del problema. Cada smartphone que sus invitados llevan a su red ejecuta entre 30 y 80 aplicaciones instaladas. De ellas, una proporción significativa está configurada para ejecutar ciclos de background app refresh: sondeando servidores de analítica, sincronizando datos en la nube, obteniendo tokens de notificaciones push, buscando actualizaciones de SO y enviando pings a redes publicitarias. En iOS, la función Background App Refresh de Apple se introdujo en iOS 7 y ha sido una característica constante desde entonces. Android tiene su propio equivalente a través de las API JobScheduler y WorkManager. El punto clave es este: estos procesos se ejecutan independientemente de si el usuario está utilizando activamente su dispositivo. Se activan de forma silenciosa, invisible y constante. Ahora bien, en una conexión de banda ancha doméstica con uno o dos dispositivos, esto es esencialmente invisible. Pero si escalamos eso a un centro de conferencias con 1,200 delegados, o a una tienda insignia de retail con 400 conexiones de invitados concurrentes, la aritmética se vuelve muy complicada rápidamente. Las investigaciones sobre implementaciones inalámbricas empresariales muestran de manera constante que el tráfico de fondo (balizas de analítica, comprobaciones de actualizaciones de SO, pings de redes publicitarias, sondeos de notificaciones push, sincronización en la nube y ciclos de actualización de redes sociales) puede representar entre el 30 y el 45 por ciento de la capacidad total de los puntos de acceso en una red de invitados concurrida. Esa es capacidad que se les está negando a sus usuarios legítimos, aquellos que intentan transmitir una presentación, completar una transacción o simplemente navegar. Permítame darle el panorama técnico de lo que realmente está sucediendo en la capa de radio. En una red 802.11, cada dispositivo que se asocia con un punto de acceso compite por el tiempo de aire utilizando CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Cada solicitud de actualización en segundo plano, por pequeña que sea la carga útil, requiere una secuencia de asociación completa: solicitud de sondeo, autenticación, asociación, DHCP si es necesario y luego el intercambio de datos en sí. En una implementación de alta densidad, esta sobrecarga de contención es significativa. Una sola baliza de analítica de una sola aplicación puede transferir solo 200 bytes de datos, pero la sobrecarga de esa transacción en el medio inalámbrico puede consumir de 10 a 20 veces más en tiempo de aire. Con Wi-Fi 6 (IEEE 802.11ax) tenemos OFDMA y BSS Colouring, que ayudan a gestionar esto de manera más eficiente. Pero incluso con estas mejoras, el problema fundamental permanece: no se puede recuperar el tiempo de aire consumido por el tráfico de fondo a menos que se intervenga en la capa de red. El radio no sabe ni le importa si un paquete es de un usuario que ve un video o de una aplicación que llama silenciosamente a un servidor de telemetría en Virginia. Aquí es donde la inspección profunda de paquetes y la clasificación de tráfico se convierten en herramientas críticas en su arquitectura. Un motor de clasificación de tráfico correctamente configurado, situado en línea entre su controlador inalámbrico y su puerta de enlace ascendente, puede identificar el tráfico de background app refresh por su destino, su firma de carga útil y su patrón de comportamiento. Los puntos de enlace de analítica conocidos (Google Analytics, Firebase, Crashlytics, Flurry, Amplitude, Mixpanel y docenas de otros) tienen rangos de IP y patrones de dominio bien documentados. Los puntos de enlace de redes publicitarias de DoubleClick, AppNexus y plataformas similares están igualmente bien catalogados. Una lista de bloqueo actualizada periódicamente, aplicada en la capa de DNS o IP, puede interceptar estas solicitudes antes de que consuman un ancho de banda significativo. El enfoque es neutral respecto al proveedor. Ya sea que esté ejecutando Cisco Catalyst Centre, Aruba Central, Juniper Mist o una implementación de Ruckus SmartZone, el principio es el mismo: clasificar y luego actuar. Tiene tres opciones para manejar el tráfico de fondo identificado. Puede bloquearlo por completo, el enfoque más agresivo y el más eficaz para la recuperación de capacidad. Puede limitar su velocidad, permitiendo que el tráfico pase pero limitándolo a un techo de ancho de banda definido, normalmente 64 kilobits por segundo por dispositivo para las categorías de fondo. O puede despriorizarlo utilizando marcados QoS DSCP, empujándolo a la clase de tráfico más baja para que solo consuma tiempo de aire cuando ningún otro tráfico esté compitiendo. Para la mayoría de los operadores de recintos, una combinación de bloqueo de puntos de enlace de analítica y redes publicitarias conocidos, junto con la limitación de velocidad del tráfico de actualizaciones de SO durante las horas pico, ofrece el mejor equilibrio entre recuperación de capacidad y experiencia del usuario. Ahora permítame guiarle a través de dos escenarios de implementación del mundo real donde esto marcó una diferencia medible. El primero es un hotel de cuatro estrellas con 340 habitaciones en la región de Midlands, Reino Unido. La propiedad había invertido en una infraestructura moderna de Wi-Fi 6: 48 puntos de acceso distribuidos en pisos de huéspedes, suites de conferencias y áreas públicas. A pesar de la inversión en hardware, las puntuaciones de satisfacción de los huéspedes para el WiFi estaban constantemente por debajo del objetivo. El equipo de red realizó un análisis de tráfico utilizando la plataforma Purple y descubrió que el tráfico de background app refresh consumía el 38 por ciento del tiempo de aire disponible en el SSID de invitados durante los períodos pico de registro entre las 3 y las 6 PM. Se implementó una lista de bloqueo específica que cubría 847 dominios conocidos de analítica y redes publicitarias. En dos semanas, el rendimiento promedio por dispositivo conectado aumentó en un 34 por ciento durante los períodos pico, y las puntuaciones de satisfacción del WiFi de los huéspedes mejoraron en 22 puntos en el seguimiento interno de NPS de la propiedad. El segundo escenario es una cadena de retail regional con 60 tiendas en Inglaterra y Gales. Cada tienda tiene un SSID de WiFi para invitados utilizado tanto por los clientes como por la señalización digital de la tienda. El equipo de TI había estado recibiendo quejas sobre la latencia de la señalización digital: las pantallas se congelaban durante los períodos comerciales de mayor actividad. El análisis de tráfico reveló que los dispositivos de los clientes que se conectaban al SSID de invitados generaban un tráfico de fondo sustancial, incluidas comprobaciones de actualización de iOS que descargaban cargas útiles de varios gigabytes a través de la red de la tienda. Una combinación de bloqueo a nivel de DNS para los puntos de enlace de analítica y un límite estricto de velocidad de 1 megabit por segundo para el tráfico identificado de actualizaciones de SO resolvió por completo el problema de latencia de la señalización. La solución tardó menos de cuatro horas en implementarse en todo el patrimonio de tiendas utilizando la gestión de políticas centralizada. Permítame ahora cubrir los pasos de implementación que debe seguir para desplegar esto en su propio entorno. El paso uno es la medición de la línea base. Antes de tocar cualquier configuración, debe comprender su perfil de tráfico actual. Implemente una herramienta de análisis de tráfico (la plataforma WiFi Analytics de Purple proporciona esto de forma nativa) y ejecútela durante un mínimo de cinco días hábiles para capturar los patrones de los días de semana y los fines de semana. Debe buscar la proporción de tráfico que se dirige a destinos conocidos de background app refresh, los períodos pico de actividad de fondo y las tasas de consumo por dispositivo. El paso dos es crear su lista de bloqueo. Comience con la lista de bloqueo de dominios OISD como base: está bien mantenida, validada por la comunidad y cubre los principales puntos de enlace de analítica y redes publicitarias. Complemente esto con sus propias observaciones del análisis de tráfico. Es fundamental que no bloquee de forma indiscriminada. Cierto tráfico de fondo, en particular el Servicio de Notificaciones Push de Apple en el puerto 5223 y Google Firebase Cloud Messaging, es necesario para la funcionalidad del dispositivo. Bloquear estos servicios generará quejas de los usuarios. Pruebe su lista de bloqueo en un entorno de pruebas o en un solo grupo de puntos de acceso antes de implementarla en todo el recinto. El paso tres es la implementación de políticas. Aplique sus reglas de clasificación a nivel del controlador WLAN, no en los puntos de acceso individuales. Esto garantiza la coherencia y simplifica la gestión continua. Si su controlador admite QoS con reconocimiento de aplicaciones, utilice el marcado DSCP para despriorizar las categorías de fondo en lugar de bloquear todo de forma estricta; esto le brinda una transición más suave y reduce el riesgo de consecuencias no deseadas. El paso cuatro es el monitoreo continuo. Los puntos de enlace de fondo cambian. Surgen nuevos SDK de analítica. Los desarrolladores de aplicaciones encuentran nuevas formas de enviar datos. Su lista de bloqueo debe revisarse y actualizarse como mínimo trimestralmente. Automatice esto siempre que sea posible utilizando fuentes de inteligencia de amenazas que incluyan actualizaciones de redes publicitarias y de analítica. Desde la perspectiva del cumplimiento, vale la pena señalar que la clasificación y el bloqueo de tráfico en la capa de red no constituyen una interceptación bajo la legislación RIPA o equivalente, siempre que no esté inspeccionando el contenido de las cargas útiles cifradas. Está actuando sobre metadatos de destino (direcciones IP y nombres de dominio), no sobre el contenido de las comunicaciones. Esto es coherente con los motivos de interés legítimo del Artículo 6 del GDPR para la gestión de redes, pero debe documentar su política y asegurarse de que se haga referencia a ella en su política de uso aceptable de la red y en su aviso de privacidad. Ahora, algunos errores comunes que se deben evitar. El primero es el bloqueo excesivo. Los equipos que implementan listas de bloqueo agresivas sin las pruebas adecuadas con frecuencia descubren que han roto inadvertidamente la funcionalidad de aplicaciones en las que confían los usuarios. Mantenga siempre una lista de permitidos para servicios críticos y tenga listo un plan de reversión. El segundo error es ignorar la división de bandas de 5 GHz y 6 GHz. El tráfico de background app refresh tiende a agruparse en 2.4 GHz porque los dispositivos más antiguos y los puntos de enlace de IoT se conectan de forma predeterminada a esa banda. Si solo está analizando el tráfico de 5 GHz, es posible que se esté perdiendo la mayor parte del problema. Asegúrese de que su análisis cubra todas las bandas. El tercer error es tratar esto como una solución de una sola vez. Los patrones de tráfico de background app refresh evolucionan continuamente. Una lista de bloqueo que era completa hace seis meses puede estar perdiendo el 30 por ciento de los puntos de enlace de analítica actuales. Incorpore una cadencia de revisión en su calendario de gestión de red. Permítame cerrar con una serie de preguntas rápidas que escucho regularmente de los arquitectos de red. "¿Bloquear el tráfico de analítica afectará el rendimiento de las aplicaciones para mis usuarios?" En la mayoría de los casos, no. Las balizas de analítica se envían y se olvidan. La aplicación no espera una respuesta antes de seguir funcionando. El usuario no lo notará. "¿Funciona esto con DNS cifrado?" El tráfico estándar de DNS sobre HTTPS puede eludir el bloqueo tradicional basado en DNS. Debe interceptar DoH en la puerta de enlace o utilizar el bloqueo a nivel de IP para rangos de analítica conocidos, además del bloqueo de DNS. Ambos enfoques son compatibles con los controladores de nivel empresarial. "¿Qué pasa con los dispositivos BYOD en un SSID corporativo?" Se aplican los mismos principios, pero tiene opciones adicionales que incluyen la autenticación 802.1X y la aplicación de políticas por usuario. Para un SSID corporativo, puede ser más prescriptivo sobre qué tráfico de fondo está permitido. "¿Cómo justifico la inversión ante la junta directiva?" El caso de ROI es sencillo. Recuperar entre el 30 y el 40 por ciento del tiempo de aire desperdiciado equivale a agregar entre un 30 y un 40 por ciento más de capacidad a su infraestructura existente, sin comprar un solo punto de acceso adicional. Para un recinto que estaba considerando una actualización de hardware para abordar las quejas de capacidad, la gestión del tráfico a nivel de red puede aplazar ese gasto de capital de dos a tres años. Para resumir las acciones clave de este informe. Primero, realice un análisis de línea base de tráfico: no puede gestionar lo que no puede medir. Segundo, implemente una lista de bloqueo mantenida que apunte a los puntos de enlace de analítica y redes publicitarias conocidos. Tercero, utilice la limitación de velocidad para el tráfico de actualizaciones de SO durante las horas pico de comercio o eventos. Cuarto, monitoree continuamente y update sus políticas trimestralmente. Y quinto, documente su enfoque para fines de cumplimiento. Si desea ver cómo la plataforma de Purple presenta estos datos y permite la implementación de políticas en propiedades de múltiples sitios, el enlace está en las notas del programa. Gracias por su tiempo.