TCP vs UDP
In one line
TCP delivers every byte reliably and in order at the cost of extra round trips; UDP just sends packets fast and leaves reliability to the application.
What it is
TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two main transport-layer protocols. Both carry data between programs on different machines using port numbers, but they make opposite promises.
TCP is connection-oriented: the two sides set up a connection first, then TCP guarantees that bytes arrive complete, in order and without duplicates, and it slows down when the network is congested. UDP is connectionless: each datagram is sent on its own, with no handshake, no retransmission and no ordering, so it is lighter and has lower latency.
Why interviewers ask
Interviewers use this to check whether you understand what the network actually guarantees and what it costs. Strong candidates connect the choice to the product: a payment API needs correctness, a video call needs low latency, and many modern protocols (like QUIC under HTTP/3) build their own reliability on top of UDP.
How it works
- 1TCP opens a connection with a three-way handshake: the client sends SYN, the server replies SYN-ACK, the client sends ACK. Only then does data flow, so a new connection costs one extra round trip.
- 2TCP numbers every byte. The receiver acknowledges what it got; anything not acknowledged in time is retransmitted, and out-of-order segments are held until the gaps are filled.
- 3Flow control (the receive window) stops a fast sender from overwhelming a slow receiver; congestion control (slow start, then backing off on loss) stops senders from overwhelming the network.
- 4UDP skips all of this: an application hands a datagram to UDP, it gets an 8-byte header with ports, length and checksum, and it is sent. Lost or reordered datagrams are simply lost or reordered.
- 5Because UDP adds almost nothing, applications that need some reliability (retries, ordering for a few messages, forward error correction) implement exactly the parts they need on top.
Worked example · One lost packet in a video call vs a file download
- A file download over TCP loses segment 5 of 10. TCP keeps segments 6 to 10 in a buffer, retransmits 5, and only then hands bytes 5 to 10 to the application: the file is correct, just slightly delayed.
- A video call over UDP loses the packet carrying 20 ms of audio. Waiting for a retransmission would freeze the call for a round trip, so the app conceals the gap (repeats or smooths audio) and plays the next packet on time.
- Same loss, opposite right answer: the download must be exact, the call must be on time.
Picture it
TCP is a registered courier: every parcel is numbered, signed for and re-sent if lost, so it arrives complete but takes longer. UDP is dropping postcards in a mailbox: fast and cheap, most arrive, but if one goes missing nobody tells you.
Key patterns
Pick by what a late message is worth
When: Choosing a transport for a feature
How: If late data is still valuable (files, payments, chat), use TCP. If late data is worthless (live media, game positions), use UDP.
Reliability on top of UDP
When: You need low latency but some messages must not be lost
How: Add sequence numbers, acknowledgements and selective retries only for important messages, or use QUIC instead of building it yourself.
Connection reuse
When: Many short requests over TCP
How: Keep connections alive and pool them (HTTP keep-alive, database pools) so you pay the handshake once instead of per request.
Real-world use
Web, APIs and databases (TCP)
HTTP/1.1 and HTTP/2, database connections like PostgreSQL and MySQL, SSH and email all run over TCP because a single missing byte would corrupt the result.
Voice, video and games (UDP)
Zoom, WebRTC calls and online games such as multiplayer shooters send frequent small updates over UDP; a late update is useless, so they skip retransmission.
DNS (mostly UDP)
A DNS lookup is one small question and one small answer, so UDP avoids a handshake; DNS falls back to TCP for large responses and zone transfers.
HTTP/3 and QUIC (UDP with its own reliability)
QUIC runs over UDP and rebuilds reliability per stream, so one lost packet only delays its own stream instead of every request on the connection (no head-of-line blocking across streams), and it combines the transport and TLS handshakes.
In a project
You are building a live classroom app: a teacher's audio and video stream to 200 students, students send chat messages and submit quiz answers.
- Send audio and video over UDP (WebRTC) so a lost packet causes a tiny glitch instead of a frozen stream.
- Send chat messages and quiz answers over TCP (a WebSocket or HTTPS API) because every message and answer must arrive exactly once and in order.
- Add sequence numbers and a small jitter buffer on the media side so slightly late packets can still be played in order.
- Monitor packet loss and lower the video bitrate when loss rises, instead of letting quality collapse.
Impact: Students get smooth, real-time lessons even on weak mobile networks, while no chat message or quiz answer is ever lost or duplicated. Choosing per data type, not one protocol for everything, is what makes both work.
Trade-offs
Use it when
- TCP: correctness matters more than speed (files, APIs, payments, databases, chat)
- UDP: freshness matters more than completeness (live audio and video, games, telemetry)
- UDP: tiny request-response exchanges where a handshake would double the latency (DNS)
Avoid it when
- TCP for real-time media: retransmission and head-of-line blocking cause freezes
- UDP when you would end up rebuilding all of TCP's reliability yourself; use TCP or QUIC instead
- UDP across strict corporate firewalls that block it, unless you have a TCP fallback
Cost: TCP costs one extra round trip to connect (more with TLS on TCP) and retransmission delay on loss; UDP has no setup cost but loss handling is your job.
Common mistakes
- Saying UDP is 'unreliable so never used': DNS, video calls, games and HTTP/3 depend on it.
- Claiming TCP guarantees delivery no matter what: it guarantees order and integrity of what arrives, and reports an error if the connection breaks.
- Forgetting the handshake cost when explaining latency, especially for many short connections.
- Thinking TCP preserves message boundaries: it is a byte stream, so applications must frame their own messages.
- Choosing one protocol for a whole product instead of per type of data.
Interview questions
Quick revision
- TCP: connection, ordered, reliable, flow and congestion control, byte stream.
- UDP: connectionless, no ordering or retransmission, message-based, 8-byte header.
- Handshake: SYN, SYN-ACK, ACK (one extra round trip before data).
- TCP for correctness (web, APIs, DB, chat); UDP for freshness (media, games) and tiny lookups (DNS).
- Head-of-line blocking: one lost TCP segment stalls everything behind it.
- QUIC / HTTP/3 = reliability per stream on top of UDP + faster combined handshake.
- TCP is a byte stream: frame your own messages (length prefix or delimiter).
Check yourself
1. Which protocol would you choose to send live position updates in a multiplayer game?
2. What does TCP's three-way handshake establish?
3. Why can one lost packet slow down every request on an HTTP/2 connection?
4. Which statement about UDP is true?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.