When to Use UDP Over TCP

TCP assumes your problem is that data might not arrive. It builds elaborate machinery to prevent this: acknowledgments, retransmissions, ordering guarantees. The protocol will move heaven and earth to ensure your packet arrives.

But what if you no longer want that packet?

In real-time applications, a packet that arrives late is worse than a packet that never arrives. TCP will helpfully retransmit it anyway, then make you wait for it. The protocol designed to ensure delivery becomes the reason your video call stutters.

Real-Time Communications

Voice calls make the paradox visceral. 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 insisted on retransmitting it? Now you have awkward delays and people talking over each other.

TCP's guarantee has become a liability.

UDP lets applications implement their own recovery strategies. Modern audio codecs interpolate missing samples. Video codecs skip corrupted 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.

When packets are lost, video conferencing applications reduce quality rather than waiting for retransmissions. Latency stays low. The conversation stays interactive.

Gaming

Online gaming demands the lowest possible 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 anyway. But "player fired weapon"? That needs acknowledgment and potential retransmission—which the game implements in its application layer, tailored to gaming semantics rather than TCP's one-size-fits-all approach.

Movement updates: unreliable and frequent. Inventory changes: reliable but infrequent. The game decides what matters. 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.

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 while waiting.

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.

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 Choice

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.