Latencia de red: qué es, cómo se mide y cómo reducirla en infraestructuras IT

Introducción

¿Hay algo peor que «no tener Internet? Sí, que la conexión vaya muy lenta y comience el calvario de recargar la página, enviar de nuevo la petición al servidor, ver la frustrante respuesta en blanco… Al menos, cuando no tienes conexión, puedes asumirlo y dedicarte a otra cosa que no sea doomscrolling. Pero cuando la red se arrastra por el barro, la principal sospechosa es la latencia y hoy la trataremos a fondo.

Veremos qué es, sus causas, cómo medirla y cómo monitorizar este indicador clave, además de recomendaciones para reducirla en lo posible.

Comencemos conociendo al enemigo.

¿Qué es la latencia de red y por qué es importante?

La latencia de red es el tiempo que tarda un paquete de datos en viajar desde su origen hasta su destino, y en recibir una confirmación de vuelta (lo que en telecomunicaciones se denomina Round-Trip Time (RTT) o Round-Trip Delay (RTD) cuando hablamos de señales en general). La latencia se mide en milisegundos (ms) y es fundamental porque:

• Determina la capacidad de respuesta de aplicaciones en tiempo real (VoIP, videoconferencias, trading, apps que usa la organización para trabajar…).
• Es una de las claves de la experiencia de usuario. Así, una latencia superior a 100 ms se percibe como lenta en las interacciones con los servicios en red, comenzando el desfile de tickets de soporte con un lenguaje cada vez más colorido.
• Impacta el rendimiento de sistemas distribuidos: Microservicios, bases de datos en cluster o entornos cloud acumulan retrasos en cada llamada de red. Hoy, muchas organizaciones han pasado de aplicaciones locales a otras en red propia o la nube, y una latencia reducida es clave para la productividad del usuario.
• Influye en el cumplimiento de SLA (Service Level Agreement): Superar umbrales acordados puede generar penalizaciones o pérdida de confianza en los clientes, que nos contrataron porque prometíamos velocidad, pero servimos caracoles.

Por eso, la latencia es una variable crítica para servicios digitales eficientes.

Tipos de latencia en IT: red, almacenamiento, aplicación y más

Profundicemos un poco más en los diferentes lados del prisma de la latencia, comenzando por examinar la que suele estar más asociada hoy con el término, como yo mismo he hecho al comienzo del artículo.

La latencia de red

Esta es la latencia más habitual que un administrador IT querrá comprobar para asegurar que el trabajo de los usuarios es productivo y acceden rápidamente a los recursos en red que necesitan, sean archivos o aplicaciones en red. Esta latencia la puedo comprobar, por ejemplo, con un comando ping desde mi terminal.

ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=22.0 ms

Si nos fijamos en la última parte, la variable time nos da un valor en ms que muestra esa latencia, lo que ha tardado el paquete ICMP en ir a destino y volver. En este caso, 22 ms.

La importancia del jitter

Ahora, este no es el único indicador interesante sobre problemas o análisis de latencia, porque también puedo comprobar el jitter. Este concepto mide la variación en la latencia. Si unos paquetes tardan 20 ms y otros emplean 80 ms en llegar, esa variación (±60 ms) es el jitter en términos generales, que puede causar voz entrecortada en llamadas o cortes en vídeo cuando es elevado. Por eso, no solo debemos tener en cuenta la latencia pura a la hora de analizar y optimizar la red, sino también la regularidad de esas velocidades.

El comando ping también es útil para averiguar este indicador clave, así, en la última línea de la salida de terminal de la prueba que he hecho antes aparece:

rtt min/avg/max/mdev = 14.878/19.205/21.955/3.097 ms

Eso nos muestra, por orden: la latencia mínima, la media, la máxima registrada en los paquetes del ping y ese mdev final (mean deviation o desviación media), que sería el jitter. En este caso, sigue siendo reducido lo que indica que la latencia está bien y además es estable, yéndose apenas 3 ms de media entre paquetes.

Que no se preocupe quien no gusta de contemplar la oscuridad de la terminal porque le recuerda a su futuro, porque veremos herramientas más sencillas y visuales para monitorizar latencias y jitter.

Obviamente, cuando hablamos de latencia de red, una de las maneras más directas de reducirla es mediante conexión cableada, que la mantendrá entre 1-10 ms si todo funciona bien. WiFi o 5G, en cambio, pueden superar a menudo 30 ms de latencia por interferencias.

La latencia de almacenamiento

Aquí nos referimos al tiempo de acceso a discos. Los más antiguos HDD solían registrar unos 5-10 ms en sus giros de bailarín, mientras que los SSD están entre 0.1-0.5 ms. Esta latencia afecta a bases de datos y sistemas de archivos, por ejemplo los de tu equipo local.

Latencia de aplicación

En este caso, hablamos de retrasos en procesamiento de software. Por ejemplo, APIs mal optimizadas o el garbage collection en Java pueden aumentar estos tiempos y que te empieces a desesperar con el manejo de la aplicación.

