Herramienta de Prueba Ping

Una prueba de ping comprueba si un host de destino es alcanzable por la red y estima la latencia de respuesta. El ping tradicional envía solicitudes ICMP echo y mide el tiempo de ida y vuelta; en navegadores o entornos web pueden usarse otros métodos porque no hay acceso ICMP directo. Ping sirve para diagnóstico de red, monitoreo de servidores, comparación de latencia, sospechas de DNS y separación entre problemas locales y del host remoto. Un ping exitoso no demuestra que un sitio, puerto, base de datos o login funcione, y un ping fallido no siempre significa que el servidor esté caído, porque firewalls y políticas pueden bloquear ICMP. Conviene interpretarlo junto con DNS, traceroute, puertos y checks de aplicación.

La herramienta de ping envía una sonda desde el servidor backend de ToolAct al host destino, midiendo alcanzabilidad y latencia de ida y vuelta. El ping tradicional opera en la capa 3 del modelo OSI usando ICMP (Internet Control Message Protocol, RFC 792): el origen envía un ICMP Echo Request (Tipo 8, Código 0) que contiene un número de secuencia y una carga útil, y el destino responde con un ICMP Echo Reply (Tipo 0, Código 0). El tiempo de ida y vuelta (RTT) es el intervalo entre el envío de la solicitud y la recepción de la respuesta, medido en milisegundos. Dado que los navegadores no pueden enviar paquetes ICMP crudos (la API Socket no expone sockets sin procesar al contenido web), esta herramienta hace proxy del ping a través de una API backend: el proceso del lado del servidor ejecuta el intercambio ICMP real y devuelve los resultados al navegador. El campo TTL (Time to Live) en la cabecera IP se decrementa en 1 en cada salto de router; cuando el TTL alcanza 0, el router descarta el paquete y devuelve un mensaje ICMP Time Exceeded (Tipo 11). Este es el mecanismo detrás de traceroute, pero en una prueba de ping, el valor inicial de TTL revela el SO del destino: Windows usa por defecto 128, Linux/macOS 64, y los dispositivos de red suelen usar 255. Restar el TTL recibido del valor por defecto da un conteo aproximado de saltos al destino. La pérdida de paquetes se calcula como (paquetes enviados - paquetes recibidos) / paquetes enviados x 100%. Cero pérdida significa que todas las sondas retornaron dentro del tiempo de espera; la pérdida intermitente puede indicar congestión, hardware defectuoso, limitación de tasa o deprecación de ICMP por parte del firewall intermedio o del destino. Muchos servidores de producción y proveedores en la nube deshabilitan ICMP por completo en el borde, por lo que un resultado de 100% de pérdida no significa necesariamente que el host esté caído: puede significar que ICMP está filtrado. La herramienta reporta latencia mínima, máxima y promedio a través de todas las sondas exitosas, que juntas revelan jitter: un promedio bajo con un máximo alto sugiere picos ocasionales, mientras que un min/max consistente indica un enlace estable.

• Mecanismo de ICMP Echo (RFC 792): el Echo Request (Tipo 8) lleva un identificador de 16 bits, un número de secuencia de 16 bits y una carga útil opcional; el Echo Reply (Tipo 0) hace eco del mismo identificador y secuencia, permitiendo al emisor emparejar respuestas con solicitudes.
• Medición de RTT: el tiempo de ida y vuelta es el intervalo de reloj desde la transmisión de la solicitud hasta la recepción de la respuesta, incluyendo retardo de propagación de red, encolamiento en routers y tiempo de procesamiento del destino; valores inferiores a 1 ms sugieren que el destino está en la misma LAN, mientras que 100+ ms sugiere rutas intercontinentales.
• Inferencia de saltos por TTL: los valores iniciales de TTL siguen convenciones del SO (Windows 128, Linux/macOS 64, dispositivos de red 255); el conteo aproximado de saltos = TTL inicial - TTL recibido; un TTL recibido de 117 desde un host Windows sugiere aproximadamente 11 saltos de router.
• Interpretación de pérdida de paquetes: <2% de pérdida en una ruta bien conectada es normal; 2-10% sugiere congestión o un enlace defectuoso; >10% indica un problema serio, pero el filtrado de ICMP por firewalls o proveedores en la nube puede producir falsos 100% de pérdida en un host que está saludable.
• Estadísticas de latencia: mínima, máxima y media aritmética a través de N sondas revelan jitter; una media baja con un máximo alto indica congestión esporádica; la desviación estándar (no mostrada pero calculable desde la tabla por paquete) cuantifica la dispersión.
• Limitación del navegador: JavaScript no puede enviar paquetes ICMP crudos porque las APIs WebSocket, fetch y XMLHttpRequest operan en la capa de aplicación (TCP/TLS/HTTP); la herramienta hace proxy de pings a través de una API backend, por lo que la latencia medida incluye un viaje de ida y vuelta HTTP adicional al servidor de ToolAct.
• Limitación de tasa de ICMP: muchos hosts y routers aplican limitación de tasa de ICMP (parámetro del kernel de Linux net.ipv4.icmp_ratelimit, por defecto 1000 ms); enviar sondas más rápido que el límite de tasa causa pérdida artificial de paquetes que no refleja las condiciones reales de la red.