Non riesco a trovare una risposta per questo.
Qualche suggerimento?
La differenza è nella natura stessa dei due protocolli.
TCP è un orientato alla connessione protocollo. Ciò significa che i sistemi devono stabilire e confermare una connessione stabile: per TCP, il processo è comunemente noto come "a tre vie handshake "- prima che i dati vengano effettivamente trasferiti. Poiché il processo deve avvenire rapidamente per una buona connessione, è ragionevole aspettarsi che una porta TCP aperta risponda in breve tempo quando viene rilevata. Ciò significa che il timeout prima di ipotizzare che una porta sia chiusa potrebbe anche essere molto breve.
UDP , d'altra parte, è un connectionless protocol. Per UDP, le comunicazioni vengono inviate senza alcuna aspettativa di una conferma tempestiva della ricezione dal terminale remoto. Pertanto, è necessario prevedere un timeout più lungo prima che si possa presumere che una porta remota sia chiusa, anche dopo il timeout, tale ipotesi non è garantita al 100%.
In un certo modo, è un po 'come questo:
TCP chiamerà il tuo telefono e attenderà il ritiro effettivo per avvertirti di un incendio sul tuo posto di lavoro. Se raccogli e ti parlano, sanno che hai ricevuto il messaggio. Se la tua segreteria telefonica riprende o il telefono squilla > 4 volte senza reindirizzamento, possono essere abbastanza sicuri che non riceverai il messaggio abbastanza presto.
UDP invierà un annuncio avviso di emergenza al telefono per dirti del fuoco. Non sapranno se hai ricevuto il messaggio a meno che non ti vedano uscire dall'edificio, 5 rampe di scalate e un cruscotto di 100 metri o due dopo. E questo è scontato che tu fossi persino nell'edificio per cominciare.
Ora, supponiamo che tu abbia dovuto informare circa 1.000 persone di un incendio. Ma potevi dirlo solo uno alla volta, e dovevi aspettare la conferma di ricezione (o un tempo ragionevole per essere sicuro del probabile non ricevimento) da ciascuno prima di provare il prossimo.
Port scanning (con Nmap o qualsiasi altro strumento) è un po 'come quello. TCP andrà relativamente veloce e probabilmente sarà abbastanza preciso. Con l'UDP l'edificio probabilmente brucerà prima di passare alla lista solo una volta , e non sarai ancora sicuro se le persone a cui hai inviato il messaggio fossero ancora in giro per prendersene cura.
Dalla pagina nmap
A big challenge with UDP scanning is doing it quickly. Open and filtered ports rarely send any response, leaving Nmap to time out and then conduct retransmissions just in case the probe or response were lost. Closed ports are often an even bigger problem. They usually send back an ICMP port unreachable error. But unlike the RST packets sent by closed TCP ports in response to a SYN or connect scan, many hosts rate limit ICMP port unreachable messages by default. Linux and Solaris are particularly strict about this. For example, the Linux 2.4.20 kernel limits destination unreachable messages to one per second (in net/ipv4/icmp.c).
Nmap detects rate limiting and slows down accordingly to avoid flooding the network with useless packets that the target machine will drop. Unfortunately, a Linux-style limit of one packet per second makes a 65,536-port scan take more than 18 hours. Ideas for speeding your UDP scans up include scanning more hosts in parallel, doing a quick scan of just the popular ports first, scanning from behind the firewall, and using --host-timeout to skip slow hosts.
Sono protocolli diversi. In UDP devi aspettare la risposta per un timeout specificato, al TCP si vede immediatamente che una porta è aperta dopo aver ottenuto l'handshake a tre vie. Se è chiuso, è più probabile che tu riceva un pacchetto con il flag RST impostato, così puoi anche passare immediatamente alla porta successiva.
È possibile ottenere velocità extra per le scansioni UDP, con nmap puoi usare --min-rate , --max-rtt-timeout e --max-retries per mettere a punto alcune impostazioni.
Leggi altre domande sui tag tcp ports network-scanners scan udp