Latencia de servidor

Se refiere al tiempo de respuesta de un servidor, como por ejemplo uno web (en lo que se llama Time To First Byte – TTFB). Lo ideal son menos de 200 ms. Pero si resulta que esa nueva flamante empresa IA, que no es más que el enésimo wrapper de ChatGPT, usa una Raspberry Zero para alojar su página, dará igual lo rápida que sea tu conexión, porque el servidor añadirá esa latencia. Esto nos muestra que dicha latencia no es siempre un problema de ancho de banda de nuestro proveedor de Internet o la configuración de la red, sino que puede haber otros culpables.

Principales causas de la latencia

Cuando encontremos problemas de latencia en la red, deberemos resolverlos y comienza el juego del Cluedo para descubrir al culpable (o culpables, porque la vida en IT tiene la manía de ser compleja y no debemos descartar razones multifactoriales). Así, los principales motivos de la latencia suelen ser:

Si tu proveedor de Internet es un desastre, porque esos 600 Mb por 5 euros no eran tan buen negocio como parecía, probablemente esté trabajando con hardware obsoleto y/o tenga problemas de congestión.

Cómo medir la latencia: herramientas y métricas clave

Como no podemos gestionar lo que no medimos, lo primero es monitorizar esa latencia en nuestra red, lo que podemos hacer con:

Herramientas de terminal para medir latencia

Aquí tenemos el comando ping que ya hemos visto en los ejemplos anteriores. Si queremos diagnosticar más a fondo, podemos usar la herramienta traceroute, que ejecutaremos desde terminal Linux/Unix, o bien el comando tracert desde Powershell en Windows. Así, no solo obtendremos información de latencia en general, sino de latencia en cada salto que el paquete realiza hasta destino.

Sin embargo, es importante tener en cuenta que primero deberíamos usar ping para la latencia general y, si no nos agrada, o queremos saber dónde se entretienen más los paquetes, usar traceroute / tracert. El modo en el que actúa esta herramienta, especialmente si no le asignamos opciones concretas, puede dar latencias más elevadas que ping debido a que su misión es explorar los saltos e ir enviando varios paquetes, no solo uno.

traceroute -I -n 8.8.8.8

Hará que la herramienta se «entretenga» menos al enviar paquetes ICMP (con esa opción -I, de modo que envía los mismos paquetes que tracert) y no resolver direcciones IP (-n). En resumen, ping para conocer latencias y, si estas no son buenas, traceroute para investigar saltos problemáticos.

Cómo medir la latencia de servidor desde terminal

Si queremos presumir de ser unos magos de la terminal, y medir la latencia de un servidor con ese Time To First Byte (TTFB) del que hablaba antes, podemos hacerlo con la herramienta curl en Linux/Unix.

curl https://google.com -w "TTFB: %{time_starttransfer}"

Nos devuelve el código HTML de la página y, al final del mismo, aparece algo como esto, que es la salida que me acaba de dar desde mi máquina:

TTFB: 0.594890

Con lo que sabemos la latencia hasta que el servidor nos devuelve el primer byte.

Herramientas GUI para medir latencia

Si la terminal impone, no hay problema, tenemos una serie de herramientas visuales para nuestro análisis. Mi favorita no llamada Pandora es Pingnoo, de código abierto (como nos gusta aquí) y para Windows, Linux y MacOS. Con ella, podremos analizar latencias y examinar visualmente los resultados.

La cuestión es que, el valor de la latencia por sí solo es limitado, en el sentido de que es un indicador que monitorizar para que nuestra red y servicios vayan como la seda, pero no es lo único a tener en cuenta. Si estamos a cargo de una organización mínimamente compleja, el uso de una herramienta para cada análisis crea silos de información que no se comunican, ni dan una visión global de la infraestructura IT. La perspectiva global es imprescindible y, por eso, puedes medir la latencia y mucho más con Pandora FMS.

Monitorizar y diagnosticar latencia con Pandora FMS y Pandora MINI

Pandora FMS es el sistema de monitorización global de nuestro imperio tecnológico y, obviamente, puedes medir latencias, además de tener siempre los datos históricos y agregados en un solo panel de control, para que te sientas como el capitán Kirk al mando del Enterprise. Con Pandora FMS, todo lo que hemos visto lo puedes hacer sin necesidad de escribir conjuros arcanos en la terminal, permitiendo, por ejemplo:

• Monitorización remota: con pruebas ICMP básicas para ver si el host está en línea y su latencia, además de poder hacer otras pruebas, como TCP y SNMP.
• Monitorización web: que nos permite diversos test, como el Remote HTTP module to check latency para no tener que estar manipulando curl. Sabremos latencia, tiempos de carga, código de estado del servidor…
• Alertas personalizadas: para enterarnos al instante cuando algo no va bien y, por ejemplo, pone en peligro los SLA.

