Skip to content
diff/reel
Start drawing
Start drawing
All reels
Networking

TCP vs UDP

TCP vs UDP — opening frame

sandboxed iframe · 45s loop · 26 KB

Made with Diffreel — draw your own →

One protocol asks whether every piece arrived. The other never asks.

By · Posted Aug 15, 2026 · 6 views

The cut is simple: does anything come back?

TCP acknowledges every segment. A lost segment is noticed and re-sent, so nothing is missing — but the replacement arrives late, and everything behind it waits. Traffic is bidirectional and the rhythm is call-and-response.

UDP sends datagrams one way and nothing reacts. A lost one is simply gone: no acknowledgement, no retransmit, no waiting. The rhythm is a steady one-way stream with a hole in it.

Neither is the better protocol. A file transfer cannot tolerate the hole; a live call cannot tolerate the wait.

#latency#protocols#reliability
Source

TCP vs UDP: which protocol asks whether the packet arrived

3 min read

TCP re-sends any piece of data whose arrival is never confirmed, while UDP sends each datagram once and never checks — so on TCP a lost packet arrives late, and on UDP it is simply gone. That is the difference between TCP and UDP in one sentence: both hand their packets to the same unreliable IP network, and only one of them listens for a reply. Everything else — ordering, retransmission, the reputation UDP has as "the unreliable one" — falls out of that single choice about whether anything comes back.

The reel's two scenes: sender, network, receiver, run twice.
The same three nodes in both protocols. In TCP, traffic runs both ways and a lost comet re-fires late; in UDP it runs one way and a lost comet is followed by nothing.

What TCP does

Every octet of data sent over a TCP connection carries a sequence number, so every octet can be acknowledged. When TCP transmits a segment it puts a copy on a retransmission queue and starts a timer. The receiver acknowledges cumulatively — an ACK of sequence number X means everything up to X arrived. When that ACK comes back the copy is deleted from the queue; if the timer expires first, the segment is retransmitted. The data arrives late, but it arrives. Traffic is therefore bidirectional at all times: data one way, acknowledgements the other, on the same connection. That returning stream of ACKs is the whole cost and the whole point.

What UDP does

UDP hands a datagram to IP and stops. There is no connection, no sequence number, and no retransmission queue. RFC 768 states the guarantee in its own words: "delivery and duplicate protection are not guaranteed." The specification describes no acknowledgement mechanism at all, because there is none. Nothing is sent back, so the sender is never told — and cannot be told — that a datagram was lost. A dropped datagram leaves a hole that nothing reacts to.

One correction the reel is careful about: UDP does not drop the packet. The network drops it; UDP merely declines to notice. That distinction is exactly what makes UDP correct for live audio and video, where a re-sent frame arriving 300 ms late is worse than a missing one.

Same lost packet, two protocols

  1. TCP sender

    keeps a copy of every segment on a retransmission queue, timer running

  2. Network

    drops the segment in flight

  3. TCP sender

    timer fires with no ACK — the same segment is re-sent, and arrives late

  4. UDP sender

    hands the datagram to IP: no queue, no timer, no sequence number

  5. Network

    drops the datagram in flight

  6. UDP receiver

    nothing arrives, nothing goes back — the loss is never noticed

TCP notices the gap and fills it; UDP has nothing listening, so the gap stays a gap.

Why UDP is faster — and why that framing misleads

People ask "why is UDP faster", and the honest answer is that it does none of TCP's work: no handshake before the first byte, no waiting on ACKs, no retransmission, and no holding later data back until earlier data catches up. Fewer round trips, less waiting, a smaller header. But "faster" hides the trade — UDP is faster the way not checking your work is faster.

The clearest example of what TCP pays for that speed is head-of-line blocking: because TCP delivers bytes strictly in order, a single lost segment stalls everything queued behind it, even data that already arrived, until the retransmission lands. UDP has no such rule, so nothing waits on the missing piece — which is precisely why real-time media rides on it and file transfers do not.

When to use UDP instead of TCP

The rule of thumb for when to use UDP instead of TCP is: choose UDP when a late packet is worse than a lost one, and TCP when a lost packet is unacceptable at any price. Live voice, video, and gaming tolerate the occasional hole but cannot tolerate a 300 ms stall waiting on a re-send — UDP. Files, payments, HTML, anything where every byte must arrive intact and in order — TCP, and let it retransmit. If you need reliability and UDP's freedom from head-of-line blocking, that is what QUIC is: an ordered, retried stream built on top of UDP, keeping the datagram base and rebuilding the guarantees per-stream above it.

TCP vs UDP in a system design interview

An interviewer is rarely asking you to recite header layouts. They are probing whether you can match a delivery guarantee to a failure mode. The crisp answer: TCP gives you reliable, ordered delivery by acknowledging and re-sending; UDP gives you unordered, best-effort delivery with no acknowledgement — so the design question is whether your workload can absorb loss or must eliminate it. Strong follow-ups to have ready: name head-of-line blocking as TCP's cost and the reason QUIC exists; note that "unreliable" is a formal term meaning delivery is not confirmed, not low quality; and point out that UDP does not lose your packet — the network does, and UDP simply has no machinery to react. Saying "UDP for speed" alone is the weak answer; the strong one names which guarantee you are trading away and why the workload can survive it.

Sources

Related reels