UDP vs TCP

Choosing UDP over TCP is a deliberate trade-off, not a downgrade, and interviewers use this question to check whether you understand when reliability guarantees are worth their latency cost. The rise of QUIC (HTTP/3's transport, built on UDP) has made this distinction newly relevant even for engineers who never touch raw sockets.

What Is UDP?

UDP (User Datagram Protocol) is a way of sending data over a network with no setup, no delivery guarantee, and no ordering — you just fire the data off and hope it arrives. There's no handshake before sending and no automatic retry if a piece goes missing, which makes it fast and lightweight, but it means the app itself has to handle any loss it cares about.

What Is TCP?

TCP (Transmission Control Protocol) is the more careful alternative: before sending data, both sides confirm the connection is open, and every piece of data is numbered so the receiver can detect anything missing and ask for it again. That reliability costs a bit of extra setup time and overhead, but it guarantees the data arrives complete and in the right order.

Where This Is Used

• Video calls (Zoom, Google Meet) and live streaming use UDP-based protocols because a dropped frame that gets "fixed" a second late is worse than just skipping it.
• Online multiplayer games (like Fortnite or Call of Duty) use UDP so a slightly out-of-date position update doesn't get delayed behind a retransmission.
• DNS lookups (turning a website name into an IP address) typically use UDP because the request is small and speed matters more than perfect delivery guarantees.
• Loading a webpage, sending an email, or transferring a file all use TCP, because missing or garbled data is unacceptable.
• HTTP/3 and QUIC (used by Google, Meta, and increasingly the wider web) build TCP-like reliability on top of UDP to get both speed and correctness.

A Day-to-Day Example

TCP is like sending a certified letter: the mail carrier gets a signature confirming delivery, and if it doesn't arrive, the sender finds out and can resend it. UDP is like shouting an announcement across a crowded room: it's instant and reaches everyone nearby, but you have no way of knowing if any particular person actually heard it — and if they didn't, you don't automatically repeat yourself.

Deep Dive: Header Comparison — Where the Overhead Actually Comes From

UDP header (8 bytes, fixed):
| Source Port (16) | Dest Port (16) | Length (16) | Checksum (16) |

TCP header (20 bytes minimum, plus options):
| Source Port (16)      | Dest Port (16)        |
| Sequence Number (32)                           |
| Acknowledgment Number (32)                     |
| Data Offset | Flags (SYN/ACK/FIN/RST/...) | Window Size (16) |
| Checksum (16)          | Urgent Pointer (16)   |
| Options (variable, e.g. MSS, window scaling, SACK)            |

UDP's 8-byte header carries just enough to route a datagram to the right port and verify basic integrity — no sequence numbers, no ACK numbers, no connection state, no flags. TCP's 20+ byte header is where the machinery for ordering (sequence numbers), reliability (ACK numbers), and flow control (window size) actually lives. This is a direct, mechanical reason UDP has less per-packet overhead — but it's the missing handshake and retransmission logic, not just the smaller header, that accounts for most of the real-world latency difference.

Deep Dive: Why "UDP Is Just Faster" Is the Wrong Framing

The precise, interview-safe way to state this: UDP has less transport-layer overhead and skips TCP's connection setup and reliability machinery, but whether an application built on UDP is actually faster in practice depends on the application logic, current network conditions, the specific protocol layered on top, and its implementation. A few concrete counterexamples worth having ready:

• QUIC runs over UDP but reimplements reliability, ordering, and congestion control in user space — it isn't "faster because unreliable," it's faster because it avoids TCP's head-of-line blocking across multiplexed streams while still guaranteeing delivery.
• A naive UDP-based protocol with no retry logic can perform far worse than TCP on a lossy network, because a dropped packet is just gone — the application has to notice and recover, and a poorly written one might not.
• On a clean, low-latency local network, the TCP handshake cost is negligible, and TCP's reliability comes at almost no measurable overhead for most request sizes.

Key Pointers

• TCP is connection-oriented (handshake required) and reliable — guarantees in-order, lossless delivery via acknowledgments and retransmission.
• UDP is connectionless and unreliable — it fires datagrams with no handshake, no ordering guarantee, and no automatic retransmission.
• TCP has built-in flow control and congestion control; UDP has neither, leaving those concerns (if needed) entirely to the application.
• UDP's header overhead is minimal (8 bytes vs TCP's 20+ bytes), and it has no connection setup latency, making it a lighter-weight building block for small, latency-sensitive, or loss-tolerant payloads.
• DNS uses UDP for simple queries (fast, single round trip, retried by the application if lost) but falls back to TCP for large responses like zone transfers or responses that exceed a single UDP datagram.
• Voice/video calls and live streaming use UDP because a late-arriving packet is worse than a dropped one — retransmission would introduce more lag than just skipping the frame.
• QUIC (used by HTTP/3) is built on UDP but reimplements reliability and congestion control in user space, avoiding TCP's head-of-line blocking across multiplexed streams.

