When to Use UDP Over TCP

TCP assumes your problem is that data might not arrive. It solves this with acknowledgments, retransmissions, and ordering guarantees. But real-time applications face a different problem entirely: data that arrives late is worthless.

A packet that arrives late is worse than a packet that never arrives at all. This inverts everything TCP was designed for.

Real-Time Communications

Voice and video calls are the clearest example. When you're speaking with someone, a lost packet containing 20 milliseconds of audio is barely noticeable—your brain fills the gap. But that same packet arriving 200 milliseconds late because TCP retransmitted it? Now you have awkward delays and people talking over each other.

UDP lets applications implement their own recovery strategies. Modern codecs interpolate missing audio samples or skip corrupted video frames. The result is natural conversation where timing matters more than perfection. Zoom, Discord, and WebRTC all use UDP for media streams, reserving TCP only for chat messages and control signaling.

Video conferencing applications adapt in real-time: when packets are lost, they reduce quality rather than waiting for retransmissions. Latency stays low. The conversation stays interactive.

Gaming

Online gaming demands the absolute lowest latency. When you press jump in a first-person shooter, that action needs to reach the server and reflect back to all players within tens of milliseconds. TCP's retransmission delays would make fast-paced games feel unresponsive.

Game developers using UDP implement selective reliability. A player's position update that gets lost? The next update 16 milliseconds later corrects it. But "player fired weapon"? That needs acknowledgment and potential retransmission—which the game implements in its application layer, tailored to gaming rather than TCP's one-size-fits-all approach.

This gives games fine-grained control. Movement updates: unreliable and frequent. Inventory changes: reliable but infrequent. Fortnite, Call of Duty, League of Legends—all built on UDP foundations.

Live Streaming

On-demand video can buffer. Live streaming cannot.

When broadcasting a live sports event, viewers expect to see action as it happens. UDP enables low-latency streaming that prioritizes timeliness over completeness. Cloud gaming services like GeForce NOW, remote desktop protocols, and broadcast television over IP all use UDP to minimize glass-to-glass delay.

These applications send redundant data (forward error correction) so receivers can reconstruct lost packets without requesting retransmissions. If correction fails, they skip the corrupted portion. A brief glitch beats falling behind the live event.

DNS and Query-Response Protocols

DNS exemplifies UDP's efficiency for simple exchanges. When your computer looks up "connected.app", it sends one UDP packet and expects one packet back. The entire transaction completes in a single round trip.

Using TCP would require three packets just to establish the connection, then the query and response, then teardown—multiplying overhead for a simple question and answer. DNS implements its own retry logic: no response within a few seconds? Send the query again, possibly to a different server.

NTP (clock synchronization), SNMP (device monitoring), and DHCP (network configuration) follow the same pattern. Simple exchanges don't need TCP's connection state and ordering guarantees.

Custom Reliability with QUIC

Sometimes applications need reliability guarantees that differ from TCP's model. A file sync service might want reliable transfer but doesn't care about ordering between files. TCP would block all transfers waiting for one lost packet. UDP-based protocols can continue transferring other files.

QUIC (which powers HTTP/3) builds on UDP to implement reliability per-stream rather than per-connection. This prevents head-of-line blocking—where one lost packet stalls everything behind it—that plagues TCP when downloading multiple resources over one connection.

Multicast

UDP supports one-to-many communication that TCP fundamentally cannot. Service discovery protocols use UDP multicast to let devices announce their presence to all listeners on a local network. One packet reaches multiple recipients efficiently.

IPTV systems use UDP multicast to send one video stream that multiple receivers can join. This scales far better than establishing separate TCP connections to each viewer.

The Core Insight

UDP excels when:

• Timing matters more than completeness — real-time communications, gaming, live streaming
• The exchange is simple — DNS, NTP, DHCP
• You need custom reliability — QUIC, game protocols, data center applications
• You need one-to-many — multicast, service discovery

Reliability can be implemented in the application layer when needed. TCP's latency and overhead cannot be removed. Choose UDP when your application handles packet loss better than it handles delay.