How UDP Works: Simplicity and Speed

When you make a video call or play an online game, you need data delivered fast—not perfectly. If your video call froze every time a packet got lost so the protocol could request a retransmission, you'd understand immediately why UDP exists.

The User Datagram Protocol takes a fundamentally different approach than TCP: send the data and move on. No guarantees, no retries, no fuss. This apparent recklessness is precisely what makes UDP one of the Internet's most important protocols.

The Connectionless Philosophy

UDP has no memory. There's no three-way handshake, no connection establishment, no connection teardown. When an application wants to send data, it creates a datagram and sends it. That's it.

Each datagram is completely independent—a standalone message with no relationship to any other datagram. The sending application addresses each one with a destination IP address and port number, and UDP's job ends the moment it hands the packet to the IP layer below. What happens next—whether the datagram arrives, gets lost in transit, or arrives out of order—is not UDP's concern.

This sounds irresponsible until you realize what it eliminates: no sequence numbers to track, no acknowledgment packets consuming bandwidth, no timers waiting for responses. All the machinery TCP uses to guarantee delivery simply doesn't exist. The result is a protocol that's fast precisely because it promises nothing.

The Minimal Header

UDP's philosophy is visible in its header: just 8 bytes containing four fields. TCP's header is at least 20 bytes (up to 60 with options). Every byte saved in the header is a byte available for your actual data.

Source port (16 bits): Identifies the sending application. Optional for one-way communication, but necessary if you want responses.

Destination port (16 bits): Specifies which application on the receiving machine should get this datagram—your DNS resolver, video streaming app, or game client.

Length (16 bits): Total size of the datagram including header. Maximum theoretical size is 65,535 bytes, though practical limits are smaller due to network constraints.

Checksum (16 bits): Detects if bits were corrupted during transmission. Here's the honest part: UDP doesn't fix errors. It just throws away corrupted datagrams. The checksum is optional in IPv4, mandatory in IPv6.

No sequence numbers. No acknowledgment numbers. No window sizes. No connection management flags. This minimal header is why UDP can deliver data with so little latency.

What UDP Deliberately Omits

UDP provides no reliability mechanisms. If a datagram gets lost—dropped by a congested router, corrupted by a faulty cable, misrouted—UDP won't notice and won't care. No retransmissions, no duplicate detection, no delivery guarantees.

UDP provides no ordering guarantees. Send three datagrams in sequence, and they might arrive in any order, or some might not arrive at all. Each takes an independent path through the network.

UDP has no flow control. It won't slow down if the receiver is overwhelmed. Send faster than the receiver can process, and excess packets simply get dropped.

UDP has no congestion control. It won't detect network congestion or adjust its sending rate. Poorly designed UDP applications can flood a network even when conditions are degraded.

These omissions aren't limitations—they're the entire point.

Why Omissions Are Features

Without connection setup, acknowledgments, or retransmissions, UDP delivers data with minimal latency. For a video call, getting the latest audio frame quickly matters more than ensuring an audio frame from 200 milliseconds ago eventually arrives. By the time a retransmitted packet shows up, it's obsolete.

The 8-byte header means more bandwidth goes to actual data. For applications sending many small messages, this adds up.

UDP excels at broadcast and multicast. With no connection state to maintain, a single datagram can go to multiple recipients simultaneously—essential for streaming to multiple viewers or service discovery.

Most importantly, UDP gives applications control. Because it provides so little, applications can implement exactly the reliability, ordering, or congestion control they need. Nothing more, nothing less.

The Datagram Model

In UDP terminology, each packet is a datagram—a self-contained, independent message. This contrasts with TCP's stream-oriented approach. When you send data via UDP, you send discrete datagrams, and the boundaries between them are preserved. Send three 100-byte datagrams, the receiver gets three 100-byte messages, not one 300-byte stream.

This message preservation matters. A DNS query is naturally a discrete message. A game state update is a snapshot at a specific moment. A voice packet contains a specific time slice of audio. These applications think in messages, not streams. UDP's datagram model fits how they actually work.

Where UDP Thrives

DNS uses UDP because name lookups need to be fast, and a lost query can simply be retried. Most DNS messages fit in a single datagram.

Voice and video calls rely on UDP because delivering audio quickly matters more than perfect delivery. Humans barely notice if a few milliseconds of audio disappear. They definitely notice if speech is delayed waiting for retransmissions.

Online games send player positions via UDP because the latest position matters, not positions from half a second ago. Games typically implement their own reliability for critical events (item pickups, score changes) while using unreliable UDP for the constant stream of position updates.

Streaming protocols like RTP build on UDP to deliver live video and audio. Network management protocols like SNMP use UDP for collecting monitoring data. Even QUIC—the modern protocol powering HTTP/3—builds on UDP, implementing its own reliability while benefiting from UDP's low latency.