Nmap ha l'abilita` di effettuare port scan o version scan su piu` host in parallelo. Lo spazio degli indirizzi IP di destinazione viene diviso in gruppi e viene scansionato un gruppo per volta. In genere gruppi di dimensioni maggiori porta ad una migliore efficienza. Il lato negativo di tutto cio` e` i risultati non possono essere mostrati all'utente fino a quando l'intero gruppo non e` stato esplorato completamente. Quindi, se si lancia Nmap impostando la dimensione del gruppo a 50, l'utente non vedra` alcun risultato fino a quando i primi 50 host non sono stati completati (a meno che non selezioni la modalita` verbose).

Di default, Nmap usa un compromesso per ovviare a questa difficolta`. Inizialmente utilizza una dimensione di cinque host in modo da mostrare i primi risultati velocemente, dopodiche` incrementa la dimensione fino ad un massimo di 1024. Il numero esatto dipende dalle opzioni che vengono passate. Per ragioni di efficienza Nmap usa gruppi di dimensione maggiore per UDP o per scansioni di porte TCP di piccole dimensioni.

nel caso in cui una dimensione massima del gruppo sia specificata con --max_hostgroup, Nmap non oltrepassera` mai questo limite. Specificando invece una dimensione minima con --min_hostgroup obblighera` Nmap a usare dimensioni almeno equivalenti. Nmap potrebbe tuttavia dover usare gruppi piu` piccoli di quelli indicati se non ci dovessero essere abbastanza host di destinazione rimanenti per un'interfaccia per raggiungere la minima quota specificata. Entrambe le opzioni possono essere impostate per mantenere la dimensione del gruppo all'interno di un certo limite, anche se questo succede raramente.

L'utilizzo principale di queste opzioni e` quello di specificare una dimensione minima di una certa dimensione in modo da rendere piu` veloce la scansione globale. Una scelta piuttosto comune e` 256 per una scansione di una rete di classe C. Per una scansione con piu` porte, una dimensione di 2048 o piu` puo` essere d'aiuto.

Queste opzioni controllano il numero totale di probe che puo` uscire dalla macchina sorgente per un host group. Esse sono usate per port scanning e host discovery. Di default, Nmap calcola un parallelismo ideale in continuo cambiamento a seconda delle performance della rete. Se c'e` un elevato numero di pacchetti che viene scartato, Nmap rallenta e lavora su un numero minore di probe in uscita. Il numero ideale di probe in uscita incrementa poi gradualmente fintantoche` la rete lo permette. Di default, il parallelismo puo` arrivare ad un minimo di 1 se la rete si dimostra essere poco affidabile; puo` invece aumentare a diverse centinaia per una rete in condizioni ottimali.

L'uso piu` comune consiste nell'impostare --min_parallelism ad un valore maggiore di 1 per accelerare le scansioni di reti o host che rispondono in maniera non adeguata. E` abbastanza rischioso giocare con quest'opzione, in quanto impostandola ad un valore troppo alto puo` influire negativamente sull'accuratenzza. Impostandola manualmente inoltre riduce l'abilita` di Nmap di controllare dinamicamente il parallelismo, basandosi sulle condizioni della rete. Un valore di 10 e` abbastanza ragionevole, anche se in genere le modifiche a questo parametro vengono usate come ultima risorsa.

L'opzione --max_parallelism viene impostata a volte sul valore 1 per impedire a Nmap di inviare piu` di un probe alla volta verso un determinato host. Questo puo` essere d'aiuto quando usato insieme all'opzione --scan_delay (discussa in seguito), anche se quest'ultima in genere e` piu` che sufficiente da sola per lo scopo.

Nmap mantiene un valore di timeout aggiornato per determinare quanto ci vorra` per un probe response prima di ritrasmettere il probe. Questo viene calcolato basandosi sui tempi di response degli ultimi probe inviati. Se la latenza della rete dovesse oscillare troppo questo timeout puo` crescere fino ad un valore di diversi secondi. Inoltre esso e` impostato inizialmente ad un valore abbastanza alto e potrebbe restare su quel valore per tutto il tempo in cui Nmap effettua la scansione su host che non rispondono.

Le seguenti opzioni prendono come parametro un valore espresso in millisecondi. Specificando limiti di --max_rtt_timeout e di --initial_rtt_timeout inferiori ai valori di default e` possibile ridurre di molto i tempi di scansione. Questo e` vero in particolare per scansioni di tipo "pingless" (opzione -P0, ovvero senza effettuare un ping preliminare) e nei confronti di reti particolarmente protette. Tuttavia, e` bene non esagerare; infatti la scansione puo` addirittura richiedere piu` tempo del previsto nel caso in cui si specifichi un valore talmente basso da resettare il timeout dei probe (e forzarne un nuovo invio) mentre la risposta sta ancora arrivando.

