TCP and UDP are the two main transport-layer protocols of the internet. They both sit on top of IP and carry application data between hosts, but they make opposite trade-offs. TCP guarantees reliable, ordered delivery at the cost of overhead and latency; UDP sends packets with minimal overhead and makes no guarantees.
Choosing between them comes down to a single question: does your application need every byte to arrive, in order — or does it need data to arrive fast, even if some of it is lost?
1. The Core Difference
TCP (Transmission Control Protocol) is connection-oriented. Before any data flows, the two hosts establish a connection, and TCP then tracks every byte, retransmits anything that’s lost, and delivers the data to the application in the exact order it was sent.
UDP (User Datagram Protocol) is connectionless. There’s no setup and no tracking. The sender fires off independent packets (datagrams), and that’s it — no acknowledgement, no retransmission, no ordering. If a packet is lost or arrives out of order, UDP neither knows nor cares; it’s up to the application to deal with it.
| Property | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (handshake first) | Connectionless (no setup) |
| Reliability | Guaranteed delivery (retransmits lost data) | Best-effort (no retransmission) |
| Ordering | In-order delivery | No ordering guarantee |
| Error handling | Detects loss and recovers | Detects corruption (checksum), drops bad packets |
| Flow/congestion control | Yes | No |
| Header size | 20–60 bytes | 8 bytes |
| Speed | Higher latency, more overhead | Lower latency, minimal overhead |
2. The TCP Three-Way Handshake
TCP establishes a connection before sending data using a three-step exchange:
Client Server
| ---------- SYN ----------> | "I want to connect, my sequence number is X"
| <------ SYN-ACK ---------- | "OK, acknowledging X; my sequence number is Y"
| ---------- ACK ----------> | "Acknowledging Y. Connection established."Only after this handshake completes does application data start to flow. When the connection closes, a similar exchange (FIN/ACK) tears it down.
This handshake is why TCP has higher startup latency: a connection costs a full round trip before any useful data moves. For a long-lived connection (downloading a file, streaming a web page), that one-time cost is negligible. For a tiny one-off request, it can dominate — which is part of why DNS uses UDP.
UDP has no equivalent. The first packet is the data.
3. Reliability and Ordering
This is the heart of the comparison.
TCP assigns every byte a sequence number. The receiver acknowledges what it has received, and if the sender doesn’t get an acknowledgement within a timeout, it retransmits. The receiver uses the sequence numbers to reassemble the stream in order before handing it to the application. The application sees a clean, complete, ordered byte stream — it never sees a lost or reordered packet.
UDP does none of this. Each datagram carries a checksum (so the receiver can detect corruption and drop a bad packet), but there’s no acknowledgement, no retransmission, and no reordering. The application receives whatever arrives, in whatever order it arrives, with gaps where packets were lost.
That sounds strictly worse, but for some workloads it’s exactly right. In a live voice call, a packet that arrives 300ms late is useless — you’d rather skip it and play the next one than stall the whole call waiting for a retransmission. UDP lets the application make that choice.
4. Headers and Overhead
The header sizes show the philosophy. UDP’s header is 8 bytes and carries only four fields:
UDP header (8 bytes):
+------------------+------------------+
| Source Port | Destination Port |
+------------------+------------------+
| Length | Checksum |
+------------------+------------------+TCP’s header is at least 20 bytes (up to 60 with options) and carries sequence numbers, acknowledgement numbers, window size for flow control, flags (SYN, ACK, FIN, RST), and more — everything needed to track and recover a connection.
That extra TCP machinery is the reason it’s reliable, and also the reason it has more per-packet overhead and more latency.
5. Flow and Congestion Control
TCP also manages how fast it sends:
- Flow control uses a “window” so a fast sender doesn’t overwhelm a slow receiver.
- Congestion control (algorithms like Reno, CUBIC, and BBR) detects network congestion — usually via packet loss — and backs off the sending rate, then ramps back up. This is what keeps the internet from collapsing under load, and it’s why a single TCP download speeds up and slows down as conditions change.
UDP has neither. It sends as fast as the application tells it to. If that causes congestion, UDP won’t back off on its own — the application (or a higher-level protocol like QUIC) has to implement that logic if it needs it.
6. Which Protocol Real Applications Use
TCP
- The web (HTTP/1.1 and HTTP/2): pages, APIs, and assets must arrive complete and in order.
- Email (SMTP, IMAP): a message can’t be missing bytes.
- File transfer (FTP, SFTP) and SSH: correctness is non-negotiable.
The common thread: the data must be complete and correct, and a bit of extra latency is acceptable.
UDP
- DNS: small query/response that fits in one packet; the handshake overhead of TCP would be wasteful. Falls back to TCP for large responses.
- Live video and voice (VoIP, video calls): low latency matters more than a perfect stream; a lost frame is better skipped than waited for.
- Online gaming: position updates need to be current, not complete — a late update is worthless because a newer one is already on the way.
- QUIC / HTTP/3: built on UDP, but adds its own reliability and ordering on top, combining UDP’s flexibility with TCP-like guarantees.
The common thread: timeliness matters more than completeness, or the payload is small enough that connection setup isn’t worth it.
7. A Note on QUIC and HTTP/3
It’s worth knowing that the TCP/UDP line is blurring. QUIC, the protocol behind HTTP/3, runs over UDP but implements reliability, ordering, and congestion control itself — in user space rather than the operating system kernel. This lets it fix long-standing TCP limitations (like head-of-line blocking, where one lost packet stalls all streams on a connection) while still giving applications the reliable delivery they expect.
So “UDP is unreliable” is true of UDP itself, but a protocol built on UDP can add whatever guarantees it needs. That flexibility is exactly why modern protocols are choosing UDP as a foundation.
8. How to Choose
- Use TCP when the application needs every byte delivered, in order: web pages, APIs, file transfer, email, anything where missing data is a bug.
- Use UDP when low latency matters more than completeness, or the exchange is small and one-shot: live media, gaming, DNS, telemetry, and as a base for custom protocols like QUIC.
If you’re building a normal web application or API, you’re already using TCP (through HTTP) and don’t need to think about it. You reach for UDP deliberately, when its trade-offs match a specific need.