TCP & UDP
Reliable and ordered vs. fast and best-effort — the two ways bytes travel over IP.
Big idea
TCP guarantees reliable, ordered delivery at the cost of extra latency; UDP sends packets with no guarantees in exchange for speed. Choosing one means choosing which failure you can tolerate: waiting or losing.
The idea
Once a packet knows where it's going (that's IP's job), something still has to decide how it gets delivered — reliably and in order, or as fast as possible with no guarantees. That's the transport layer, and in practice it means choosing between two protocols: TCP and UDP.
Think of it like
Sending an important contract, you use registered mail: the post office confirms someone is there to receive it, collects a signature for every envelope, resends anything that goes missing, and numbers the pages so they can be put back in order. It's dependable, but slow. A sports commentator on live radio just keeps talking; if static swallows a sentence, nobody rewinds, because the next play matters more than the one you missed. TCP is the registered mail, with its handshake and acknowledgments; UDP is the live broadcast, fast and best-effort.
TCP — reliable, ordered, connection-based
TCP starts every conversation with a three-way handshake (SYN, SYN-ACK, ACK) before a single byte of real data moves — both sides are confirming "I'm here, I heard you, let's go" before committing to a connection. From then on, every segment is numbered, acknowledged, and retransmitted if it goes missing, and the receiving side reassembles everything in the original order even if packets arrive out of sequence.
That reliability isn't free — the handshake, acknowledgments, and retransmission logic all add latency and overhead. TCP also does congestion control, deliberately slowing down when it senses the network is struggling, which is good for the network as a whole but means throughput can dip under load.
Use TCP when correctness matters more than raw speed: web traffic (HTTP), file transfer, email, anything where a dropped or out-of-order byte would actually break something.
UDP — fast, unordered, connectionless
UDP skips all of that. There's no handshake, no acknowledgment, no retransmission, and no guaranteed order — you fire a packet ("datagram") at a destination and it either arrives or it doesn't, and nothing in UDP itself will tell you which. In exchange, it has far less overhead and lower latency, since there's no connection state to maintain and no waiting for confirmation before sending the next packet.
Use UDP when speed matters more than any single packet, and when the application itself can tolerate — or already compensates for — loss: video calls and live streaming (a dropped frame is fine, waiting for a retransmit that arrives late is worse), DNS lookups (small, and the client just retries if nothing comes back), and online games (a stale position update is worse than a missing one).
The core tradeoff
| TCP | UDP | |
|---|---|---|
| Connection | Handshake required | None — connectionless |
| Delivery | Guaranteed, retransmits on loss | Best-effort, no retransmission |
| Order | Guaranteed | Not guaranteed |
| Overhead | Higher (headers, ACKs, state) | Minimal |
| Typical use | HTTP, file transfer, email | Video/voice calls, DNS, gaming |
Neither one is "better" — they're optimized for opposite priorities. Picking between them is really picking which failure mode your application can tolerate: waiting, or losing.
By the numbers
Connection setup costs round trips. With a 100 ms round-trip time (say, Mumbai ↔ Frankfurt):
| Step | Round trips | Time |
|---|---|---|
| TCP handshake | 1 | 100 ms |
| TLS 1.3 handshake | 1 (TLS 1.2: 2) | 100 ms |
| The HTTP request itself | 1 | 100 ms |
| First byte of the response | 3 | ~300 ms |
HTTP/3 over QUIC (which runs on UDP) folds transport and TLS into one round trip — and zero on a resumed connection — which is why it matters most on long, lossy mobile links. Reusing connections (keep-alive, pooling) avoids the setup entirely.
Headers: TCP 20 bytes, UDP 8.
Throughput is capped by window ÷ RTT. A 64 KB window over a 100 ms RTT moves at most 64 KB × 10 per second ≈ 5 Mbit/s, however fast the link. And loss hurts TCP a lot: at 1% packet loss, a single connection over that 100 ms path tops out around 1 Mbit/s (throughput ≈ MSS ÷ (RTT × √loss)). That's why video calls and games use UDP and tolerate a lost packet rather than wait for it.
A fresh HTTPS request over TCP and TLS 1.3 crosses a link with a 100 ms round trip. Roughly when does the first byte of the response arrive?
Which of these is the best fit for UDP?
Key terms
- TCP — A connection-based protocol that delivers every byte reliably and in order.
- UDP — A connectionless protocol that sends datagrams with no delivery or ordering guarantees.
- Three-way handshake — The SYN, SYN-ACK, ACK exchange TCP uses to set up a connection before sending data.
- Retransmission — Resending a segment that was never acknowledged, which TCP does and UDP does not.
- Congestion control — TCP deliberately slowing its sending rate when it detects the network is struggling.