Los resultados de las pruebas de los test de velocidad con IPS no son reales.
La mayoría de nosotros estamos familiarizados con estos populares servicios de prueba de velocidad de Internet que hay. Lo que hacen estos sitios es permitirte probar tu ancho de banda de subida y bajada, dándote una idea de la calidad de tu conexión a Internet. Pero ¿Son realmente precisos si estamos en una red corporativa?
Lamentablemente, a menudo estos datos no son del todo exactos. Hay que tener en cuenta muchos factores, como por ejemplo si se está generando tráfico adicional en el instante de realizar las pruebas, el estado del equipo desde donde se está lanzando, la latencia y fluctuación del retardo de la red, y quizás lo más importante el cortafuego o dispositivo de gestion unificada de amenazas (Firewall/UTM) y las capas de seguridad que tenemos activadas en este momento. A menudo, el mayor inconveniente que tenemos para obtener resultados reales es debido a un detalle que se pasa por alto.
Estamos de acuerdo de que cualquier función de escaneo o filtrado en un Firewall/UTM afectará sin duda el rendimiento de la red. De todas las características de seguridad disponibles en un Firewall/UTM, se sabe que el Sistema de Prevención de Intruso (IPS) tiene el mayor impacto en el rendimiento de una red (throughput).
Cuando se ejecuta una prueba de velocidad tipo OOKLA Speedtest o Fast.com de Netflix (por cierto, mi favorito y de los más fiables ya que es HTML5 puro) el impacto en el rendimiento puede ser mucho mayor de lo esperado en las condiciones descritas a continuación.
- Si tenemos IPS activado
- Usamos una red de alta velocidad, como una conexión a internet por Fibra, Gigabit o Gigabit LAN
- Una o varias conexiones comparten la misma IP de origen y IP de destino (este punto es muy relevante en cuanto al rendimiento de IPS)
Esto se basa en cómo el proceso IPS maneja el tráfico y las limitaciones de la prueba en lugar de reflejar efectivamente el rendimiento o el throughput.
El motor de IPS
El motor de escaneo IPS puede iniciar múltiples procesos en múltiples núcleos de CPU; sin embargo, solo se usa un proceso por cada par de origen y destino de IP. A medida que aumenta la velocidad de la conexión, la demanda de los recursos del sistema también aumenta para procesar el flujo incrementado de paquetes.
Al usar una conexión de alta velocidad, llegará un punto en el que el ancho de banda de red disponible es mayor que la velocidad con la que el proceso IPS puede escanear el tráfico, lo que hace que el núcleo de la CPU ejecute el proceso para alcanzar el 100%. No existen cifras exactas para este impacto porque depende de la marca y el modelo del Firewall/UTM y de qué más está haciendo el sistema en ese momento. Está claro que cuando mayor sea en rendimiento del equipo (procesadores potentes, memorias desahogadas, chipsets y buses mega rápidos) mejor se nos pintará el resultado final.
Siempre que las conexiones nuevas se originen desde una fuente diferente o se dirijan a un destino diferente, estas pasarán por un nuevo proceso de IPS en un núcleo de CPU separado. Esto permitiría, por lo tanto, que una conexión simultánea solo tenga su velocidad limitada cuando su núcleo de CPU alcance el 100% o cuando el ancho de banda de red disponible se haya saturado.
En términos reales, esto significa que el impacto real en el rendimiento de la red no será tan dramático como lo muestran los resultados de la prueba de velocidad, y los usuarios finales no notarán ningún impacto en el rendimiento de la red a menos que transfieran archivos súper grandes.
