UDP: Connectionless, Datagram, Use Cases
What This Concept Is
UDP (User Datagram Protocol) is the simplest thing you can build on top of IP and still call a transport protocol. It adds exactly three things to what IP already provides:
- Source and destination port numbers, so multiple processes on one host can share the same IP.
- Length of the UDP payload.
- A checksum covering the header and payload (optional over IPv4, mandatory over IPv6).
Everything else that TCP does -- connections, ordering, reliability, flow control, congestion control -- UDP deliberately leaves out. You get a best-effort datagram: it either arrives intact or it doesn't, the sender is not told, and two datagrams can arrive out of order.
Why It Matters Here
UDP is not "TCP for lazy people." It is the right protocol whenever:
- latency matters more than retransmission (voice, video, games)
- the message is a single small request/response where a full handshake is wasteful (DNS, NTP)
- the application wants to implement its own reliability or ordering (QUIC, many RPC systems)
- there is no single conversation to maintain state for (one-to-many multicast, service discovery)
Every modern stack still uses UDP. QUIC, which underpins HTTP/3, lives on UDP precisely because the kernel's TCP is too rigid for what it wants to do.
Concrete Example
A DNS query for example.com is one UDP datagram going out and one coming back. The UDP header on the wire:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-------------------------------+-------------------------------+
| Length | Checksum |
+-------------------------------+-------------------------------+
| |
| Payload ... |
| |
+---------------------------------------------------------------+
That is it. Eight bytes of header and then the DNS message. If the datagram is lost, the client times out and retries. If a second query arrives before the first, the client disambiguates by transaction id inside the payload, not by UDP.
Common Confusion / Misconception
"UDP is unreliable, so it is for unimportant data." No. UDP is unreliable at the transport layer. Applications that use UDP often implement their own reliability tailored to the workload. QUIC, for example, is extremely reliable while running on UDP.
"UDP is faster than TCP." Only under specific conditions -- usually when the payload is small and the handshake would dominate. For bulk transfer, TCP's pipelined design is very hard to beat.
How To Use It
Ask four questions before choosing UDP:
- Is my message small and one-shot (fits in one datagram)?
- Can I tolerate occasional loss, or will I handle it myself?
- Do I need multiple receivers or low-latency broadcast-like semantics?
- Would TCP's head-of-line blocking hurt more than losing a packet would?
If yes to one or more, UDP is a legitimate pick. Otherwise default to TCP.
Check Yourself
- If UDP has no connection state, how does a server distinguish replies to two different clients?
- Why is the UDP checksum optional over IPv4 but mandatory over IPv6?
- Name two application protocols that use UDP and say why TCP would have been the wrong choice.
- Why can a UDP datagram arrive with its length field mismatching the actual bytes, and what should a defensive receiver do?
- Why does QUIC -- which is reliable -- live on UDP instead of TCP?
Protocols That Are UDP-Based
Some protocols you have probably used that ride UDP:
- DNS -- single small request/reply, retried at the application level.
- NTP -- time synchronization; loss is handled by the next beacon.
- DHCP -- bootstrap-time address configuration.
- QUIC (HTTP/3) -- user-space reliability and encryption on top of UDP.
- VPN protocols like WireGuard -- encrypt datagrams end-to-end.
- Real-time media -- RTP carrying voice/video frames, often with forward error correction.
Seeing the list once dispels the "UDP is only for toys" notion.
Mini Drill or Application
- Use
dig +short example.com @1.1.1.1. - In a second terminal, run
sudo tcpdump -n -i any port 53. - Capture the query and the reply. Count the packets. Note there is no handshake.
- Compare to
dig +tcp +short example.com @1.1.1.1and count the packets again. Explain the difference.