HTTP Ping — Test de Latencia y Jitter desde el Edge de Cloudflare
El ping HTTP mide el tiempo de respuesta de ida y vuelta enviando una serie de peticiones HTTP(S) desde la red edge global de Cloudflare al host destino y registrando el tiempo transcurrido en cada una. No es un eco ICMP (ping según RFC 792, Postel 1981) — opera a nivel de aplicación (HTTP/1.1 según RFC 9112, HTTP/2 según RFC 9113) en lugar del nivel de red, e incluye el tiempo de handshake TLS (RFC 8446 TLS 1.3, Rescorla 2018) más el tiempo de procesado del propio servidor en cada muestra. La medición se ejecuta desde la red anycast de Cloudflare (RFC 4786 BCP 126, Abley y Lindqvist 2006), lo que significa que la sonda se origina cerca del destino desde el punto de vista de la infraestructura, no desde tu dispositivo ni tu ISP. La latencia mínima refleja el mejor caso de la ruta edge-servidor en condiciones favorables. La media y el máximo muestran el rango típico y el peor caso. El jitter — la varianza entre muestras consecutivas — indica estabilidad: jitter bajo significa rendimiento consistente; jitter alto sugiere fluctuaciones en cola, variabilidad de enrutamiento del origen CDN o inconsistencia en el procesado del servidor. Una calificación de rápido corresponde a tiempos medios de respuesta inferiores a 300 ms; moderado a menos de 1 s; lento por encima. La alcanzabilidad informa la fracción de muestras que recibieron una respuesta HTTP válida — 100 % significa que todas las sondas tuvieron éxito; valores menores indican timeouts o fallos de conexión intermitentes.
Cómo usar la herramienta de ping HTTP
- Introduce un hostname o URL completa (p.ej. github.com o https://api.ejemplo.com/health).
- Pulsa Ping — la herramienta envía 5 peticiones HTTP(S) desde el edge de Cloudflare y registra el tiempo de respuesta de cada una.
- Lee mín/media/máx/jitter: el mínimo es la latencia de mejor caso; la media, la típica; el máximo, el peor; el jitter, la varianza entre muestras.
- Comprueba la alcanzabilidad — si está por debajo del 100 %, algunas sondas agotaron el tiempo o fallaron, lo que indica problemas de conectividad intermitente en la ruta edge-origen.
Casos de uso comunes
- Comparar tiempos de respuesta HTTP de dos endpoints de API u orígenes CDN para elegir el más rápido.
- Detectar jitter alto que provoca tiempos de respuesta inconsistentes incluso cuando la media parece correcta.
- Verificar que un servidor recién desplegado es alcanzable desde el edge de Cloudflare antes de conectarlo a producción.
- Comprobar si una dependencia de terceros (pasarela de pago, proveedor de auth) responde dentro del presupuesto de latencia.
Preguntas frecuentes
¿Es esto un ping ICMP real?
No. El ping ICMP (RFC 792) opera a nivel IP y mide el RTT de red puro sin overhead de TLS ni de aplicación. Esta herramienta envía peticiones HTTP(S) desde el edge global de Cloudflare y mide el tiempo de respuesta a nivel de aplicación — incluye la apertura de conexión TCP, el handshake TLS (RFC 8446 TLS 1.3) y el tiempo de procesado del propio servidor. Para un ping ICMP real desde tu dispositivo, usa el comando de tu sistema operativo: ping github.com en una terminal.
¿Por qué la primera muestra suele ser más lenta?
La primera muestra establece una conexión TCP nueva y completa un handshake TLS completo (RFC 8446), lo que añade uno o dos RTT de overhead. Las muestras siguientes pueden reutilizar la conexión existente según la configuración keep-alive del servidor, reduciendo ese overhead. El mínimo entre todas las muestras es normalmente la mejor aproximación a la latencia en estado estacionario.
¿Mide la latencia desde mi dispositivo?
No. La sonda se ejecuta desde la red edge anycast de Cloudflare (RFC 4786 BCP 126), no desde tu navegador ni tu ISP. Los números reflejan la latencia entre la infraestructura de Cloudflare y el destino — útil para entender el rendimiento a nivel de infraestructura, pero no incluye el tiempo de tu propia conexión de último kilómetro.
¿Qué indica jitter alto?
El jitter es la varianza entre muestras consecutivas. Jitter bajo significa que el servidor responde de forma consistente. Jitter alto sugiere fluctuaciones en cola, variabilidad de enrutamiento del origen detrás de un CDN, pausas de garbage collection o recursos del servidor sobrecargados. Incluso una buena media de respuesta puede enmascarar jitter alto, que es lo que hace que las APIs se perciban como poco fiables.
Ping HTTP vs ping ICMP — qué significan los números de latencia
El ping ICMP (RFC 792, Postel 1981) envía datagramas de echo request/reply a nivel IP y mide el tiempo de ida y vuelta de red puro sin involucrar ninguna aplicación, TCP ni TLS. El comando ping del sistema operativo es la herramienta canónica para esto. El ping HTTP opera a nivel de aplicación: abre una conexión TCP, realiza un handshake TLS (en HTTPS), envía una petición HTTP GET o HEAD según RFC 9110 (Fielding, Nottingham y Reschke 2022), y registra el tiempo hasta el primer byte de respuesta o cierre de conexión. Esto significa que la latencia HTTP incluye el RTT del SYN-ACK TCP (típicamente cercano al RTT ICMP), el handshake TLS (uno o dos RTT adicionales bajo TLS 1.2; uno bajo TLS 1.3 con 0-RTT, Rescorla 2018 RFC 8446) y el procesado del servidor (consultas a base de datos, lógica de aplicación, generación de contenido). Para la primera muestra, no es posible la reanudación de sesión TLS, por lo que el coste del handshake siempre está presente; muestras posteriores pueden beneficiarse de la reutilización keep-alive según la configuración del servidor. En la práctica, el mínimo a lo largo de cinco muestras aproxima la latencia de red edge-servidor más un handshake TLS 1.3. El jitter importa para la fiabilidad de APIs y cargas de trabajo en tiempo real: un servidor que responde en 80 ms la mitad del tiempo y en 800 ms la otra mitad tiene jitter alto aunque la media parezca aceptable. Compara varios destinos para diagnosticar si la latencia alta es del lado del origen (mismo host, múltiples rutas) o del camino de red (distintos hosts, mismo patrón). Dado que la sonda se origina desde la red de Cloudflare — no desde tu dispositivo — los números reflejan la latencia a nivel de infraestructura entre el edge de Cloudflare y el destino.
- 5 muestras HTTP(S) — mín, media, máx y jitter
- Porcentaje de alcanzabilidad sobre todas las muestras
- Calificación de latencia: Rápido (<300 ms media) / Moderado (<1 s) / Lento
- Distinción honesta ICMP vs HTTP — incluye TLS y procesado del servidor
- Sonda desde el edge anycast de Cloudflare (RFC 4786 BCP 126)
Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.
Fuentes (3)
- Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (June 2022 — STD 97; §15 status code classes; the tool measures HTTP(S) round-trip time from Cloudflare's edge to the target, including TLS handshake and server processing time — this is NOT an ICMP ping and does NOT measure latency from the user's device).
- Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF (August 2018 — TLS 1.3 handshake latency is included in the measured response time; 1-RTT full handshake + optional 0-RTT on resumption).
- Postel, J. (1981). Internet Control Message Protocol (ICMP). RFC 792, IETF (September 1981 — defines ICMP Echo Request/Reply; this tool does NOT use ICMP: it issues an HTTP(S) request, which traverses TCP+TLS+application layers rather than raw network-layer RTT).
Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.
Por Marco B. ·