How It Works

1. TCP: client and server perform a 3-way handshake, then exchange data with sequence numbers, ACKs, and retransmission on loss, before a multi-step teardown.
2. UDP: the sender just addresses a datagram to a destination IP:port and sends it — no setup, no guarantee of arrival, no teardown.
3. If an application needs some reliability on top of UDP (e.g. game state sync, QUIC), it implements just the specific guarantees it needs — sequence numbers, selective retransmission — rather than TCP's full reliability model.
4. The OS delivers UDP datagrams to whichever socket is bound to the matching local port; there's no per-connection state to maintain on the receiving side.

Try It Yourself

# Watch a DNS query use UDP (and see it retry/fall back to TCP for large responses):
dig example.com                 # uses UDP by default
dig +tcp example.com            # force TCP, compare
dig +short CHAOS TXT version.bind @1.1.1.1   # small UDP round trip

# Compare handshake overhead directly: time a TCP connect vs a UDP send
time nc -zv example.com 443     # TCP: pays handshake cost
time nc -zvu 8.8.8.8 53         # UDP: no handshake, just fires the packet

# Capture UDP vs TCP traffic side by side:
sudo tcpdump -i any -nn 'udp port 53 or tcp port 443'

# Inspect a QUIC (HTTP/3, UDP-based) connection in the browser:
# DevTools -> Network tab -> Protocol column -> look for "h3"

Interview Q&A

Q: Why does YouTube/Netflix use TCP for the video itself despite the reliability overhead?

A: Because on-demand video is buffered — the player downloads ahead of playback, so TCP's retransmission latency is hidden inside that buffer and never affects what the viewer sees. Live, real-time voice/video (WebRTC calls) is different: there's no buffer to hide behind, so a retransmitted packet just adds visible lag, which is why real-time communication uses UDP-based protocols instead, accepting occasional glitches over added delay.

Q: Isn't UDP just "TCP but faster"? Why wouldn't everyone use it?

A: That framing is too simplistic. UDP is lighter-weight (no handshake, smaller header, no built-in reliability machinery), but "faster" depends entirely on what the application does with it. If your application needs ordering and guaranteed delivery, you either use TCP or you end up reimplementing a subset of TCP's reliability logic yourself on top of UDP (as QUIC does) — at which point you've traded TCP's proven implementation for your own, and you'd better have a good reason (like avoiding head-of-line blocking across independent streams).

Q: How does QUIC get TCP-like reliability while still using UDP?

A: QUIC implements its own sequencing, acknowledgment, retransmission, and congestion control entirely in user-space code running over plain UDP datagrams, rather than relying on the kernel's TCP stack. The key win isn't skipping reliability — it's that QUIC multiplexes multiple independent streams within one connection, so a lost packet only blocks the one stream it belongs to instead of stalling all streams the way a single TCP connection's head-of-line blocking would.

System Design Tie-in

In a "design a multiplayer game" or "design a live chat/video app" interview, the transport choice is a first-class design decision, not an implementation detail: game state updates (position, health) typically go over UDP because a stale update replaces the need for a dropped one to ever be retransmitted, while chat messages and matchmaking/auth calls go over TCP (or a reliable layer) because losing a message silently is unacceptable. In a "design a DNS-heavy or high-fan-out service," expect UDP's single-round-trip query cost to matter — batching or caching DNS lookups avoids paying repeated UDP round trips (or TCP fallback cost for oversized responses) on the hot path.

Trade-offs

TCP: reliable, ordered, congestion-aware — but pays for it with handshake latency, head-of-line blocking (one lost packet stalls all data behind it on that connection), and slow-start ramp-up. UDP: minimal latency and overhead, no head-of-line blocking — but zero delivery guarantees, so the application must handle loss, duplication, and reordering itself if it cares. A frequent interview gotcha: "why does YouTube/Netflix use TCP for the video itself despite the reliability overhead?" — because buffering hides TCP's retransmission latency for on-demand video, whereas live, real-time voice/video (WebRTC) genuinely needs UDP's low latency since there's no buffer to hide behind. Avoid the trap of saying "UDP is just faster" without qualification — the honest answer is that UDP has less overhead, and whether that translates into a faster application depends on what the application builds on top of it.