How UDP Works — Speed Over Guarantees

UDP (User Datagram Protocol) sends data without acknowledgment, ordering, or retransmission. Where TCP guarantees every byte arrives in order, UDP makes no promises at all. It sends a datagram and moves on.

David Reed defined UDP in RFC 768 in 1980. The entire specification is three pages — the shortest RFC for any major internet protocol. That brevity is the point.

Why Does UDP Exist?

TCP solves reliability, but reliability has a cost. The three-way handshake adds a round trip before any data flows. Acknowledgments and retransmissions add latency when packets are lost. Ordering guarantees mean a single lost packet blocks everything behind it.

For many applications, those costs are worse than occasionally losing data. A video call that retransmits a frame from 100 milliseconds ago just adds delay — that frame is already useless. A game sending player positions 60 times per second doesn't need every update to arrive — the next one is already on its way. A DNS lookup is a single question and answer — setting up a full TCP connection to ask one question doubles the latency.

UDP exists for applications where speed matters more than completeness.

What Does a UDP Packet Look Like?

The UDP header is 8 bytes. That's it. Compare this to TCP's 20-byte minimum header (often 32 bytes with options).

Four fields:

• Source port — where the datagram came from.
• Destination port — where it's going.
• Length — total size of header + data.
• Checksum — detects corruption (optional in IPv4, mandatory in IPv6).

No sequence numbers. No acknowledgments. No window size. No flags. No connection state. The simplicity is the feature.

How Does UDP Differ from TCP?

	TCP	UDP
Connection setup	Three-way handshake	None — just send
Delivery guarantee	Every byte, in order	Best effort — may lose, duplicate, or reorder
Flow control	Window-based	None
Congestion control	Built-in (slow start, avoidance)	None
Header size	20-32 bytes	8 bytes
Connection state	Maintained by both sides	Stateless

TCP is a phone call — you set up the connection, speak in turns, confirm you were heard, and say goodbye. UDP is dropping a letter in a mailbox — you send it and hope it arrives.

Where Is UDP Used?

DNS — The most common use of UDP on the internet. A DNS query is typically a single question in one packet and a single answer in one packet. The overhead of a TCP handshake would double the lookup time. If the answer doesn't arrive, the resolver retries — simpler and faster than maintaining a connection.

Video and audio streaming — Real-time media sends hundreds of packets per second. If a packet carrying 20 milliseconds of audio is lost, retransmitting it would arrive too late to be useful. The application compensates by interpolating or skipping, which sounds better than waiting.

Gaming — Player state updates happen every 16 milliseconds (60 FPS). A stale position update is worse than no update. Games typically send the full current state in every packet, so a lost packet is automatically superseded by the next one.

Network time (NTP) — Time synchronization needs to measure round-trip delay with minimal overhead. A TCP handshake would add variable latency, corrupting the very measurement it's trying to make.

DHCP — Your device can't use TCP to get an IP address because it doesn't have an IP address yet. DHCP uses UDP broadcasts to discover the network.

QUIC — The most important modern use of UDP. QUIC builds its own reliability, ordering, encryption, and congestion control on top of UDP's raw simplicity. It uses UDP as a thin delivery mechanism because middleboxes (firewalls, NATs, load balancers) already know how to forward UDP packets.

What About Reliability?

If an application needs reliability over UDP, it builds its own. This is exactly what QUIC does. It reimplements sequence numbers, acknowledgments, retransmission, and congestion control — but in userspace instead of the kernel. The advantage is that these can be updated without waiting for OS kernel updates and can be tailored to the application's specific needs.

Other protocols that build reliability on top of UDP include DTLS (TLS for datagrams), TFTP (trivial file transfer), and many game networking libraries that implement their own reliability layer with selective acknowledgment.

The pattern is clear: use TCP when you want the kernel to handle reliability for you. Use UDP when you need control over the tradeoffs — or when reliability isn't needed at all.

Can UDP Overwhelm the Network?

Yes. UDP has no congestion control. A UDP sender can blast packets as fast as the network interface allows, without caring whether the network or receiver can keep up. TCP self-limits — it slows down when it detects congestion. UDP does not.

This is why protocols built on UDP (like QUIC) implement their own congestion control. Without it, a UDP-based protocol could starve TCP connections sharing the same network. QUIC uses algorithms similar to TCP's (CUBIC or BBR) to be fair to other traffic.

It's also why network administrators sometimes rate-limit or block UDP on specific ports — uncontrolled UDP traffic can degrade the network for everyone.

Next Steps

Now that you understand both transport protocols — TCP for reliability and UDP for speed — you can see how higher layers build on them:

• How DNS Works — the name resolution system that runs on UDP and starts every internet connection.
• How QUIC Works — the protocol that builds TCP-like reliability on top of UDP.
• How TCP Works — revisit TCP with the contrast of UDP in mind.