Se tutti gli host sono su una rete locale, 100 millisecondi e` un valore ragionevolmente aggressivo per l'opzione --max_rtt_timeout. Se nella scansione e` coinvolto qualche routing, sarebbe meglio effettuare un ping preliminare dell'host (con l'utility ICMP ping o con un generatore di pacchetti come hping2 che puo` penetrare un firewall piu` facilmente), e osservare poi il valore massimo di andata/ritorno ("round trip") per un numero di pacchetti non inferiore a 10. E` quindi consigliato raddoppiare questo valore per l'opzione --initial_rtt_timeout e triplicarlo o quadruplicarlo per l'opzione --max_rtt_timeout. In genere si preferisce non impostare il maximum rtt al di sotto di 100 millisecondi, indipendentemente dai tempi di ping. E nemmeno al di sopra di 1000 millisecondi.

L'opzione --min_rtt_timeout e` usata molto raramente; essa puo` essere utile nel caso in cui una rete sia talmente poco affidabile che anche il default di Nmap e` troppo aggressivo. Poiche` Nmap riduce il timeout fino al valore minimo quando la rete sembra affidabile, questa esigenza di solito non e` necessaria e dovrebbe essere indicata come bug alla mailing list nmap-dev.

Alcuni host a volte richiedono un tempo estremamente lungo per portare a termine una scansione. Questo puo` essere dovuto a hardware o software poco performante o inaffidabile o a firewall troppo restrittivi. La minoranza degli host sottoposti a scansione puo` richiedere la maggior parte del tempo di scansione. A volte e` preferibile risparmiare sul tempo ed evitare questi host fin dal principio. Questo comportamento viene forzato dall'opzione --host_timeout seguito dal numero di millisecondi dopo i quali non si vuole piu` aspettare. In genere si specifica un valore di 1800000 per avere la garanzia che Nmap non sprechi piu` di mezz'ora su un singolo host. Si noti che Nmap puo` nel frattempo effettuare la scansione su altri host durante quella mezz'ora, per cui non si tratta di tempo completamente sprecato. Un host che dovesse andare in timeout viene semplicemente saltato. Non vengono mostrati l'elenco delle porte, il detection del sistema operativo ne` risultati di version detection per quell'host.

Quest'opzione obbliga Nmap ad aspettare almeno il tempo indicato (in millisecondi) tra i probe inviati ad un determinato host. Questo risulta particolarmente utile nel caso di limitazioni sulla frequenza dell'invio ("rate limiting"). Tra gli altri, in particolare le macchine Solaris in genere rispondono a scansioni UDP con un solo messaggio ICMP al secondo. Qualsiasi altro probe inviato da Nmap durante questo intervallo di tempo sarebbe quindi sprecato. Un'opzione di --scan_delay di 1000 manterra` Nmap al di sotto di questa particolare frequenza di invio di probe. Nmap comunque cerchera` di capire eventuali limiti sulla frequenza e modifichera` i ritardi sui probe di conseguenza, tuttavia non e` cattiva abitudine specificarlo sulla linea di comando quando dovesse essere noto a priori il valore ottimale.

Un'altro uso dell'opzione--scan_delay e` quello in cui si desidera evitare sistemi anti-intrusione (IDS/IPS, "intrusion-detection" e "intrusion-prevention system").

Molti host usano da tempo delle funzionalita` di "rate limiting" (limitazioni alla frequenza) per ridurre il numero di messaggi di errore ICMP che mandano (ad esempio gli errori su "port-unreachable", porta non raggiungibile). Alcuni sistemi hanno iniziato ad applicare le stesse tecniche all'invio di pacchetti RST (reset). Queste tecniche possono rallentare di molto Nmap poiche` esso continuera` a calibrare la gestione dei timing per gestire queste limitazioni di frequenza. Si puo` quindi indicare a Nmap di ignorare questi rate limits (per i port scan come il SYN scan, che non considerano le porte silenziose come aperte) mediante l'opzione --defeat-rst-ratelimit.

