El pipevalor en la salida de pingindica el número máximo de paquetes de solicitud de eco ICMP sin respuesta pendientes en la red en algún momento durante la prueba. Normalmente no se informa cuando este valor es uno (cada solicitud recibió una respuesta antes de que se enviara la siguiente solicitud), que es el caso bajo operación normal.
Por defecto, el pingcomando espera un segundo entre el envío de solicitudes de eco, según la descripción en su página de manual bajo el -iparámetro:
El valor predeterminado es esperar un segundo entre cada paquete normalmente, o no esperar en modo inundación. Solo el superusuario puede establecer el intervalo en valores menores a 0.2 segundos.
En la mayoría de las redes, el tiempo de ida y vuelta (RTT) suele ser del orden de decenas o cientos de milisegundos, no segundos, por lo que en este modo predeterminado, cada solicitud de eco normalmente recibirá una respuesta antes de que se envíe la siguiente solicitud. El número máximo de paquetes pendientes en la red no es mayor que uno en cualquier punto de la prueba, por lo que pipees igual a 1 y no se informa.
Si el tiempo de respuesta a un paquete se eleva por encima de este intervalo predeterminado por alguna razón, causando que varias solicitudes estén pendientes en la red, el ping informará un pipemayor que uno. De manera similar, puede invocar esta respuesta reduciendo artificialmente el intervalo pasando un valor menor que el RTT para el -iparámetro de ping.
Si el sistema de red es local, entonces:
- sus pruebas están reduciendo el intervalo para emitir pings
- Ha habilitado el modo de inundación , que no espera una respuesta antes de enviar otro ping
- las respuestas tardan un tiempo en volver a su sistema de prueba desde el host remoto
Si esto es indicativo de un problema mayor depende del escenario, el hardware de la red, la pingconfiguración, etc.
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3014msypipe 3en diferentes líneas que confundieron mi código Java que intenta analizarlo