Latencia y ping: por qué importa la ubicación del servidor

Haces clic en un botón y no pasa nada durante medio segundo. La conexión no es lenta en el sentido de "pocos megas": la petición simplemente tarda en llegar al servidor y volver. Ese tiempo es la latencia, y es la razón de que un bot responda con retraso o de que una página cargue lenta incluso con fibra de 500 Mbps.

La latencia no es el ancho de banda. El ancho de banda dice cuánto cabe por la tubería cada segundo; la latencia dice cuánto tarda una gota en cruzarla. Los sitios, las APIs y los bots intercambian muchos mensajes pequeños, así que la latencia suele pesar más que el ancho de banda.

¿Qué es la latencia y qué es el ping?#

Según MDN, la latencia es el tiempo que tarda un paquete de datos en ir del origen al destino. En la práctica casi siempre se mide de ida y vuelta (RTT, round-trip time): el tiempo entre que sale la petición y llega la respuesta.

El ping es la herramienta más común para medirla. Envía un mensaje ICMP de "echo request" y espera el "echo reply". El número que muestra, en milisegundos (ms), es el RTT hasta esa dirección.

ping -c 4 example.com

El ping solo mide la red hasta el servidor. No incluye TLS ni el tiempo que tu aplicación tarda en armar la respuesta. Algunos servidores también bloquean ICMP, así que un ping sin respuesta no prueba que el servidor esté caído. En Windows, la opción es -n 4 en lugar de -c 4.

¿Por qué la distancia impone un mínimo de latencia?#

Ninguna señal viaja más rápido que la luz. En la fibra, la luz va más lenta que en el vacío: con un índice de refracción cercano a 1,5, el retraso es de unos 5 µs por kilómetro, según Wikipedia (en el vacío serían 3,33 µs por km).

Eso permite una cuenta simple del mínimo. Ciudad de México está a unos 3.360 km de Nueva York en línea recta:

• 3.360 km x 5 µs = unos 17 ms solo de ida
• Ida y vuelta: unos 34 ms, en el mejor caso teórico

Los cables reales no siguen una línea recta y pasan por routers, así que el valor medido es mayor. Ninguna optimización de código baja de ese mínimo. Por eso la ubicación del servidor respecto a tus usuarios es la primera decisión, y la más difícil de deshacer después.

¿Qué compone la latencia de una petición web?#

Una sola petición HTTPS a un sitio que todavía no visitaste pasa por varias etapas, cada una con al menos una ida y vuelta:

1. DNS: averiguar la IP del dominio (mira qué es el DNS).
2. Conexión TCP: el handshake que abre el canal.
3. TLS: la negociación de la conexión segura.
4. Petición y espera: el servidor recibe, procesa y empieza a responder.
5. Descarga: llega la respuesta, y el tiempo depende del ancho de banda y del tamaño del archivo.

MDN señala que en la primera petición la latencia es mayor justamente porque suma DNS, TCP y TLS, y que las siguientes son más rápidas porque la conexión ya está abierta. Por eso reutilizar conexiones (keep-alive, HTTP/2, HTTP/3) ayuda tanto.

La suma de todo esto hasta el primer byte es el TTFB. web.dev considera bueno un TTFB de hasta 0,8 s y malo por encima de 1,8 s, como guía aproximada, y recuerda que incluye redirecciones, DNS, conexión, TLS y la espera de la respuesta.

¿Cómo medir cada etapa con curl?#

curl puede separar los tiempos con -w. Este comando funciona en Linux, macOS y en Git Bash de Windows:

curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconexion: %{time_connect}s\ntls: %{time_appconnect}s\nprimer byte: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.com

Los valores son acumulados desde el inicio. Para obtener el tiempo de cada etapa, resta el valor anterior:

• time_connect - time_namelookup es el handshake TCP, más o menos una ida y vuelta hasta el servidor.
• time_appconnect - time_connect es el TLS.
• time_starttransfer - time_appconnect es la petición más el procesamiento del servidor.

Si la conexión TCP ya tarda decenas de ms, el cuello de botella es la distancia. Si el TCP es rápido y el intervalo hasta el primer byte es grande, el cuello de botella está en el código o en la base de datos del servidor, y mover el servidor no lo arregla.

¿Cómo reducir la latencia?#

En orden de impacto, para la mayoría de los proyectos:

• Acerca el servidor a tus usuarios. Es la única forma de bajar el mínimo físico.
• Acerca los componentes entre sí. Una app que hace 10 consultas a la base de datos paga 10 idas y vueltas. Con la base y la aplicación en la misma región casi no importa; lejos, multiplica el retraso.
• Usa una CDN para lo que se puede cachear. Imágenes, CSS y JS salen de un punto cercano al visitante. Mira qué es una CDN.
• Reduce el número de idas y vueltas. Menos redirecciones, menos dominios distintos, conexiones reutilizadas, consultas agrupadas.
• Reparte la carga. Varios servidores detrás de un balanceador de carga eliminan la cola de espera, aunque no acortan la distancia.
• Mide desde donde están tus usuarios. El ping desde tu computadora solo vale para tu computadora.

¿Cuándo importa más la latencia?#

Las aplicaciones que intercambian mensajes todo el tiempo son las que más sufren: juegos, llamadas de voz, bots de Discord con comandos interactivos, paneles en tiempo real. Un sitio estático con caché sufre menos. Un backend que hace varias llamadas secuenciales a otros servicios siente cada ida y vuelta sumada.

También conviene separar la latencia del jitter, que es la variación del retraso de un paquete a otro. Una latencia media baja con jitter alto sigue produciendo cortes en voz y video.

Cómo hacerlo en Square Cloud#

En Square Cloud, las aplicaciones corren en contenedores aislados en un datacenter Tier 3 asociado en Nueva York (Telehouse). Delante de ellas hay una CDN Anycast con más de 200 puntos de presencia, HTTP/3 y WebSockets.

Dos números ayudan a planificar. Un bot de Discord alojado en Square Cloud tiene una latencia media de unos 30 ms hasta el Gateway de Discord. El hosting de bases de datos, disponible desde el plan Standard, provisiona la base en el mismo datacenter que tus aplicaciones, con alrededor de 1 ms de latencia media, lo que abarata las consultas en secuencia. Son medias observadas, no garantías.

Si un solo servidor no alcanza, el balanceo de carga te permite servir el mismo dominio personalizado desde varias aplicaciones, con round-robin y failover pasivo. No hay autoescalado: tú decides cuántas aplicaciones entran y cuánta RAM tiene cada una. Para usuarios lejos de Nueva York, el mínimo físico calculado arriba sigue valiendo, y la CDN ayuda con el contenido cacheable, respetando el Cache-Control de tu aplicación.

Los detalles de la red están en Red y CDN de Square Cloud.