La fracción de finalización por host se calcula ( scan_engine.cc UltraScanInfo::getCompletionFraction() ) como :
ports_finished * ( maxtries - 1 ) + probes_sent
_______________________________________________
maxtries * numprobes
El porcentaje de finalización total se calcula a partir de esto en todos los hosts.
En un escaneo TCP ( -sT ) el número de sondas numprobes se fija al número de puertos (
scan_engine.cc UltraScanInfo::numProbesPerHost() ) y nunca cambia después de la inicialización, por lo que maxtries es el término interesante del cálculo. ports_finished y probes_sent son contadores incrementales, lo anterior funciona en 1.0 cuando ports_finished == probes_sent == numprobes . numprobes será 1000, el número predeterminado de sondas TCP en el ejemplo que dio.
Si maxtries aumenta (debido al tiempo de espera y al reintento), la cantidad estimada de trabajo que queda por hacer aumenta y, por lo tanto, la fracción del trabajo completado disminuye. ( --max-retries puede controlar esto, aunque con un -sT para la conexión TCP por la pila IP del sistema operativo connect() algunos de los otros parámetros de tiempo de espera / reintento que admite NMAP son ineficaces).
El recuento de maxtries no es ingenuo, es la marca de agua más alta de los reintentos (+1) para un puerto de sondeo exitosamente en la exploración hasta el momento. Si agrega -d (depuración), verá el mensaje "Incrementando max_successful_tryno para 1.2.3.4 a 1 (caída de paquete)". Este no es el mismo mensaje que "Incrementando el retraso de envío ...". Es probable que vea ambos mensajes cuando haya una pérdida de paquetes durante una exploración.
Lo que ha visto es una prueba TCP exitosa para un host, pero requirió un reintento, se produjo al final del análisis y logró aumentar el límite superior de la estimación de trabajo. Probablemente revisó la finalización más de un 1%, y la pérdida de paquetes probablemente cause que los tiempos de espera aumenten, disminuyendo la velocidad de escaneo. Aproximadamente 4 minutos transcurrieron entre las dos líneas de estado, por lo que la caída en la finalización no fue simplemente del 0,01%.
La sincronización de la exploración del servicio es un cálculo separado.