Cómo la actualización en segundo plano de las aplicaciones destruye el rendimiento de la WiFi pública

Cómo Background App Refresh destruye el rendimiento del WiFi público: un informe técnico de Purple. Bienvenido. Si es responsable de una red WiFi para invitados, ya sea en un hotel, un establecimiento comercial, 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 factores destructores de capacidad más subestimados en los despliegues inalámbricos públicos: la actualización de aplicaciones en segundo plano. Analizaremos qué es a nivel de protocolo, por qué es especialmente destructivo en entornos de alta densidad y, lo más importante, qué puede hacer al respecto en la capa de red hoy mismo. Empecemos por la magnitud del problema. Cada smartphone que sus invitados conectan a su red ejecuta entre 30 y 80 aplicaciones instaladas. De ellas, una proporción significativa está configurada para ejecutar ciclos de actualización en segundo plano: consultar servidores de análisis, sincronizar datos en la nube, obtener tokens de notificaciones push, buscar actualizaciones del sistema operativo y hacer ping 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 prácticamente invisible. Pero si trasladamos eso a un centro de conferencias con 1.200 delegados o a una tienda insignia con 400 conexiones de invitados simultáneas, la aritmética se vuelve incómoda muy rápidamente. Las investigaciones sobre despliegues inalámbricos empresariales muestran sistemáticamente que el tráfico en segundo plano (balizas de análisis, comprobaciones de actualización del sistema operativo, 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 del punto de acceso en una red de invitados con mucha actividad. Esa es una capacidad que se está denegando a sus usuarios legítimos, aquellos que intentan transmitir una presentación, completar una transacción o simplemente navegar. Permítame ofrecerle un panorama técnico de lo que ocurre realmente 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, a continuación, el propio intercambio de datos. En un despliegue de alta densidad, esta sobrecarga de contención es significativa. Una sola baliza de análisis 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 entre 10 y 20 veces más de tiempo de aire.Con Wi-Fi 6 — IEEE 802.11ax —, disponemos de OFDMA y BSS Colouring, que ayudan a gestionar esto de forma más eficiente. Pero incluso con estas mejoras, el problema fundamental persiste: no se puede recuperar el tiempo de transmisión (airtime) consumido por el tráfico de fondo a menos que se intervenga en la capa de red. La radio no sabe ni le importa si un paquete pertenece a un usuario que ve un vídeo o a una aplicación que se comunica silenciosamente con un servidor de telemetría en Virginia. Aquí es donde la inspección profunda de paquetes (DPI) y la clasificación del 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 pasarela (gateway) ascendente, puede identificar el tráfico de actualización en segundo plano por su destino, su firma de carga útil (payload) y su patrón de comportamiento. Los endpoints 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 endpoints de redes publicitarias de DoubleClick, AppNexus y plataformas similares están igualmente catalogados. Una lista de bloqueo actualizada periódicamente, aplicada en la capa DNS o IP, puede interceptar estas solicitudes antes de que consuman un ancho de banda significativo. Este enfoque es independiente del fabricante. Ya sea que utilice Cisco Catalyst Centre, Aruba Central, Juniper Mist o un despliegue de Ruckus SmartZone, el principio es el mismo: clasificar y, después, actuar. Tiene tres opciones para gestionar el tráfico de fondo identificado. Puede bloquearlo por completo: el enfoque más agresivo y el más eficaz para recuperar capacidad. Puede limitar su ancho de banda (rate-limit), permitiendo el paso del tráfico pero limitándolo a un techo máximo definido, normalmente 64 kilobits por segundo por dispositivo para las categorías de segundo plano. O puede restarle prioridad utilizando marcas QoS DSCP, desplazándolo a la clase de tráfico más baja para que solo consuma tiempo de transmisión cuando no haya otro tráfico compitiendo. Para la mayoría de los operadores de recintos, una combinación de bloqueo de endpoints de analítica y redes publicitarias conocidos, junto con la limitación del tráfico de actualizaciones de sistemas operativos durante las horas punta, ofrece el mejor equilibrio entre la recuperación de capacidad y la experiencia del usuario. A continuación, le guiaré a través de dos escenarios de despliegue reales donde esto supuso una diferencia medible. El primero es un hotel de cuatro estrellas y 340 habitaciones en la región de las Midlands del Reino Unido. El establecimiento había invertido en una moderna infraestructura Wi-Fi 6: 48 puntos de acceso distribuidos en las plantas de huéspedes, salas de conferencias y zonas públicas. A pesar de la inversión en hardware, las puntuaciones de satisfacción de los huéspedes con el WiFi se situaban sistemáticamente 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 actualización en segundo plano de las aplicaciones consumía el 38 por ciento del tiempo de transmisión disponible en el SSID de invitados durante los periodos de máxima afluencia de registros, entre las 15:00 y las 18:00. Se implementó una lista de bloqueo específica que cubría 847 dominios conocidos de análisis y redes publicitarias. En dos semanas, el rendimiento medio por dispositivo conectado aumentó un 34 por ciento durante los periodos de máxima actividad, y las puntuaciones de satisfacción con el WiFi de invitados mejoraron 22 puntos en el seguimiento interno del NPS del establecimiento. El segundo escenario es una cadena minorista regional con 60 tiendas en Inglaterra y Gales. Cada tienda cuenta con 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 recibido quejas sobre la latencia de la señalización digital: las pantallas sufrían retrasos de carga (buffering) durante los periodos de mayor actividad comercial. 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 segundo plano considerable, incluidas las comprobaciones de actualización de iOS que descargaban paquetes de varios gigabytes a través de la red de la tienda. Una combinación de bloqueo a nivel de DNS para los endpoints de análisis y un límite estricto de velocidad de 1 megabit por segundo para el tráfico identificado de actualizaciones del sistema operativo 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 parque de tiendas mediante una gestión de políticas centralizada. A continuación, detallamos los pasos de implementación que debe seguir para desplegar esto en su propio entorno. El primer paso es la medición de la línea base. Antes de modificar cualquier configuración, debe comprender su perfil de tráfico actual. Implemente una herramienta de análisis de tráfico (la plataforma Purple WiFi Analytics lo ofrece de forma nativa) y ejecútela durante un mínimo de cinco días hábiles para capturar los patrones de los días laborables y del fin de semana. Deberá analizar la proporción de tráfico dirigido a destinos conocidos de actualización en segundo plano, los periodos de máxima actividad en segundo plano y las tasas de consumo por dispositivo. El segundo paso consiste en crear su lista de bloqueo. Comience utilizando la lista de bloqueo de dominios OISD como base: cuenta con un buen mantenimiento, está validada por la comunidad y cubre los principales endpoints de análisis y redes publicitarias. Complemente esto con sus propias observaciones a partir del análisis de tráfico. Es fundamental que no bloquee de forma indiscriminada. Cierto tráfico de segundo plano —en particular el Apple Push Notification Service en el puerto 5223 y Google Firebase Cloud Messaging— es necesario para el funcionamiento del dispositivo. Bloquear estos servicios generará quejas de los usuarios. Pruebe su lista de bloqueo en un entorno de pruebas o en un único grupo de puntos de acceso antes de implementarla en toda la red. El tercer paso es el despliegue 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 segundo plano en lugar de bloquearlo todo de forma estricta; esto proporciona una transición más suave y reduce el riesgo de consecuencias imprevistas. El cuarto paso es la monitorización continua. Los endpoints de actualización en segundo plano cambian. Surgen nuevos SDK de analítica. Los desarrolladores de aplicaciones encuentran nuevas formas de comunicarse con el servidor. 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 de publicidad y analítica. Desde la perspectiva del cumplimiento, conviene señalar que la clasificación y el bloqueo de tráfico en la capa de red no constituyen una interceptación según la RIPA o legislación equivalente, siempre que no se inspeccione el contenido de las cargas útiles encriptadas. Está actuando sobre los 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 hace referencia a ella en su política de uso aceptable de la red y en el aviso de privacidad. A continuación, algunos errores comunes que se deben evitar. El primero es el bloqueo excesivo. Los equipos que despliegan listas de bloqueo agresivas sin realizar las pruebas adecuadas suelen descubrir que han interrumpido involuntariamente funciones de la aplicación de las que dependen los usuarios. Mantenga siempre una lista blanca para los servicios críticos y disponga de 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 actualización en segundo plano tiende a concentrarse en los 2,4 GHz porque los dispositivos más antiguos y los endpoints de IoT se conectan a esa banda por defecto. Si solo analiza el tráfico de 5 GHz, es posible que se esté perdiendo la mayor parte del problema. Asegúrese de que su análisis abarque todas las bandas. El tercer error es tratar esto como una solución única. Los patrones de tráfico de actualización en segundo plano evolucionan continuamente. Una lista de bloqueo que era completa hace seis meses puede estar omitiendo el 30 por ciento de los endpoints de analítica actuales. Incorpore una frecuencia de revisión en su calendario de gestión de red. Permítanme concluir con una serie de preguntas rápidas que escucho habitualmente de los arquitectos de red. "¿Afectará el bloqueo del tráfico de analítica al rendimiento de la aplicación para mis usuarios?" En la mayoría de los casos, no. Las balizas de analítica son de tipo "disparar y olvidar". La aplicación no espera una respuesta para seguir funcionando. El usuario no lo notará. "¿Funciona esto con DNS encriptado?" El tráfico estándar de DNS sobre HTTPS puede eludir el bloqueo tradicional basado en DNS. Debe interceptar el DoH en la pasarela 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 dispone de 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 restrictivo sobre qué tráfico de fondo está permitido. "¿Cómo justifico la inversión ante el consejo de administración?" El caso de ROI es sencillo. Recuperar entre un 30 y un 40 por ciento del tiempo de aire desperdiciado equivale a añadir 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 estuviera considerando una renovación de hardware para resolver las quejas de capacidad, la gestión del tráfico a nivel de red puede aplazar ese gasto de capital entre dos y tres años. Para resumir las acciones clave de esta sesión de información. En primer lugar, realice un análisis de referencia del tráfico: no se puede gestionar lo que no se puede medir. En segundo lugar, implemente una lista de bloqueo actualizada dirigida a endpoints conocidos de analítica y redes publicitarias. En tercer lugar, utilice la limitación de ancho de banda para el tráfico de actualización de sistemas operativos durante las horas de mayor actividad comercial o de eventos. En cuarto lugar, supervise de forma continua y actualice sus políticas trimestralmente. Y en quinto lugar, documente su enfoque para fines de cumplimiento. Si desea ver cómo la plataforma de Purple muestra estos datos y permite el despliegue de políticas en propiedades multisitio, el enlace se encuentra en las notas del programa. Gracias por su tiempo.