UDP Protocol

What is UDP?

UDP (User Datagram Protocol) is one of the two core transport-layer protocols of the internet (alongside TCP). It’s connectionless and lightweight: you send a datagram and it’s dispatched immediately, with no connection setup, no guarantee of delivery, no ordering, no retransmission of lost packets, and no built-in congestion control. UDP does the bare minimum — address the data to a port and send it — trading away TCP’s reliability machinery for speed and low overhead. It’s the right tool whenever getting data there fast matters more than getting every packet there in order.

UDP vs TCP — the fundamental tradeoff

The core concept is the UDP vs TCP tradeoff, and understanding it explains everything about when to use which. TCP is connection-oriented and reliable: it establishes a connection (the three-way handshake), guarantees that data arrives complete and in order, retransmits lost packets, and manages flow and congestion control — at the cost of overhead and latency (setup round-trips, waiting for acknowledgements, and head-of-line blocking where one lost packet stalls everything behind it). UDP does none of that: no handshake, no acknowledgements, no reordering, no retransmission — so it’s faster and has less overhead, but packets can be lost, duplicated, or arrive out of order, and the application must tolerate or handle that itself. The rule of thumb: use TCP when you need every byte reliably and in order (web pages, file transfers, APIs, email — most application traffic); use UDP when speed and low latency matter more than perfect reliability, and occasional loss is acceptable or handled at the application layer.

Where UDP shines — and the modern twist

UDP’s classic use cases are those where stale data is useless and retransmitting it would only add delay. Real-time media — voice (VoIP), video calls, live streaming: if a packet of audio is lost, you don’t want to pause everything to retransmit it (that would cause stutter); you want to skip it and keep going with the current audio, so a tiny glitch beats a delay. Online gaming: player position updates are time-sensitive — a lost update is obsolete instantly (a newer one is already coming), so retransmitting it is pointless. DNS: queries are small, single-shot, and fast over UDP (with fallback to TCP for large responses). DHCP, streaming telemetry, and other fire-and-forget signaling. The important modern twist: QUIC — the transport underlying HTTP/3 — is built on UDP, but re-implements reliability, ordering, and congestion control in user space on top of UDP, getting TCP-like guarantees while avoiding TCP’s head-of-line blocking and rigidity. This is a big deal: it means UDP is no longer just for lossy real-time media — it’s now the foundation of next-generation reliable web transport, precisely because building on UDP’s minimal base gave protocol designers the freedom TCP’s ossified implementation didn’t allow. Practical realities: because UDP has no congestion control, applications using it must be careful not to flood the network (a UDP application that blasts packets without restraint can cause congestion collapse — QUIC and well-designed UDP apps add their own congestion control); UDP is also more prone to being blocked or throttled by firewalls and networks tuned for TCP (which is why HTTP/3 needs TCP fallback); and its connectionless, spoofable nature makes it a common vector for amplification DDoS attacks (small spoofed request, large response to the victim). The recurring mistakes: using UDP where you actually need reliability (and then hand-rolling a worse version of TCP), and deploying UDP without congestion control or rate limiting.

What people get wrong

• Using UDP where reliability is needed — if you need every byte in order, TCP already solves that well; re-implementing reliability badly on UDP is a common trap (QUIC does it properly).
• No congestion control: UDP won’t throttle itself, so an application that floods packets can cause congestion collapse — well-behaved UDP apps must add their own pacing.
• Forgetting firewalls block/throttle UDP — networks tuned for TCP may drop UDP, which is why UDP-based protocols like HTTP/3 need TCP fallback and why some UDP apps fail on restrictive networks.

Primary source: RFC 768: User Datagram Protocol