Concept · 8 min read
TCP vs UDP
Why do some scans answer and others simply go quiet?
TCP negotiates and confirms a stream. UDP sends datagrams and accepts silence. Nearly every 'is this port open?' ambiguity comes from that difference.
TCP: three-way handshake
A SYN scan stops after SYN/SYN-ACK and sends RST, which is why it is faster and why it needs raw sockets. A connect scan completes the handshake through the OS.
text
client server ---- SYN ----> (half-open) <--- SYN/ACK --- (waiting) ---- ACK ----> (established)
What 'open|filtered' really means
UDP has no handshake. If a probe is dropped you cannot distinguish 'nothing is listening' from 'a firewall dropped it' from 'the service got the packet and stayed quiet'. Nmap reports that ambiguity instead of inventing an answer.
- ICMP port-unreachable in response to a datagram → closed
- Any application response → open
- Silence → open|filtered, and you must say so
Where each one lives
- TCP: HTTP/1.1 and HTTP/2, SMTP, SSH, LDAP, SMB, databases
- UDP: DNS, NTP, DHCP, SNMP, RIP, QUIC/HTTP/3 — connection-oriented behaviour is rebuilt in the application
- QUIC is the instructive case: unreliable datagrams, but per-stream ordering and its own loss recovery — an argument against 'UDP is insecure by nature'.
Check your understanding
Answer before expanding. If you cannot explain it in one sentence, the section above needs a re-read.
Why is a UDP sweep of all ports a bad idea on a small device?Q1
Each probe invites an ICMP reply from a device whose stack or rate limiter can be overwhelmed. Restrict the port list, always.
A UDP port returns 'open' but the service rejects your query. Contradiction?Q2
No — 'open' means it answered something. Authorisation is an application-layer question.
Where this shows up
Tools in the directory whose commands assume this knowledge.