The short answer
TCP and UDP are the two main transport protocols of the internet. Both carry data between programs on different machines, on top of IP. They make opposite trade-offs.
Quick answer: TCP (Transmission Control Protocol) sets up a connection first and guarantees that every byte arrives, in order, without duplicates. UDP (User Datagram Protocol) just sends packets with no setup and no guarantees. TCP is reliable but adds delay; UDP is fast but can lose data. Web pages, email and file downloads use TCP. Video calls, online games and DNS lookups often use UDP.
| TCP | UDP | |
|---|---|---|
| Connection | Handshake before any data | None; just send |
| Delivery | Guaranteed; lost packets are resent | Best effort; lost packets stay lost |
| Order | Always in order | Can arrive out of order |
| Data model | A continuous byte stream | Separate messages (datagrams) |
| Flow and congestion control | Built in | None; the app must handle it |
| Header size | 20 to 60 bytes | 8 bytes |
| Broadcast / multicast | No | Yes |
| Typical uses | Web (HTTP/1.1, HTTP/2), email, SSH, file transfer | DNS, voice and video calls, games, streaming telemetry, QUIC |
| Specification | RFC 9293 | RFC 768 |
The classic analogy: TCP is a phone call. You dial, wait for an answer, and if they miss a word they ask you to repeat it. UDP is a stream of postcards. You drop them in the box and hope they all arrive; some may come in the wrong order, and one or two may not come at all.
The difference in one picture
TCP spends a round trip on the handshake and keeps checking in afterwards. When a packet goes missing, the receiver notices the gap and the sender resends it. UDP skips all of that, so it's faster, but a lost packet is simply gone.
How TCP guarantees delivery
IP, the layer underneath, makes no promises. Packets can be dropped, duplicated, delayed or reordered. TCP builds reliability on top with a handful of mechanisms:
- Three-way handshake. SYN, SYN-ACK, ACK. Both sides agree on starting sequence numbers before any data flows. Cloudflare's TCP/IP explainer walks through it.
- Sequence numbers. Every byte is numbered, so the receiver can reassemble data in the right order and throw away duplicates.
- Acknowledgements (ACKs). The receiver reports how much it has received. Anything unacknowledged after a timeout, or flagged as missing by repeated ACKs, is retransmitted.
- Checksums. Each segment carries a checksum, so corrupted data is detected and discarded.
- Flow control. The receiver advertises how much buffer space it has left, so a fast sender can't overwhelm a slow receiver.
- Congestion control. TCP starts slowly and speeds up while things go well, then backs off when packets are lost. This keeps millions of connections from collapsing the network.
- Graceful close. FIN and ACK messages make sure both sides have finished before the connection is torn down.
All of this is invisible to the application. A program just writes bytes into a socket and reads bytes out the other end, as if through a perfect pipe.
The hidden cost: head-of-line blocking
Because TCP delivers bytes strictly in order, one lost packet holds up everything behind it, even data that has already arrived. For a file download that's fine. For a live video call, waiting for a half-second-old frame is worse than skipping it. This problem is also why HTTP/3 moved off TCP.
How UDP stays fast
UDP's header, defined in RFC 768, is just 8 bytes: source port, destination port, length and checksum. That's it. No connection state, no sequence numbers, no retransmissions.
That simplicity buys three things:
- No setup delay. The first packet carries real data.
- No waiting on the past. Each datagram is handled on its own, so a lost one doesn't stall the rest.
- Low overhead. A server can handle huge numbers of clients without tracking connections. Cloudflare's UDP explainer notes this is also why UDP is popular for flood attacks.
UDP doesn't mean "unreliable apps." It means the application decides what reliability it needs. A game might resend important events ("player died") but never resend old position updates.
When to use TCP vs UDP
The rule of thumb: if late data is still useful, use TCP. If late data is useless, consider UDP.
| Use case | Protocol | Why |
|---|---|---|
| Web pages (HTTP/1.1, HTTP/2) | TCP | Every byte of HTML, CSS and JS must arrive intact |
| Web pages (HTTP/3) | UDP, via QUIC | QUIC adds its own reliability without TCP's blocking |
| Email (SMTP, IMAP) | TCP | Messages must arrive complete |
| File transfer, SSH, databases | TCP | Correctness beats speed |
| DNS lookups | UDP (TCP for large answers) | One tiny question, one tiny answer |
| Voice and video calls | UDP | A missing 20 ms of audio is better than a delay |
| Online multiplayer games | UDP | Only the newest position matters |
| Video on demand (YouTube, Netflix) | Usually TCP or QUIC | Buffering hides delay, and the picture must be complete |
| WebSockets | TCP | Built on an HTTP connection |
A few of these deserve a closer look:
- DNS uses UDP because a query and answer each fit in one packet. See how DNS works.
- WebSockets run over TCP, which is why they suit chat and live scores but not fast-twitch games. See how WebSockets work.
- Web browsing is TCP-first: the URL-to-page journey opens a TCP connection, then runs a TLS handshake on top.
QUIC: the best of both
QUIC, standardised in RFC 9000, runs on UDP but rebuilds TCP's good parts in user space: reliable delivery, ordering, and congestion control. It adds two things TCP can't:
- Independent streams. A lost packet only stalls the stream it belongs to, not every stream on the connection.
- Built-in encryption. Connection setup and the TLS 1.3 handshake happen together, saving a round trip.
QUIC runs on UDP partly for practical reasons. Routers and firewalls everywhere already pass UDP, while a brand-new transport protocol would be blocked by old network equipment for decades.
Frequently asked questions
Is UDP faster than TCP?
UDP has less overhead: no handshake, no acknowledgements, and a smaller header. So it usually has lower latency, especially at connection start and on lossy networks. For bulk downloads on a good connection, TCP's throughput is comparable.
Is UDP unreliable?
UDP itself doesn't guarantee delivery, but applications can add exactly the reliability they need on top. QUIC is a fully reliable protocol built on UDP.
Why doesn't everything just use TCP?
For real-time data, TCP's guarantees become a liability. Waiting to resend a lost packet makes a video call stutter, and resending an old game position is pointless when a newer one has already been sent.
Can a port use both TCP and UDP?
Yes. TCP and UDP port numbers are separate spaces. DNS, for example, listens on port 53 for both.
What layer are TCP and UDP?
Both are transport layer protocols (layer 4 in the OSI model). They sit above IP, which handles addressing and routing, and below application protocols like HTTP, DNS and SMTP.
Does HTTPS use TCP or UDP?
HTTP/1.1 and HTTP/2 run TLS over TCP. HTTP/3 runs over QUIC, which uses UDP and has TLS 1.3 built in.
Conclusion
TCP and UDP aren't rivals; they're tools for different jobs. TCP trades time for certainty, which is what you want for web pages, email and files. UDP trades certainty for time, which is what you want when data goes stale in milliseconds. QUIC shows the modern answer: start from UDP's flexibility and add only the reliability you need.
Related articles
- What happens when you type a URL and press Enter
- How DNS turns "google.com" into an IP address
- How HTTPS keeps your data safe (TLS handshake explained)
- Why HTTP/2 and HTTP/3 exist
- How CDNs make websites load faster worldwide
- What is a load balancer?
- How WebSockets enable real-time apps
- Why IPv4 ran out and how NAT kept the internet alive
- How email travels from your outbox to someone's inbox
Sources and further reading
- RFC 9293: Transmission Control Protocol
- RFC 768: User Datagram Protocol
- RFC 9000: QUIC
- What is TCP/IP? (Cloudflare Learning Center)
- What is UDP? (Cloudflare Learning Center)
- What is HTTP/3? (Cloudflare Learning Center)