L'uso di questa opzione puo` ridurre la precisione di uno scan, poiche` alcune porte potrebbero restituire uno stato di non-risposta (Nmap non e` rimasto in attesa abbastanza a lungo a causa di meccanismi di rate-limiting dei pacchetti RST). Con una scansione di tipo SYN le porte "mute" (dalle quali non si e` ricevuto un RST) in questo caso vengono indicate con filtered piuttosto che chiuse. Quest'opzione e` utile solo quando si e` interessati alle porte aperte, e la distinzione tra porte open e closed non e` di alcun interesse rispetto al tempo che richiede.

Mentre le opzioni mostrate nella precedente sezione sono molto utili ed effettive nel caso in cui si voglia avere il controllo piu` preciso possibile sul comportamento di Nmap, alcuni potrebbero trovarle troppo complicate da usare. Inoltre, la scelta dei valori piu` appropriati puo` a volte richiedere piu` tempo della scansione che si sta cercando di ottimizzare. Nmap offre quindi un approccio piu` semplice mediante sei "timing templates", ovvero opzioni pre-impostate per regolare l'aggressivita` della scansione. Esse si specificano mediante l'opzione -T seguita dal numero del template corrispondente o dal suo nome. Essi sono: paranoico (0), furtivo (1), educato (2), normale (3), aggressivo (4) e folle (5). I primi due vengono usati per evitare i sopracitati sistemi anti-intrusione (IDS). La modalita` "gentile" rallenta la scansione in modo da usare meno banda e risorse sulla macchina bersaglio. La modalita` "normale" e` di default (e pertanto l'opzione -T3 non modifica nulla). La modalita` "aggressiva" incrementa la velocita` assumendo che si e` su una rete veloce ed affidabile. Infine la modalita` "folle" da` per scontato che si e` su una rete estremamente veloce ed affidabile o che si vuole sacrificare l'accuratezza in nome della velocita`.

Questi template consentono all'utente di specificare quanto aggressivi si desidera essere, lasciando al tempo stesso a Nmap il compito di scegliere i valori piu` appropriati. I template inoltre effettuano piccoli aggiustamenti sui timing per i quali non esistono opzioni che ne consentono il controllo. Ad esempio, l'opzione -T4 impedisce al ritardo dinamico per una scansione di andare al di sotto della soglia dei 10 millisecondi per le porte TCP, e l'opzione -T5 limita questo valore a 5 millisecondi. I template possono essere usati insieme a controlli piu` precisi a patto che il template venga specificato per primo. Altrimenti i valori impostati dal template potrebbero sovrascrivere quelli specificati dall'utente. Si raccomanda di usare l'opzione -T4 nel caso in cui si desideri effettuare scansioni di reti abbastanza recenti e affidabili; inoltre e` consigliabile mantenere quell'opzione (intesa come inserita all'inizio dei comandi) anche qualora si dovessero aggiungere controlli piu` precisi in modo da beneficiare da tutti i piccoli miglioramenti che dovessero intervenire.

Se la propria connessione e` a banda larga o di tipo ethernet, si raccomanda di usare sempre l'opzione -T4. Alcuni prediligono anche l'opzione -T5, nonostante per i piu` sia troppo aggressiva. Altri a volte usano l'opzione -T2 perche` credono che sia meno propensa a mandare in crash un host o perche` si considerano persone educate. Spesso essi non si rendono conto di quanto e` lenta l'opzione -T Polite; una scansione di questo tipo puo` impiegare anche dieci volte il tempo richiesto per una scansione di default. Crash di host e problemi di banda sono rari con le opzioni di timing di default (opzione -T3) e pertanto e` l'opzione consigliata a chi deve effettuare scansioni senza dare troppo nell'occhio. Omettere una scansione di tipo version detection e` molto piu` efficiente del giocare con i valori di timing per ridurre i problemi sopracitati.

Mentre le opzioni -T0 e -T1 potrebbero essere utili per evitare gli allarmi di un IDS (sensore anti-intrusione), esse richiederanno un tempo estremamente lungo per portare a termine una scansione di migliaia di host o di porte. In una situazione di questo tipo si suggerisce di lavorare sui valori esatti di timing richiesti piuttosto che avvalersi delle opzioni preimpostate nelle opzioni -T0 e -T1.

Gli effetti principali dell'opzione T0 sono quello di serializzare la scansione in modo da affrontare una sola porta alla volta, e al tempo stesso quello di attendere cinque minuti tra l'invio di un probe e il successivo. Le opzioni T1 e T2 sono simili ma attendono rispettivamente 15 secondi e 0.4 secondi tra un probe e l'altro. L'opzione T3 e` il comportamento di default di Nmap (che include il parallelismo). L'opzione T4 ha lo stesso risultato dell'impostare --max_rtt_timeout 1250 --initial_rtt_timeout 500 e di impostare il ritardo massimo per una scansione TCP a 10 millisecondi. Infine l'opzione T5 e` equivalente a --max_rtt_timeout 300 --min_rtt_timeout 50 --initial_rtt_timeout 250 --host_timeout 900000 e ad impostare il massimo ritardo TCP (maximum delay) a 5 millisecondi.