Overview
Not every application wants TCP's overhead. UDP (User Datagram Protocol) takes the opposite approach: send the data and move on, with no connection setup, no acknowledgements, and no retransmission. This lesson explains UDP's behavior and when its trade-offs are the right choice.
Learning objectives
- Describe UDP's connectionless, best-effort model.
- Contrast UDP with TCP.
- Identify applications suited to UDP.
Core concept
UDP is connectionless and best-effort: it sends independent datagrams without establishing a session and without guaranteeing delivery, ordering, or duplicate protection. There is no handshake and no acknowledgement — a datagram is simply sent toward its destination port.
This makes UDP fast and lightweight but unreliable in the technical sense: the network may lose, reorder, or duplicate datagrams and UDP will not fix it. If an application needs reliability over UDP, it must implement that itself.
How it works
A UDP datagram carries just enough header to identify source and destination ports, a length, and a checksum — far less overhead than TCP's connection state and sequencing. There is no window, no retransmission timer, and no ordering logic. The sender does not wait for the receiver; it fires the datagram and continues. This minimal design gives lower latency and less per-packet cost, at the price of no built-in delivery guarantees.
Practical example
A live video call uses UDP. If one packet of audio is lost, retransmitting it would arrive too late to be useful — a brief glitch is preferable to a stall. UDP's "send and move on" behavior suits this: the call keeps flowing in real time. DNS queries also use UDP for speed, since a lookup is a small, quick request/response that can simply be retried if no answer comes.
Cybersecurity relevance
UDP's connectionless nature has security implications. Because there is no handshake, source addresses are easy to spoof, which enables amplification/reflection DDoS attacks (e.g. abusing DNS or NTP: a small spoofed request triggers a large reply sent to a victim). UDP scanning behaves differently from TCP scanning because there is no handshake to observe. Analysts must account for these differences when monitoring or testing UDP services.
Common mistakes
- Calling UDP "broken" — it is best-effort by design, ideal for latency-sensitive or simple request/response traffic.
- Expecting ordering or delivery guarantees from UDP — there are none.
- Overlooking spoofing/amplification risk in UDP-based services.
Key takeaways
- UDP is connectionless and best-effort: no handshake, acknowledgements, ordering, or retransmission.
- It trades reliability for low latency and low overhead, suiting real-time media and quick request/response protocols like DNS.
- Its lack of a handshake makes source spoofing easy, enabling amplification/reflection DDoS.
Check your understanding
- Why is UDP a better fit than TCP for a live voice or video call?
- How does UDP's connectionless design contribute to amplification DDoS attacks?