TCP vs UDP

TCP and UDP are the two dominant Layer 4 (Transport) protocols in the OSI Model — both sit directly on top of IP and both exist to get data from one process to another, but they make opposite bets on the same underlying tradeoff: how much reliability are you willing to pay for in latency and overhead?

TCP: reliable, ordered, connection-oriented

TCP (Transmission Control Protocol) guarantees that data arrives complete, in order, and without duplication — or the sender finds out it didn't. It does this through a three-way handshake to establish a connection before any application data flows, sequence numbers to detect loss and reordering, acknowledgments and retransmission for anything lost, and congestion control to back off when the network is overloaded.

UDP: fast, connectionless, best-effort

UDP (User Datagram Protocol) sends a datagram and moves on — no handshake, no acknowledgment, no retransmission, no guaranteed ordering. If a packet is lost, UDP doesn't know and doesn't care; that's left entirely to the application, if it cares at all. In exchange for dropping all those guarantees, UDP has near-zero setup latency and a much smaller header, since it isn't carrying the bookkeeping TCP needs to make its promises.

System Design Lab

Head-to-head

	TCP	UDP
Connection setup	Three-way handshake required	None — just send
Ordering	Guaranteed	Not guaranteed
Reliability	Guaranteed (retransmits lost data)	Best-effort — loss is possible and silent
Congestion control	Built in	None (application's responsibility)
Header overhead	Larger (~20 bytes)	Smaller (~8 bytes)
Typical use cases	Web traffic, APIs, file transfer, email	Video/voice calls, live streaming, gaming, DNS queries, QUIC/HTTP/3

Why anyone chooses UDP at all

It sounds like TCP is strictly better — until you consider workloads where a late packet is worse than a lost one. In a live video call, a video frame that arrives after its moment has passed is useless; retransmitting it and waiting would just add visible lag, whereas dropping it and moving on to the next frame keeps the call feeling live. Reliability isn't free: TCP's retransmission and strict-ordering guarantees mean a single lost packet stalls delivery of everything after it, even data the application could otherwise use immediately. That's the exact head-of-line-blocking problem discussed in HTTP/HTTPS, and it's the reason HTTP/3 rebuilt its transport on QUIC (UDP-based, with reliability handled per-stream in user space) instead of TCP.

The other common case is workloads that just need speed and can tolerate occasional loss at the application level: DNS queries use UDP because a lookup is small, latency-sensitive, and easy to just retry if it fails; a queried record either comes back or the client asks again, so TCP's connection setup cost isn't worth paying on every lookup.

Why this matters in an interview

The strongest way to bring this up isn't reciting the comparison table — it's naming why a specific workload in your design tolerates loss or doesn't. "This is a live video feed, so we'd use UDP and accept occasional frame loss rather than stall the stream waiting for a retransmit" is a much more convincing sentence than "video uses UDP." Conversely, for anything involving money, inventory counts, or state that must be exactly correct, TCP's guarantees are almost always worth the overhead — silent data loss is rarely an acceptable tradeoff there.

Choosing UDP over TCP: pros and cons

Pros

• ✓No handshake — lower connection setup latency, especially valuable for many short-lived exchanges
• ✓A single lost datagram doesn't stall delivery of everything after it
• ✓Smaller header and no congestion-control bookkeeping, so less overhead per packet

Cons

• ✕No delivery guarantee — data can be lost silently unless the application handles it
• ✕No ordering guarantee — packets can arrive out of sequence
• ✕Any reliability the application actually needs has to be built by hand on top

Further Reading

• RFC 793 — Transmission Control Protocol — the original TCP specification, including the handshake and retransmission mechanics.
• RFC 768 — User Datagram Protocol — the entire UDP spec, notably one of the shortest RFCs in wide use, which itself says something about how little UDP does.