UDP is preferred over TCP whenever speed and low overhead matter more than guaranteed delivery. This includes real-time applications like online gaming, live video streaming, voice calls, DNS lookups, and IoT devices. The core tradeoff is simple: TCP ensures every packet arrives in order, but that reliability costs time. UDP skips those safeguards and gets data moving immediately, which makes it the better choice in several common scenarios.
Why UDP Is Faster Than TCP
The speed difference comes down to two things: smaller packets and no setup time. A UDP packet header is just 8 bytes, compared to TCP’s minimum of 20 bytes (and up to 60 bytes with options enabled). That might sound trivial, but when you’re sending thousands of small messages per second, the savings add up fast.
More importantly, TCP requires a three-way handshake before any data can flow. The client sends a synchronization request, the server acknowledges it and sends its own, and the client confirms. Only then does actual data transmission begin. That exchange adds a full round trip of latency before a single byte of useful information moves. UDP skips all of this. It just starts sending.
TCP also introduces ongoing overhead during communication. It tracks packet order, waits for acknowledgments, retransmits lost packets, and manages flow control to avoid congestion. Each of these mechanisms adds processing time and extra packets on the wire. UDP does none of it, which means lower latency and less network traffic at the cost of no delivery guarantees.
Real-Time Gaming and VR
Fast-paced multiplayer games are one of the clearest cases for UDP. Latencies above 200 milliseconds noticeably degrade the quality of interactive games, and for VR and AR applications the threshold drops to just 20 milliseconds. At those margins, TCP’s handshake, acknowledgment cycles, and retransmission delays are unacceptable.
In a shooter or racing game, your position updates dozens of times per second. If one of those updates is lost, it’s better to just use the next one than to pause everything while TCP retransmits the old packet. By the time a retransmitted position arrives, it’s already outdated. UDP lets the game engine decide what to do with missing data (usually interpolation or prediction) rather than forcing a wait. Excessive latency also breaks the sense of cause and effect in gameplay, and in VR specifically, sensory inputs arriving out of order can cause motion sickness.
Voice and Video Calls
Voice over IP (VoIP) and video conferencing use UDP for the same reason games do: a slightly degraded stream is better than a delayed one. When you’re on a video call, a dropped frame causes a brief glitch. A retransmitted frame that arrives late causes the entire stream to stutter or buffer. Your brain can fill in a missing syllable of speech far more easily than it can handle a half-second freeze followed by a burst of catch-up audio.
Live streaming platforms face the same calculus. Protocols built on UDP prioritize keeping the stream moving in real time. TCP-based streaming works fine for on-demand video where buffering ahead is possible, but for live broadcasts where every millisecond of delay separates viewers from the actual event, UDP-based delivery is standard.
DNS and Small Network Queries
The Domain Name System, which translates website names into IP addresses, defaults to UDP for a practical reason: most DNS queries and responses are tiny. The traditional size limit for a DNS message over UDP is 512 bytes. Extensions to the protocol (EDNS) allow larger responses, but the vast majority of lookups fit comfortably within that limit.
For a query that small, TCP’s three-way handshake would take longer than the actual data exchange. You’d spend three packets just setting up the connection, then send one packet of real data, then tear down the connection. UDP sends the query in one packet and gets the response in one packet. DNS only falls back to TCP when a response is too large for UDP, which happens with certain record types or DNSSEC-signed responses that exceed the size limit.
Broadcasting and Multicasting
TCP is a one-to-one protocol. It establishes a dedicated connection between two endpoints, which means it cannot natively send the same data to multiple recipients at once. UDP supports both broadcasting (sending to every device on a network) and multicasting (sending to a specific group of devices). This makes UDP essential for tasks like network service discovery, where a device needs to announce its presence to everything on the local network, or for distributing the same live video feed to thousands of viewers simultaneously without maintaining a separate connection to each one.
IoT and Constrained Devices
Internet of Things devices like sensors, smart home hardware, and industrial monitors often run on batteries with limited processing power and minimal bandwidth. TCP’s overhead is a real problem in that environment. Maintaining a persistent connection, managing retransmissions, and processing larger headers all drain power and consume resources that these devices don’t have to spare.
CoAP, a protocol designed specifically for constrained IoT devices, runs on top of UDP rather than TCP. Compared to TCP-based alternatives like MQTT, CoAP is better suited for battery-powered devices with limited resources. It uses a lightweight security layer (DTLS) instead of the heavier TLS encryption that TCP-based protocols rely on. For a sensor that wakes up every few minutes, sends a small temperature reading, and goes back to sleep, the efficiency difference between a UDP-based and TCP-based protocol can meaningfully extend battery life.
When TCP Is Still the Right Choice
UDP’s advantages disappear when reliable, ordered delivery actually matters. File transfers, emails, web page loads, database queries, and any situation where a missing or out-of-order packet corrupts the result all require TCP. If you’re downloading a software update, you need every single byte to arrive correctly. A missing packet in a file isn’t something you can interpolate around.
The decision comes down to a single question: what happens when a packet is lost? If the answer is “use the next one” or “it doesn’t matter,” UDP is likely the better fit. If the answer is “the whole thing breaks,” you need TCP. Many modern applications split the difference, using UDP for time-sensitive data like game state or audio while running a separate TCP connection for reliable tasks like login authentication or chat messages.