Skip to content

UDP

TL;DR

UDP is like shouting into a crowd — fast, but no guarantee anyone heard you. It skips all the safety checks that TCP provides, which makes it perfect for things like video calls and online gaming where speed matters more than perfection.

The Walkie-Talkie of the Internet

Imagine you're playing a fast-paced online game. Your character's position needs to update 60 times per second. What happens if one of those updates gets lost in transit?

With a protocol that guarantees delivery, the system would pause everything, request the missing update, wait for it to arrive, and then resume. Your game would stutter and freeze constantly.

The smarter approach? Just skip it. Your character's position was at (10, 20) and now it's at (10, 22) — who cares that we missed (10, 21)? The next update is already here.

That's the philosophy behind UDP (User Datagram Protocol). It's the walkie-talkie of the internet: press the button, talk, and hope the other person heard you. No confirmation, no do-overs.

UDP datagram structure

What You Get With UDP

When a UDP message (called a datagram) arrives at your application, here's everything you know:

  • Who sent it (source IP address and port)
  • Who it was meant for (destination IP address and port)
  • The data itself (a blob of bytes)

That's it. That's the whole protocol.

What UDP Deliberately Skips

Here's the deal: UDP doesn't do any of the safety stuff that TCP does. And that's on purpose.

Feature Does UDP do it?
Connection setup (handshake) Nope — just send it
Guaranteed delivery Nope — packets can vanish
Ordering Nope — packets can arrive shuffled
Flow control Nope
Congestion control Nope
Header size Tiny — just 8 bytes

"Wait, packets can just disappear and nobody tells you?" Yep. "And they can arrive in random order?" Yep.

Sounds terrible. So why would anyone use this?

When "Unreliable" Is Actually What You Want

Let's think about a phone call (like a Zoom call).

You're talking to someone. One tiny audio packet — maybe 20 milliseconds of sound — gets lost somewhere in the network. What should happen?

Option A: Pause the whole call. Request the missing packet. Wait for it. Then play it. Your friend hears a long awkward silence followed by a word from 2 seconds ago. Terrible.

Option B: Skip it. Your friend hears a tiny blip — barely noticeable — and the conversation flows naturally.

Option B is clearly better. And that's exactly what UDP enables. The lost packet is already outdated by the time you could retransmit it. Better to move on.

Where UDP Shines

  • Video and audio streaming — A dropped frame is invisible. A frozen stream is infuriating.
  • Online gaming — Player positions update dozens of times per second. Missing one is nothing.
  • Voice calls (VoIP) — Same logic as the phone call example above.
  • DNS lookups — Tiny, fast queries. If one gets lost, just send another. Takes milliseconds.
  • High-volume logging/metrics — If you're sending thousands of log entries per second and a few get lost, that's usually fine.

One Gotcha: Browsers Can't Do Raw UDP

Here's something practical to know. Web browsers don't support sending raw UDP messages. The one exception is WebRTC (which we'll cover in Chapter 4), and that's specifically for audio/video calls.

So if you're designing something like a live reactions feature (those floating hearts on a livestream), you might want to use UDP for real-time delivery. But browser users can't receive UDP. You'd need a workaround — maybe mobile app users get the fast UDP stream while browser users get a slightly delayed HTTP-based stream that you animate smoothly in the UI.

This kind of trade-off thinking is exactly what shows up in design discussions.

The Key Takeaway

UDP makes sense when:

  • Speed matters more than completeness — real-time audio, video, gaming
  • Losing some data is fine — or even preferable to the delay of retransmitting
  • You're sending lots of small, frequent messages — where any individual loss is no big deal

If none of those apply — and most of the time they don't — you want TCP. That's next.

Interview Tip

You'll rarely need to argue for UDP in an interview. TCP is the default everyone expects. But if the problem involves real-time streaming, gaming, or video — and you can articulate why a dropped packet is better than a delayed one — that's a strong signal.