UDP: Explanation & Insights

Fire the packet and forget it — no handshake, no guarantees, and that is exactly the point.

What It Is

UDP — the User Datagram Protocol — is the transport protocol that does almost nothing, on purpose. It sits at the transport layer of the OSI model, right next to TCP, and where TCP is an elaborate machine of handshakes and acknowledgements, UDP is a postcard: address it, drop it in the box, walk away. No connection is established. No receipt comes back. If it arrives, great; if it doesn't, UDP will never know and never tell you. It's connectionless, unreliable, and unordered — and reading those three words as insults is the single most common misunderstanding about it.

Here's the reframe that makes UDP click. The job of TCP is to hide the network's messiness behind a clean, reliable byte stream. The job of UDP is to not do that — to hand the application a thin wrapper over raw IP packets and get out of the way. Why would you want that? Because reliability has a cost (latency, head-of-line blocking, per-connection state), and a whole class of applications would rather pay none of it and handle correctness themselves — or simply not care about the lost packet at all. A dropped frame in a video call is gone before you'd want it resent. A DNS query that vanishes is cheaper to just ask again than to wrap in a handshake. For these, UDP's "do nothing" is not a limitation — it's the feature.

The rest of this page covers UDP's almost-comically-small header, why no handshake means lower latency, what the application must do for itself if it wants guarantees back, the workloads where that trade fits (and where it doesn't), and the plot twist where the web's newest, fastest protocol is built on top of this supposedly "unreliable" thing.

How It Works

The Whole Header Is Eight Bytes

The clearest way to feel the difference between UDP and TCP is to look at what each one staples to the front of your data. A TCP header is at least 20 bytes and carries sequence numbers, acknowledgement numbers, window sizes, flags, and options — all the machinery of a managed conversation. A UDP header is eight bytes, and that's the entire story:

 0      15 16     31
+--------+--------+
| Src Port|Dst Port|   ports — who sent it, who it's for
+--------+--------+
| Length  |Checksum|   total length, and an optional integrity check
+--------+--------+
|        Data       |
+-------------------+

Source port, destination port, length, checksum. That's it. No sequence number because nothing is ordered, no acknowledgement field because nothing is acknowledged, no window because there's no flow to control. The checksum is the one nod to safety — it lets the receiver detect a corrupted datagram and silently drop it — and on IPv4 it's even optional. This minimalism is why UDP is fast: less to build, less to parse, nothing to track between packets.

No Handshake, No State, No Memory

A UDP "connection" isn't a connection at all — there's no setup ceremony like TCP's three-way handshake. The first packet is the conversation, which has two big consequences. First, latency: there's no round-trip to pay before your data can flow, so a request-response exchange (ask, answer, done) finishes in one round-trip instead of two-plus. For a DNS lookup that happens before every web request, shaving that handshake is enormous.

Second, no per-connection state. A TCP server tracks every open connection — sequence numbers, windows, timers — and that bookkeeping costs memory and caps how many it can hold. A UDP server holds nothing; each datagram is handled and forgotten, so one socket can field packets from a million senders without breaking a sweat. That's why UDP underpins services that fan out to huge numbers of clients — and also why a UDP service is a tempting amplification vector for denial-of-service attacks: spoof the source address, send a tiny query that triggers a huge reply, and the reply lands on the victim. The very statelessness that makes UDP scale is what makes it abusable.

If You Want Guarantees, You Build Them

UDP gives you delivery of individual datagrams with no promise any arrive, arrive once, or arrive in order. So an application that needs reliability builds exactly the reliability it needs — no more. A request-response protocol like DNS just sets a timeout and re-asks if no answer comes; that's the whole reliability layer, a few lines. NTP doesn't even bother — lose a time sample and the next is along in a moment. Real-time media adds a sequence number and a jitter buffer to reorder and smooth, but deliberately drops late packets rather than wait, because a late video frame is worthless. Each app picks its own point on the reliability/latency curve instead of accepting TCP's one fixed setting.

Note

"UDP is unreliable" doesn't mean it's flaky or low-quality. On a healthy local network, UDP packets get delivered just as dependably as TCP ones — the wire is the same. "Unreliable" is a precise technical term: the protocol makes no delivery guarantee. It's a statement about whose job error-handling is, not about how often packets actually drop.

What Uses UDP, and Why

The pattern across UDP's users is consistent: short exchanges, real-time data, or one-to-many delivery — cases where TCP's guarantees would cost more than they're worth.

