Reliable delivery sounds like it should always win. For a live video call, it can be the thing that ruins the call.
Every transport protocol has to decide what to do when a packet goes missing — because on a real network, packets always eventually go missing. TCP (Transmission Control Protocol) answers that question by guaranteeing it will never happen invisibly: every byte is accounted for, retransmitted if lost, and delivered in the exact order it was sent. UDP (User Datagram Protocol)answers it by not guaranteeing anything at all — packets go out, and if one never arrives, UDP simply doesn't know and doesn't care. Framed like that, TCP sounds strictly better. It isn't. For an entire category of real-time applications — live video, voice calls, multiplayer games, DNS lookups — the thing TCP guarantees turns out to be less useful than the thing it costs to guarantee it, and engineers reach for UDP on purpose.
TCP is connection-oriented. Before either side sends a single byte of application data, TCP performs a three-way handshake(SYN, then SYN-ACK, then ACK) to establish a connection and agree on starting sequence numbers. From that point on, every segment sent is tracked, and the receiver acknowledges what it has received. If an acknowledgment doesn't come back within a timeout window, TCP assumes the segment was lost and automatically retransmits it — and because TCP guarantees strict ordering, any data that arrives out of sequence is held back and reassembled in order before it's ever handed to the application. All of that machinery is what makes TCP reliable. It's also exactly where the overhead comes from: handshake setup time before the first useful byte moves, acknowledgment traffic flowing constantly in the background, and — critically — unpredictable latency, because a single lost or delayed segment can stall delivery of every segment behind it until that one gap is resolved.
UDP is connectionless. There's no handshake — a datagram is simply sent, addressed to a destination, with no setup step and no prior agreement that anyone is listening. There's no acknowledgment, no automatic retransmission, and no guaranteed ordering: a datagram sent a moment later can legitimately arrive before one sent earlier, and UDP does absolutely nothing to fix that. If a datagram is lost in transit, UDP does not know and does not care — it's simply gone, unless the applicationsitting on top of UDP has been specifically written to detect and recover from that loss itself. Stripping out all of TCP's bookkeeping is precisely what makes UDP dramatically lower-latency and far more predictable in timing — there's nothing to wait for, because UDP never promised to wait for anything.
This is where the tradeoff stops being abstract. Live video/audio streaming, VoIP calls, online multiplayer gaming, and DNS lookups all share one property: a slightly stale or missing piece of data is far less harmful than the delay it would take to guarantee that piece arrives. A video call that briefly glitches because one frame never showed up is a minor, forgettable annoyance. A video call that freezes entirely while the network retransmits and reorders that same frame — which, by the time it finally arrives, is already too old to be useful — is the failure users actually notice. This is exactly why real-time media protocols deliberately build on UDP: they accept some packet loss on purpose, because the alternative isn't "no loss," it's "the same loss, plus a stall, plus stale data delivered late."
TCP's reliability and UDP's low latency aren't independent features you could somehow have both of at once — they're opposite answers to the same unavoidable question: what happens when a packet doesn't arrive? TCP's answer is "wait for it, and hold everything after it until it's confirmed," which is exactly what makes it reliable and exactly what makes its latency unpredictable. UDP's answer is "don't wait for anything, ever," which is exactly what makes it lossy and exactly what makes its latency low and consistent. For a file transfer or a database query, TCP's answer is obviously correct — every byte matters and nothing is useful out of order. For a live video call, VoIP, a multiplayer game's position updates, or a DNS lookup, the data has a shelf life measured in milliseconds. By the time a retransmitted, reordered packet would arrive, it usually isn't worth having anymore — so protocols built for those cases choose UDP specifically to guarantee they never stall waiting for data that's about to be stale anyway.
False, and it inverts the actual engineering tradeoff. UDP isn't a fallback for applications that "don't care" about reliability — it's a deliberate choice for applications where TCP's reliability guarantees would actively make things worse. Retransmission and strict ordering are exactly the mechanisms that introduce stalls, jitter, and the delivery of stale data long after it stopped being useful. Real-time media, online gaming, and DNS specifically choose UDP's low-latency, no-guarantee behavior because a dropped packet that lets the stream move on immediately is preferable to a "reliable" delivery that arrives late, out of order, and no longer relevant. This is a genuine architectural tradeoff between two different kinds of correctness — not UDP settling for less. Plenty of critical infrastructure runs on UDP precisely because TCP would be the wrong tool for the job, not a downgrade from the right one.
Explains the fundamental tradeoff between TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) — connection-oriented, reliable, ordered delivery versus connectionless, best-effort delivery — and why real-time applications like video calls, VoIP, gaming, and DNS deliberately choose UDP's lack of guarantees over TCP's reliability.
TCP is connection-oriented: before any application data moves, the two endpoints perform a three-way handshake (SYN, SYN-ACK, ACK) to establish the connection. Every segment sent afterward is acknowledged by the receiver, and if an acknowledgment doesn't arrive within a timeout window, TCP automatically retransmits the segment it assumes was lost. TCP also guarantees strict ordering — segments that arrive out of sequence are held and reassembled in order before being handed to the application. This reliability comes at a real cost: handshake setup time before the first useful byte, continuous acknowledgment overhead, and unpredictable latency, since a single lost or delayed segment can stall delivery of everything sent after it.
UDP sends datagrams directly, with no handshake, no acknowledgment, no automatic retransmission, and no guaranteed ordering — a datagram sent later can arrive before one sent earlier, and UDP does nothing to correct that. If a datagram is lost, UDP simply doesn't know; it's gone unless the application on top of UDP implements its own recovery logic. Removing TCP's bookkeeping is exactly what makes UDP lower-latency and far more predictable in timing — there is nothing to wait for, because UDP never promises anything to wait for.
For live video/audio streaming, VoIP calls, online multiplayer gaming, and DNS lookups, a slightly lost or dropped packet is usually far less harmful than the delay TCP's retransmission-and-reordering would introduce. A video call that glitches briefly from one dropped frame is a minor annoyance; a video call that freezes while TCP retransmits and reorders a now-stale frame — one that arrives too late to matter — is the failure users actually notice. This is exactly why real-time media protocols are deliberately built on UDP rather than TCP: accepting some packet loss beats guaranteeing delivery of data that will already be obsolete by the time it arrives.
TCP and UDP are not "reliable" and "unreliable" versions of the same protocol — they are two different answers to what should happen when a packet goes missing, and each answer is correct for a different class of application. File transfers, database queries, web page loads, and email all choose TCP because every byte matters and nothing is useful out of order. Real-time media, gaming, and DNS choose UDP because the data has a short shelf life and stalling to guarantee its arrival is worse than occasionally losing it. Choosing UDP is an architectural decision, not a compromise.
The sender doesn't receive an acknowledgment for that segment within its timeout window, assumes it was lost, and retransmits it. Because TCP guarantees strict ordering, any segments sent after the lost one are held by the receiver — even if they already arrived — until the missing segment is recovered and everything can be delivered to the application in the correct order.
Because for certain applications, TCP's guarantee is worse than no guarantee at all. Real-time video, VoIP, gaming, and DNS deal with data that becomes useless if it's delayed even slightly — so the priority is never stalling, not guaranteeing every packet arrives. Applications that need some reliability on top of UDP (like some game-state protocols) build their own lightweight recovery logic tailored to what they actually need, instead of paying for TCP's full guarantee.
The handshake (SYN, SYN-ACK, ACK) lets both sides confirm the connection is live in both directions and agree on initial sequence numbers, which is what makes reliable, ordered delivery possible in the first place. It's a one-time cost at connection setup — roughly 1.5 round trips — before any application data can be sent.
On a live call, a video frame represents a specific moment in time. By the time TCP detects the loss, waits for a timeout, and retransmits the frame, that moment has already passed — the frame arrives too late to be useful, and everything recorded after it has been sitting queued, waiting for it, the whole time. Skipping the lost frame and continuing with the next one produces a brief, forgettable glitch instead of a multi-frame freeze.
A DNS query and response are small and need to complete fast — paying for a TCP handshake before every lookup would roughly double the round trips needed for something that usually fits in a single request/response pair. If a UDP-based DNS query is lost, the resolver simply retries the whole request, which is cheap and simple; DNS does fall back to TCP for larger responses that don't fit in a single UDP datagram.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.