Latencia de red: qué es y adónde se van los milisegundos
De qué se compone la latencia, el mínimo que impone la distancia y mediciones reales desde nuestros servidores a Nueva Jersey, Singapur, Tokio y Sídney.
La latencia de red es el tiempo que tarda un paquete en llegar a su destino y volver, el tiempo de ida y vuelta (RTT), medido en milisegundos. La componen cuatro cosas: la distancia que recorre la señal, la ruta que eligen las redes, las colas en las que espera y las idas y vueltas que añaden los protocolos de las capas superiores. Solo la primera la fija la física. Esta guía las repasa una a una, con mediciones reales desde nuestros servidores de Falkenstein (Alemania) y Gravelines (Francia) del 7 de octubre de 2026.
De qué se compone una ida y vuelta
| Componente | Qué es | Orden de magnitud |
|---|---|---|
| Propagación | La luz en la fibra óptica viaja a unos 200.000 km/s, dos tercios de su velocidad en el vacío: 1 ms de ida y vuelta por cada 100 km de cable | Menos de 1 ms dentro de una ciudad, de 60 a 90 ms para cruzar el Atlántico, 160 ms o más hasta la otra punta del mundo |
| Serialización | Colocar los bits de un paquete en la línea: 1.500 bytes tardan 12 µs a 1 Gbit/s | Despreciable, salvo en enlaces lentos: 1,2 ms por paquete completo a 10 Mbit/s |
| Espera en cola | Esperar en el búfer de un router o de un módem cuando un enlace está ocupado | Cero en una ruta sin carga, cientos de milisegundos cuando se llena un búfer |
| Procesamiento | La decisión del router sobre adónde enviar el paquete | Microsegundos en el hardware actual |
Una creencia extendida es que «cada salto añade unos milisegundos». No es así: el reenvío tarda microsegundos. Cuando los tiempos de un traceroute crecen de un salto al siguiente, es por la distancia, por una cola o porque el router tarda en responder a la sonda mientras reenvía todo lo demás a toda velocidad.
La distancia fija un mínimo
La ida y vuelta más corta posible equivale a recorrer la distancia por el círculo máximo a la velocidad de la luz en la fibra. Los cables reales nunca siguen el círculo máximo, y las rutas reales rara vez toman el cable más corto. Así de lejos quedaron nuestras mediciones de ese mínimo (media de 60 a 100 sondas por destino, con mtr):
| Origen → destino | Distancia | Mínimo en fibra | Medido | Relación |
|---|---|---|---|---|
| Gravelines → Cloudflare 1.1.1.1 (París) | 237 km | 2,4 ms | 4,9 ms | 2,0× |
| Falkenstein → Cloudflare 1.1.1.1 (Fráncfort) | 265 km | 2,6 ms | 5,9 ms | 2,3× |
| Gravelines → Nueva Jersey | 5.779 km | 57,8 ms | 71,7 ms | 1,2× |
| Falkenstein → Nueva Jersey | 6.462 km | 64,6 ms | 86,4 ms | 1,3× |
| Falkenstein → Singapur | 9.994 km | 99,9 ms | 165,5 ms | 1,7× |
| Falkenstein → Tokio | 9.134 km | 91,3 ms | 273,6 ms | 3,0× |
| Falkenstein → Sídney | 16.220 km | 162,2 ms | 341,2 ms | 2,1× |
En distancias cortas dominan los retardos fijos (los equipos, los últimos metros de cableado, el tiempo que tarda el destino en responder), y la relación parece mala aunque las cifras absolutas son minúsculas. En las largas, lo que cuenta es la ruta. Tokio triplica su mínimo porque los paquetes no van directos: la traza sale de Europa por la red de Arelion, llega a Singapur a los 169 ms y después a Tokio a los 246 ms. En nuestro estudio de la latencia cloud desde 33 ciudades, el trayecto de Johannesburgo a São Paulo tardó 351 ms en el mejor de los casos, para un mínimo de 74 ms: los paquetes pasaron por Europa.
Mismo destino, dos rutas
El mismo host de Vultr en Nueva Jersey, medido en el mismo minuto desde nuestros dos servidores:
Desde Falkenstein (Hetzner, AS24940)
5. AS201011 ae12-499.nbg40.core-backbone.com 0.0% 100 3.2 3.0 2.7 3.3 0.1
6. AS201011 ae7-2093.nyk10.core-backbone.com 0.0% 100 86.6 86.7 86.5 87.0 0.1
11. AS20473 108.61.149.182.vultrusercontent.com 0.0% 100 86.2 86.4 85.9 107.1 2.1
Desde Gravelines (OVHcloud, AS16276)
10. AS16276 be102.lon-drch-sbb1-nc5.uk.eu 1.0% 100 3.8 3.7 3.5 4.1 0.1
11. AS16276 nyc-ny1-sbb2-8k.nj.us 0.0% 100 73.0 73.4 71.6 76.0 0.8
13. AS??? nyiix.gi3-6.cr1.nyc1.choopa.net 0.0% 100 72.7 72.5 72.3 73.0 0.1
17. AS20473 108.61.149.182.vultrusercontent.com 0.0% 100 71.7 71.7 71.5 73.0 0.2De los 14,7 ms de diferencia, solo la mitad se debe a la distancia (los mínimos difieren en 6,8 ms). El resto es la ruta: desde Gravelines, OVH lleva el tráfico por su propia red, vía Londres, hasta Nueva York y se lo entrega a Vultr en NYIIX, un punto de intercambio de Nueva York; desde Falkenstein, Hetzner se lo entrega a Core-Backbone en Núremberg, que cruza el Atlántico. Elegir un hosting, o un proveedor, es también elegir sus rutas.
Colas: la latencia que va y viene
La propagación no cambia. Las colas, sí. En las rutas sin carga de más arriba, la dispersión en los destinos se mantuvo entre 0,1 y 2,1 ms a lo largo de 100 sondas. En una conexión doméstica, una sola subida de archivos grande puede llenar el búfer del módem y añadir cientos de milisegundos a todo lo demás: eso es el bufferbloat.
Para comprobarlo, ejecuta ping 1.1.1.1 y, mientras corre, lanza una subida grande y después una descarga grande. Si los tiempos pasan de 15 ms a 200 ms o más y vuelven a bajar cuando termina la transferencia, el problema es el búfer. La solución está en el router: gestión inteligente de colas (fq_codel o CAKE, disponibles en OpenWrt y en muchos routers recientes), o limitar el caudal del enlace un poco por debajo de su velocidad nominal.
Los protocolos multiplican las idas y vueltas
Una conexión HTTPS nueva paga varias idas y vueltas antes de que llegue el primer byte de la página: una consulta DNS si el nombre no está en caché, una para el handshake de TCP, una para TLS 1.3 (dos para TLS 1.2) y una para la propia petición. Contando cuatro:
| Ida y vuelta | 4 idas y vueltas |
|---|---|
| 6 ms (un servidor cercano) | 24 ms |
| 86 ms (de Alemania a Nueva Jersey) | 344 ms |
| 341 ms (de Alemania a Sídney) | 1,4 s |
La misma aritmética vale para todo lo secuencial: una aplicación que hace 20 consultas seguidas a una base de datos situada a 80 ms espera 1,6 segundos. HTTP/2 y HTTP/3 reutilizan las conexiones, TLS 1.3 y QUIC recortan los handshakes, y hacer menos peticiones secuenciales recorta el resto.
Cuánto es demasiado
| Uso | Cómodo | Se nota |
|---|---|---|
| Llamadas de voz y vídeo | Menos de 150 ms en un sentido, según la recomendación UIT-T G.114 | Por encima, los interlocutores empiezan a hablar a la vez |
| Juegos online rápidos | Menos de unos 50 ms de ida y vuelta | Por encima de 100 ms, la mayoría de los jugadores lo nota |
| Páginas web y API | Depende del número de idas y vueltas secuenciales | Cada ida y vuelta adicional se suma al tiempo hasta el primer byte |
Mídela tú mismo
ping -c 20 host: el mínimo marca el suelo de esa ruta, la media tu latencia habitual ymdevel jitter.mtr -rwz -c 100 host: en qué punto de la ruta se añade el tiempo (consulta cómo leer un informe de mtr).- Desde varios lugares: nuestro test de latencia cloud mide la latencia de tu navegador hacia 36 regiones de AWS, OVHcloud, Vultr y Akamai, y TraceMapper traza la misma ruta desde más de 30 ubicaciones.
Lo que puedes cambiar y lo que no
- Distancia: solo acercando el servidor a los usuarios, o añadiendo una región o una CDN. En nuestro estudio de 33 ciudades, Fráncfort por sí solo servía a 14 ciudades en menos de 100 ms; Fráncfort y Singapur juntos, a 27.
- Ruta: eligiendo un proveedor cuya red y cuyo peering se adapten a tus usuarios. No puedes cambiar la política de enrutamiento de otra red.
- Colas: gestión inteligente de colas en casa, y no llevar los enlaces al 100 % en un centro de datos.
- Idas y vueltas: reutilización de conexiones, TLS 1.3, caché DNS, menos llamadas secuenciales.
Para la parte práctica, consulta cómo reducir la latencia de red.