TCP vs UDP
TCP gives you a reliable, ordered stream at the cost of handshakes and waiting for lost packets; UDP sends independent packets with no guarantees and no delay. Learn how each works and when to choose which.
In a nutshell
- TCP: connection-based, reliable, ordered, with flow and congestion control. Used by HTTP/1.1, HTTP/2, databases, email.
- UDP: no connection, no guarantees, no ordering, very low overhead. Used by DNS, video calls, games, and QUIC (HTTP/3).
- TCP waits for lost data, which adds delay; UDP lets the application decide what to do about loss.
- Choose TCP when every byte must arrive; UDP when fresh data matters more than complete data.
Two ways to send data
Both TCP and UDP run on top of IP, which delivers individual packets between machines on a best-effort basis: packets can be lost, duplicated or arrive out of order. TCP and UDP take opposite approaches to that.
| TCP | UDP | |
|---|---|---|
| Connection | Set up with a handshake before data flows | None: just send |
| Delivery | Guaranteed: lost packets are resent | Best effort: lost packets are lost |
| Order | Bytes arrive in the order sent | Packets may arrive in any order |
| Unit | A continuous stream of bytes | Separate messages (datagrams) |
| Speed control | Flow control and congestion control built in | None; the application must be polite |
| Header size | 20+ bytes | 8 bytes |
The TCP handshake
Before any data flows, TCP spends one round trip agreeing on starting sequence numbers, which it uses to put bytes in order and detect what is missing.
Three-way handshake
All steps SYN, SYN-ACK, ACK: one round trip before the first byte of data can be sent.
- The client asks to open a connection and picks a starting sequence number.
- The server acknowledges it and picks its own starting number.
- The client acknowledges the server's number. The connection is open, and data can ride along with this packet.
Diagram as text
- The client asks to open a connection and picks a starting sequence number.
- The server acknowledges it and picks its own starting number.
- The client acknowledges the server's number. The connection is open, and data can ride along with this packet.
After that, every chunk of data is acknowledged. If an acknowledgement does not arrive in time, the sender resends. The receiver holds back later data until the missing piece arrives, so the application always reads bytes in order.
The price of reliability
Waiting for a lost packet stalls everything behind it. This is head-of-line blocking. For a file download it does not matter: you need every byte anyway. For a video call it is harmful: by the time a resent piece of audio arrives, the moment has passed, and everything after it was delayed too.
One lost packet stalls the stream
Diagram as text
- Packet 1 → Packet 2
- Packet 2 → Packet 3: blocked
- Packet 3 → Packet 4
TCP also slows down when it sees loss (congestion control), which is good citizenship on a shared network but adds delay on poor connections.
When to use which
| Use TCP for… | Use UDP for… |
|---|---|
| Web pages and APIs over HTTP/1.1 and HTTP/2 | DNS lookups (small, a quick retry is cheaper than a handshake) |
| Database connections | Voice and video calls, live streaming |
| File transfer, email, SSH | Multiplayer games (the latest position matters, not old ones) |
| Anything where missing data is unacceptable | Protocols that build their own reliability, such as QUIC |
Common mistakes
- Saying UDP is "faster" without qualification. It has no handshake and no waiting for resends, but the application must handle loss itself.
- Using UDP for data that must arrive complete and then reinventing TCP badly.
- Forgetting that many corporate firewalls block UDP, so UDP-based protocols need a TCP fallback.
Interview questions
Try answering out loud before you open each one.
Why do video calls use UDP?
Freshness matters more than completeness. With TCP, one lost packet delays everything behind it while it is resent, causing freezes. With UDP, a lost packet is simply skipped (maybe concealed by the codec) and the call keeps flowing with low latency.
Why does DNS mostly use UDP?
Queries and answers are small and fit in one packet. A UDP query avoids the TCP handshake round trip; if a packet is lost, the client simply asks again. DNS falls back to TCP for large responses and zone transfers.
Check yourself
Related topics
Further reading
- TCP vs UDP Cloudflare Learning Center
- High Performance Browser Networking (free online book) Ilya Grigorik, O'Reilly
Your notes
Saved in this browser as you type.
Finished this topic?
Mark it read to track your progress, then carry on with the next one.