TCP vs UDP

A few kilobytes should not feel slow, and yet it does. The usual reason is not bandwidth and not the server — it is the handshakes and acknowledgements you are paying for and may not need. Both questions come down to the same fact — TCP buys you order and delivery, and the price it pays is waiting.

What the handshake buys you#

Before a TCP connection carries a single byte of your data, three packets cross the wire: SYN, SYN-ACK, ACK. That round trip is not overhead someone forgot to remove — it is both sides agreeing they can hear each other and settling on starting sequence numbers, so every byte that follows can be placed, counted and confirmed. Nothing is sent until that agreement exists.

An ACK after that point is a narrower promise than it sounds. It means the segment reached the kernel’s receive buffer on the other machine — not that your application has read it, and not that it processed it without error. TCP’s contract ends at the socket. Whether the byte actually did anything useful is a question TCP was never asked and cannot answer.

UDP skips all of it. There is no handshake, no agreed sequence, no socket-level buffer keeping score. A UDP send either leaves the machine or it does not, and the sender is not told either way — which is why the first data arrow in the UDP track above starts the instant you ask, while TCP’s first data arrow waits for three packets to finish.

What re-sending costs when you did not need it#

“Reliable” is usually read as a pure upside, and the cost it hides is head-of-line blocking. TCP must deliver bytes to your application in the order they were sent, so when one segment is lost, every segment that arrived after it — correctly, already sitting in the receive buffer — is held back too. Nothing downstream of the gap moves until the missing piece is resent and arrives. One lost packet stalls the whole stream, not just the byte that went missing.

That resend is automatic and invisible to your code, which is different from a retry your own application decides to issue at the request level. When the network loses a request instead of a packet, the retry is the client’s only option — this article covers what the server owes a request it is seeing for the second time.

UDP has none of this bookkeeping to fall back on. A lost UDP packet is simply gone; nothing behind it waits, and nothing resends it unless your application decides to. That absence is a cost when you needed the data — and free when you did not.

Picking one on purpose#

The trade sits in one place: TCP pays with a handshake up front and a stall whenever a segment is lost, in exchange for never handing your application a gap or an out-of-order byte. UDP pays nothing up front and stalls for nothing, in exchange for making loss and ordering entirely your problem. Neither is the safe default — each is the wrong guarantee to buy for the other one’s workload.

The case that shows it clearest is a live video or game feed carried over TCP. One dropped packet stalls the stream while TCP waits for the resend, so the viewer sees a freeze — and then, when the resend finally lands, a burst of frames arrive all at once, each one older than the moment the viewer is now watching. The resend did its job and delivered the missing data intact. By the time it arrived, that data was worthless: the game had moved on, the video had a newer frame ready, and nobody downstream wanted the stale one anymore. Reliability was the wrong guarantee to buy — the feed needed the freshest packet, not every packet.

This one choice is a small piece of a larger subject: the distributed-systems path is aimed at what the network does to the assumptions you bring to it.