TCP vs UDP: What's the Difference?
TCP and UDP are both ways to send bytes across a network, but "TCP is reliable, UDP isn't" undersells the actual tradeoff — UDP isn't a worse TCP, it's a deliberate bet that a late packet is worse than a lost one.
The quick answer
| TCP | UDP | |
|---|---|---|
| Connection | Established via a 3-way handshake first | Connectionless — just send |
| Ordering | Guaranteed | Not guaranteed |
| Reliability | Lost packets are retransmitted | Best-effort, no retransmission |
| Congestion control | Built in, backs off under loss | None |
| Header overhead | Larger | Minimal |
| Typical use | Web pages, APIs, file transfer | Video calls, DNS, HTTP/3 (QUIC) |
What TCP actually does to earn "reliable"
TCP opens every connection with a three-way handshake (SYN, SYN-ACK, ACK) before a single byte of real data moves, which is real latency spent up front in exchange for a guarantee. Every segment gets a sequence number, the receiver acknowledges what it got, and anything unacknowledged within a timeout gets retransmitted — so data arrives complete and in order, or the connection reports a failure. TCP also runs congestion control, backing off its send rate when it detects loss, so it behaves cooperatively on a shared network instead of hammering it.
What UDP does instead: almost nothing, on purpose
UDP has no handshake, no sequence numbers, no acknowledgments, no retransmission, and no congestion control. A sender just fires packets; if one is dropped, nobody notices at the transport layer — it's simply gone. This sounds like a strictly worse protocol until you consider what it buys: near-zero setup latency (no handshake to wait on) and a much smaller header, which matters when you're sending many small, time-sensitive packets.
The real question: is a late packet worse than a lost one?
This is the actual decision, and it's the reason UDP exists at all. For a video call, a frame that arrives 400ms late is useless — the moment it was meant to represent has already passed, and TCP-style "wait and retransmit" logic would just add growing delay for stale data nobody wants. Dropping that frame and moving on to the next one, which is exactly what UDP-based protocols do, produces a better user experience than perfect, ordered, retransmitted delivery. The same logic applies to live audio, to gaming, and to DNS — a UDP-based DNS query that gets no response can just be reissued immediately, which is often faster than waiting for TCP's own retransmission timers.
Why HTTP/3 picked UDP
Modern HTTP/3 is built on QUIC, which runs over UDP rather than TCP — deliberately. TCP's ordering guarantee has a side effect called head-of-line blocking: if one packet is lost, everything behind it in the stream has to wait for the retransmit before the application sees any of it, even data for a completely unrelated request multiplexed on the same connection. QUIC implements its own reliability and ordering on top of UDP, but per-stream instead of per-connection, so one lost packet only blocks the stream it belongs to. It's a case of taking UDP's minimal transport and rebuilding just the pieces of TCP's guarantees that are actually needed, without the parts that hurt.
Why this matters in an interview
Naming "TCP" or "UDP" alone is a weak answer. The stronger one names why the specific workload tolerates loss or doesn't: a chat message needs guaranteed, ordered delivery (TCP), a live video stream tolerates a dropped frame far better than a delayed one (UDP), and a file upload absolutely cannot silently drop bytes (TCP). That reasoning — not the protocol name — is what the interview is actually testing.
Go deeper
The full lesson includes a sequence diagram comparing the TCP handshake against UDP's connectionless send, and goes deeper on where each protocol shows up in real systems:
👉 Read the full TCP vs UDP lesson — part of the free System Design Lab course.