Al final, la latencia no es un capricho, es un instrumento de control y optimización, y tener una herramienta integrada como Pandora FMS permite una capacidad mucho más amplia y rápida de gestionar esa optimización y diagnosticar problemas. Además, permite tener históricos, dashboards personalizados y todo lo que siempre hemos querido para sentir que controlamos al menos un aspecto de nuestra vida.

Diagnosticando la latencia con Pandora MINI

Si lo que queremos es algo gratuito y sencillo, pero también con la capacidad de controlar visualmente latencias y estados de red y servidores, tenemos Pandora MINI, la herramienta 100% gratis para Windows que puedes descargar AQUÍ. No es tan poderosa como su hermana mayor, pero MINI comparte ADN y habilidades, de modo que podremos añadir a nuestra pantalla principal en MINI los servicios a controlar (como servidores internos o externos), de modo que veremos si están online y con qué latencia, de forma colorida y visual.

No es lo único, ya que también podremos analizar más a fondo problemas de latencia con:

• Su cálculo de jitter: que tienes en Monitorización > Jitter.
• Traceroute integrado para echar un vistazo más de cerca a posibles problemas, disponible en Tools > Traceroute.
• Y mucho más, como peticiones WHOIS o un dashboard integrado.

Así, podrás controlar infraestructuras sencillas o diagnosticar problemas sin necesidad de instalaciones complejas o configuraciones en los equipos.

Impacto en el rendimiento y experiencia de usuario

La latencia es, probablemente, la causa número uno de venas en la frente a punto de explotar. Cuando ella sube, la experiencia de usuario baja y se producen hechos como:

• VoIP/videollamadas: una latencia superior a 150 ms causa eco y desincronización.
• Streaming: el maldito buffer no deja de trabajar y tenemos problemas con un jitter de más de 50 ms.
• Juegos online: esos milisegundos de más son la causa de que ese crío de 11 años nos haya propinado 10 headshots en fila india y encima se ría por el chat (entrecortadamente).
• IoT industrial: latencias elevadas pueden llevar a fallos críticos.
• Nube/SaaS: el uso de aplicaciones online con latencia elevada provoca descensos en la productividad y tickets de usuario con mensajes que no son precisamente de amor.

Cómo reducir la latencia: estrategias prácticas

Ya conocemos prácticamente todo sobre el enemigo pero, ¿cómo lo derrotamos? La tabla de causas que puse anteriormente nos da unas cuantas pistas y aquí tienes las estrategias principales para reducir la latencia. Puedes usarlas como lista de chequeo para ver qué se adapta y puedes usar en tu infraestructura IT particular:

• Edge Computing: El término que suena a película y describe el procesamiento de datos cerca de donde se producen, en lugar de enviarlos todos a un servidor central que puede estar más lejos y sumar latencia. En procesos donde la velocidad es crítica (como retail o industria, por ejemplo), es una opción a valorar.
• CDNs (Content Delivery Network): Consiste en servir contenido estático desde nodos locales o cercanos, reduciendo así la distancia. También hay soluciones más novedosas para contenido dinámico.
• Caching: Las soluciones de caching a nivel de aplicación, base de datos o red pueden reducir significativamente la latencia en el caso de información que no cambia con frecuencia. Cuidado con servir contenido obsoleto, eso sí.
• Segmentación de red: Creando VLANs para tráfico crítico (voz, video).
• Mejora de hardware: Para que, en la medida en que el presupuesto permita, tengamos dispositivos de alto rendimiento.
• Protocolos adecuados: Usar protocolos HTTP/2 o QUIC puede arañar algo.
• Políticas QoS (Quality of Service): Priorizar tráfico crítico en routers.
• Conexiones directas: Usando BGP para determinar rutas óptimas entre sistemas autónomos en Internet.
• Soluciones de equilibrado de carga: Cada vez que leo balanceo imagino que muere un gatito, pero estoy solo en esa cruzada. Implementar soluciones de este tipo puede ayudar a distribuir el tráfico de manera uniforme a través de múltiples servidores, evitando cuellos de botella.
• Optimizaciones y compresión de datos: Siempre que sea posible sin deterioros en la experiencia de usuario, claro, como el producido por demasiada tarea de descompresión en equipos más antiguos.
• SLA de proveedores: Validar y obtener garantías de un nivel de servicio óptimo, con posibles medidas y compensaciones en caso de no cumplirse.
• Y, por supuesto, monitorización constante y global. En muchos casos, la latencia será una ocurrencia temporal, pero debemos atajarla cuanto antes.

Como vemos, la latencia da mucho de sí, pero es que resulta culpable de muchos de esos tickets de soporte tan informativos que se reducen a que «la red no va». Con una buena optimización y un sistema de monitorización y alertas, que nos permita atajar problemas y cuellos de botella, nuestros usuarios nos adorarán por la rapidez con las que les funcionan las cosas. Hasta que se caiga otro pedazo de la infraestructura, pero así es la vida en IT.