DNS — the canonical example. A query and its answer are usually one small packet each; wrapping that in a TCP handshake would more than double the latency of every name lookup on the internet. DNS uses UDP by default and only falls back to TCP for answers too big for a single datagram or for zone transfers.
NTP — clock synchronisation. Tiny, frequent, and a lost sample simply doesn't matter; the protocol is built around statistical sampling, not guaranteed delivery.
VoIP and video — voice and video calls. A retransmitted audio packet would arrive too late to play, so the codec would rather conceal the gap and move on. Smoothness beats completeness.
Online gaming — your position at time T is stale by time T+1, so resending a lost position update is pointless; just send the next one. Latency is the whole game.
DHCP, broadcast, and multicast — DHCP hands out IP addresses to clients that don't have an address yet, so a connection-oriented protocol is impossible. And only UDP can do broadcast (to everyone on the subnet) and multicast (to a group) — TCP is strictly point-to-point.
QUIC and HTTP/3 — the surprise guest, and the best one.

The Plot Twist: QUIC Runs on UDP

For decades the story was simple: TCP for things that matter, UDP for things that are fast and disposable. Then Google looked hard at TCP's costs — the handshake latency, and especially head-of-line blocking, where one lost packet stalls every byte behind it — and fixed them not by patching TCP (you can't; it's baked into every router and OS) but by rebuilding transport from scratch on top of UDP. The result is QUIC, the foundation of HTTP/3.

QUIC uses UDP as a bare delivery substrate and implements its own connection setup, encryption, congestion control, and — the clever bit — independent reliable streams. Lose a packet in one stream and only that stream waits; the others flow on. It folds the connection and TLS handshakes into a single round-trip, sometimes zero. So the protocol carrying a growing share of the modern web is, at the wire level, "unreliable" UDP datagrams — with all the reliability machinery moved up into the application where it can be tuned per-stream. UDP didn't win by being reliable; it won by being a blank canvas. That's the deepest lesson here: TCP bundles its choices and hands them to you; UDP hands you the raw material and trusts you to make your own.

How I Inspect It

UDP is harder to watch than TCP precisely because it's stateless — there are no connections to list, only sockets that are open and packets that flow. ss shows you the listening sockets:

ss -ulnp        # UDP, listening, numeric, with process — what's bound to a UDP port
ss -uap         # UDP, all sockets, with owning process

ss -ulnp answers "is anything actually listening for UDP on this port" — the first check when a DNS resolver or NTP daemon seems dead. The classic netstat -ulnp does the same. But because there's no connection state to read, the only way to confirm packets are moving is to watch the wire with tcpdump:

tcpdump -ni eth0 udp port 53     # watch DNS queries and replies fly past

That's how you tell "the query left but no reply came back" (a firewall eating the response, or a dead upstream) from "the query never left" (a local config problem). To send a UDP probe by hand, nc in UDP mode does it — with the honest caveat below:

nc -u example.com 53     # open a UDP "connection" and type at it
nc -uvz example.com 123  # attempt a UDP port probe

Warning

A UDP port "check" lies more than a TCP one. Because nothing has to answer, nc -uz and nmap -sU often can't tell "open" from "open but silent" — a UDP scan reports open|filtered and shrugs. The only reliable confirmation a UDP service is alive is a real protocol exchange: ask a DNS server an actual question and see if it answers.

Why It Matters

The reason this page exists alongside TCP is that the two of them teach one idea together: reliability is a tradeoff, not a virtue. TCP spends latency and accepts head-of-line blocking to give you ordered, guaranteed delivery. UDP spends those guarantees to buy speed, statelessness, and broadcast — and then lets the application decide which slivers of reliability to rebuild. Neither is "better." They're tuned for different problems.

So the opinionated direction, the same one the TCP page gives from the other side: default to TCP. Moving a file, serving a page, writing to a database — you want every byte, in order, and TCP is the boring correct answer. Reach for UDP only when you can name the reason: lowest possible latency with loss tolerated (real-time media, gaming), broadcast or multicast, tiny request-response where a handshake would dominate the cost (DNS, NTP), or you're deliberately building your own transport (QUIC). Pick UDP on purpose, never by accident. "I'll just use UDP, it's faster" without a tolerance-for-loss story is how you ship a protocol that mysteriously drops data under load and spend a month discovering you reinvented a worse TCP. Choose the tradeoff that fits the job — that's the entire skill.