TCP vs UDP

1The core idea#

Both are transport protocols sitting on top of IP, which only knows how to shove a packet toward an address and hope. IP never promises a packet arrives, arrives once, or arrives in order. TCP and UDP are two different answers to: given that foundation, what guarantees do I want?

The mental model I give juniors.

• TCP is a phone call. You dial, the other side picks up, you both agree you are connected, then you talk back and forth. Miss a word? "Sorry, say that again." Hang up and you both know the call is over. Order holds because you speak in sequence.
• UDP is dropping postcards in a mailbox. Write an address, drop it, walk away. No handshake, no confirmation, no idea if it arrived. Fire off a hundred a second and the post office never makes you wait. Some get lost. Some arrive out of order. That is the deal you took.

The one-line definitions everything else follows from:

• TCP: a reliable, ordered, connection-based byte stream.
• UDP: a thin, best-effort wrapper around a single packet, called a datagram.

2How it works#

The big mechanical split is the connection. TCP sets one up before any real data moves. UDP does not.

TCP opens with the three-way handshake.

• Client sends SYN, server replies SYN-ACK, client sends ACK.
• Both sides now agree on starting sequence numbers and the connection is open.
• That costs a full round trip before a single byte of payload moves.
• Concretely: 50 ms one way means the handshake eats 100 ms before your first real byte starts moving.
• Layer TLS 1.2 on top and you pay roughly two more round trips, about 300 ms total just to say hello.

Once open, TCP does the heavy lifting you usually take for granted:

• Sequencing. Every byte has a number. The receiver reassembles them in order even if packets arrive scrambled.
• Acknowledgement and retransmit. The sender holds data until the receiver confirms it. No ACK in time? Resend.
• Flow control. The receiver advertises a window telling the sender how much it can buffer, so a fast sender does not drown a slow receiver.
• Congestion control. TCP watches for loss, slows down when the network looks congested, then ramps back up. This is why one TCP connection shares a link politely with others.

UDP does almost none of that. A send is basically: wrap your bytes in an 8-byte header (source port, destination port, length, checksum) and hand it to IP. Done.

• No handshake, no sequence numbers, no retransmit, no congestion control.
• Need any of that? You build it yourself on top.
• That minimalism is the point: UDP's header is 8 bytes, TCP's is 20 bytes minimum and usually more with options.
• More importantly, UDP has no state to set up or tear down, so there is no round-trip tax before you send.

3A worked example: the same 100 ms blip, two very different outcomes#

Numbers make this real, so walk one scenario through both protocols. A link with 50 ms one-way delay (100 ms round trip) and 1% packet loss, a normal mobile connection on a bad day. You send 100 packets in a burst.

Over TCP.

• On average 1 of the 100 is lost. Say it is packet 5.
• Packets 6 through 100 arrive fine and sit in the receiver's kernel buffer, but the app cannot read any of them: there is a hole at position 5 and TCP delivers in order.
• The sender does not even notice until a timeout or duplicate ACKs, then retransmits packet 5, which takes one more round trip (100 ms) to land.
• During that 100 ms, 94 already-arrived packets are frozen behind the gap.
• One lost packet just stalled almost your entire burst. That is head-of-line blocking with a number on it.

Over UDP.

• Packet 5 is lost and nothing else cares.
• Packets 6 through 100 are handed to your app the instant they arrive.
• Your app sees 99 of 100 packets with zero added delay.
• Whether the missing one matters is now your call, not the protocol's: skip a live video frame, re-request a chess move.

Same link, same loss, same round trip: TCP froze 94 packets for 100 ms, UDP lost one and stalled nothing.

Neither is better. They are answers to different questions. This single example, told with these numbers, often carries a whole interview answer on its own.

4Trade-offs#

This is the part interviewers actually care about. What do you give up each way?

Two rows win interviews, so go deeper on them.

