What’s the difference between TCP and UDP, and when would you choose each?
TCP is connection-oriented and guarantees delivery, ordering, and error-checked reassembly, at the cost of overhead: a handshake to establish the connection, acknowledgments for every segment, and retransmission of anything lost. UDP is connectionless and gives no such guarantees, it just sends packets (datagrams) and moves on, with no handshake, no acknowledgment, and no automatic retransmission.
When to choose which
Choose TCP whenever correctness and completeness matter more than raw speed: web traffic (HTTP), file transfer, database connections, anything where a missing or out-of-order byte would corrupt the result. Choose UDP when low latency matters more than guaranteed delivery, and the application can tolerate or work around loss: live video/audio streaming (a dropped frame is fine, a frozen stream waiting for retransmission is worse), DNS lookups (small, simple, retry at the application level if needed), and real-time multiplayer games (a stale position update is worse than a missing one).
Best practice
Don’t assume UDP means “no reliability at all is possible,” it means reliability isn’t handled by the transport layer, so if you need some reliability with UDP’s low latency, you build it at the application layer (as protocols like QUIC do, layering their own reliability and congestion control over a UDP-like foundation to get more control than TCP’s built-in behavior allows).
Edge case interviewers probe for
Ask why a video call uses UDP despite seeming like it needs “reliable” delivery. The key insight: for real-time media, an old, late-arriving retransmitted packet is actively worse than just dropping that frame and moving on, since audio/video needs to stay in sync with real time, not be perfectly complete.
Common mistake
Saying “UDP is just worse/less reliable TCP” without recognizing that dropping guarantees is a deliberate design tradeoff for latency-sensitive use cases, not a limitation to work around.
What the interviewer is checking
Whether you understand the guarantees each protocol actually provides and can match them to real application requirements, rather than treating one as strictly better than the other.
TCP is like sending a package with tracking, signature required, and a guarantee that if anything’s missing, the sender will resend it, you’ll definitely get everything, in order, eventually, even if it takes a bit longer. UDP is like shouting a message across a noisy room: it’s fast and you don’t wait for confirmation, but if someone didn’t hear part of it, nobody automatically repeats it, that’s on you to notice and ask again if it actually mattered.
For a video call, shouting (UDP) makes sense: if you missed one word a half-second ago, you don’t want the whole conversation to pause while it gets repeated, you just keep going, a little garbled is better than frozen. For downloading a contract you need to sign, tracked delivery (TCP) makes sense: you absolutely need every single page, in the right order, even if it takes a few extra seconds.
Why interviewers ask this
It’s foundational networking knowledge that reveals whether a candidate thinks about protocol choice as a deliberate tradeoff rather than “TCP is always the safe/better choice.”
What a strong answer signals
That you match transport protocol guarantees to actual application needs, and understand why dropping reliability is sometimes the right design choice.
Common follow-ups
- What is the TCP three-way handshake?
- How does QUIC combine ideas from both?
- What’s TCP head-of-line blocking and why does it matter?
Advanced variation
“Why did HTTP/3 move to QUIC over UDP instead of staying on TCP,” which expects discussion of head-of-line blocking in TCP and how QUIC solves it while keeping meaningful reliability.
A video conferencing product initially used TCP for its media stream to guarantee “no lost frames,” but users experienced noticeable freezing and lag during any packet loss, since TCP would pause the entire stream waiting to retransmit and reorder a single lost segment before delivering anything after it. Switching the media stream to UDP with an application-level scheme that simply skips a lost frame and continues (accepting occasional visual glitches over freezing) produced a noticeably smoother real-time experience, while keeping TCP for the call’s signaling and chat messages, where completeness genuinely mattered.
- 1TCP guarantees ordered, reliable delivery via a handshake and acknowledgments; UDP guarantees neither.
- 2Choose TCP when completeness matters more than speed: web traffic, file transfer, databases.
- 3Choose UDP when low latency matters more than guaranteed delivery: live video, DNS, real-time gaming.
- 4UDP’s lack of reliability is a deliberate tradeoff, not a limitation, applications can add their own reliability on top if needed.
- 5Protocols like QUIC build meaningful reliability over UDP specifically to avoid TCP’s head-of-line blocking.