Head-of-line blocking (TCP's hidden tax, and the thing most juniors miss).

• Because TCP delivers an ordered stream, if packet 5 is lost, packets 6 through 20 may already be in the receiver's buffer but invisible to your app until 5 is retransmitted and arrives.
• Everything behind the gap waits.
• On a clean data center link with loss under 0.01% this rarely bites.
• On a lossy mobile connection it can turn a 40 ms blip into a 300 ms stall across the whole stream.
• UDP has no such problem: each datagram stands alone, lose one and the rest keep flowing.

Reliability is not free, and it is not always wanted.

• TCP's retransmits are great for a file download where every byte matters.
• They are actively harmful for a live voice call: a chunk of audio from 200 ms ago gets lost, you do not want it retransmitted and played late.
• You want to skip it and keep the conversation moving.
• That is the deep reason real-time media leans on UDP: a late packet is worse than a lost one.

The honest summary: TCP trades latency and control for correctness and simplicity in your application code. UDP trades those guarantees away so you can go fast and decide for yourself what reliability even means for your use case.

5Where it is used#

Rule of thumb I use: if losing data breaks correctness, reach for TCP. If losing data is a tiny glitch but delay is a bigger one, reach for UDP.

TCP shows up in:

• HTTP and HTTPS for the web: loading a page, a REST API, GraphQL. You cannot have half a JSON response.
• Database connections: Postgres, MySQL. Query results must arrive complete and in order.
• Email (SMTP), file transfer, SSH, Git over the wire. All correctness-critical.
• Most service-to-service calls inside a backend.

UDP shows up in:

• DNS lookups. Query and response each fit one small packet, and a loss just means a retry. A TCP connection per name resolution would be wasteful.
• Voice and video calls, live streaming with WebRTC. Glitch over delay, every time.
• Online games. Player positions update 30 to 60 times a second. A lost position packet is irrelevant because a fresher one is 16 ms behind it.
• Metrics and logs fired in high volume, the classic statsd pattern, where dropping a sample is fine.

The modern twist: QUIC.

• Runs over UDP but rebuilds reliability, ordering, and encryption in user space. HTTP/3 uses it.
• It fixes TCP's head-of-line blocking by giving each request its own independent stream, so a loss on one does not stall the others.
• It also sidesteps the kernel: TCP lives in OS kernels and is slow to evolve, so building on UDP let them ship fixes in user space.

6Common pitfalls and gotchas#

"UDP is faster, so I'll use it everywhere."

• No. UDP skips work, it does not have a magic fast network.
• Bolt your own acks and retransmits onto UDP because you actually needed reliability, and you have reinvented a worse TCP.
• Only choose UDP when you genuinely do not want some of TCP's guarantees.

Forgetting that TCP is a stream, not messages.

• TCP does not preserve message boundaries. Send "HELLO" then "WORLD" and the receiver might read "HELLOWORLD", or "HEL" then "LOWORLD".
• You frame messages yourself, usually with a length prefix or a delimiter.
• UDP preserves boundaries: one send is one datagram is one receive.

Ignoring packet size with UDP.

• If a datagram exceeds the network's MTU (commonly around 1500 bytes) it fragments, and losing any fragment loses the whole datagram.
• Keep UDP payloads under roughly 1400 bytes to avoid a class of weird intermittent failures.

Assuming the handshake cost does not matter.

• For a long-lived connection the one-time handshake is noise.
• For a workload that opens a fresh connection per request, that round trip plus TLS can double your latency.
• Picture an API doing 10 ms of real work but opening a new TCP plus TLS connection each time on a 50 ms link: about 300 ms of setup dwarfs the 10 ms of work, a 30x tax.
• This is exactly why connection pooling and keep-alive exist. Naming that shows you know the cost is real but amortizable.

Thinking UDP has zero reliability tooling.

• None built in, but the ecosystem on top (WebRTC, QUIC, game netcode libraries) adds selective reliability.
• You choose which messages must arrive and which can drop. That control is the actual value.

7How it shows up in interviews#

Interviewers rarely ask "define TCP" on its own. It comes up embedded in a design: "design a video chat," "design a multiplayer game," "design a DNS service," "why is your API slow on mobile." They want to see if you reach for the right transport and can justify it.

Candidate (weak): TCP is reliable and UDP is fast, so I'll use UDP for the game.

That is a memorized fact with the right conclusion and no reasoning. I cannot tell if you got lucky or actually know why. In a real loop it reads as a pass-fail flag, not a strong signal.

Candidate (strong): For the game, player position updates go out 30 times a second, so a fresh one is 33 ms behind the last and each one supersedes the previous. A dropped packet is irrelevant because the next update is already on its way. TCP would retransmit that stale position a full round trip later, and head-of-line blocking could stall newer updates behind it, the opposite of what I want. So I'd use UDP for position state and add my own lightweight acks only for events that must land, like "player fired" or "player died." Chat and login still go over TCP because those need to be exact.

Why the strong answer lands:

• Names the data and its rate (positions, 30/s).
• Puts a number on why loss is acceptable (33 ms to the next update).
• Calls out head-of-line blocking by name.
• Shows selective reliability (acks only for must-land events).
• Recognizes one system uses both protocols for different traffic, which is how real systems work. That last point separates mid-level from senior.

Want to see this applied end to end? Try the System Design Question walkthrough on designing a real-time multiplayer game, where the TCP vs UDP decision drives the entire networking layer.