Part 1 · Foundations Before System Design
TCP vs UDP: How Data Actually Travels
The internet loses, duplicates and reorders packets. TCP promises every byte in order and pays for it in round trips; UDP just sends and lets the app cope. How each works, and how QUIC takes the best of both.
On this page
The Problem
In the last lesson we saw that data travels as packets. A packet is a small chunk of data with an address on it. But the internet makes no promises about those packets:
- Some get lost.
- Some arrive twice.
- Some arrive in the wrong order: packet 5 before packet 3.
For a bank transfer, this is not acceptable. For a live video call, it is worse to wait for a lost packet than to skip it.
So which do you want: "everything, in order, no matter how long it takes" or "fast, even if a bit is missing"? That choice is the difference between TCP and UDP, and it shapes how chat apps, games, video streaming and APIs are built.
A protocol is a set of rules that two computers agree on for talking to each other. TCP (Transmission Control Protocol) is a protocol that delivers data reliably and in order. UDP (User Datagram Protocol) is a protocol that just sends data fast, with no promises. Difference in one line: TCP checks that everything arrived, UDP does not check.
The Core Idea
Think about two ways to send documents to a friend.
TCP is like a courier with tracking. You number every page. The friend confirms each page they receive. If page 7 goes missing, you send it again. Your friend puts the pages in order before reading. It is reliable, but there is extra back-and-forth.
UDP is like shouting across a room. You just say things. Nobody asks "did you hear that?" and nothing is repeated. If a word gets lost in the noise, it is gone. But it is very fast and very simple.
| TCP | UDP | |
|---|---|---|
| Connection | Must set up first (handshake) | None, just send |
| Delivery | Guaranteed (lost data is resent) | Not guaranteed |
| Order | Always in order | Can arrive in any order |
| Speed | More overhead (extra work and extra bytes), slower to start | Minimal overhead |
| Header size (the extra control bytes added to every packet) | 20+ bytes | 8 bytes |
| Used for | Web pages, APIs, email, file downloads, databases | Video calls, online games, DNS, live streaming |
How It Works
TCP: the three-way handshake
A handshake is a short exchange of messages that two computers do before they start talking. Before sending any data, TCP opens a connection with three messages. SYN means "synchronise" (let us agree on starting numbers). ACK means "acknowledge" (I got it).
- SYN“Can we talk? My numbers start at 100”
- SYN-ACK“Got your 100. Mine start at 500”
- ACK“Got your 500. Let's go.”
- Connection open — data can now flow both ways
- GET /index.htmlthe first real bytes, 1 RTT later
- 200 OK + data
This costs one full round trip before any real data is sent. A round trip (RTT, round-trip time) is the time for a message to go to the other side and come back. If one round trip to the server takes 100 ms, you have waited 100 ms just to say hello. This is why:
- Keep-alive (keeping one connection open and reusing it for many requests) matters so much.
- Connection pools in backend servers keep a set of ready connections to the database and reuse them, instead of making a new one for every query.
TCP: how reliability works
- Sequence numbers. Every byte has a number, so the receiver can put data back in order and see what is missing.
- Acknowledgements (ACKs). Short replies from the receiver, such as "I have everything up to byte 4,000".
- Retransmission. If the sender does not get an ACK in time, it sends the data again.
TCP: flow control and congestion control
These two ideas sound alike but protect different things. Congestion means too much traffic on the network at once, like a traffic jam.
- Flow control protects the receiver. The receiver says "I only have room for 64 KB right now, do not send more". This limit is called the receive window.
- Congestion control protects the network. TCP starts slowly (called slow start), sends more and more while things go well, and slows down sharply when packets are lost, because loss usually means the road is jammed. Modern algorithms like CUBIC (the Linux default) and BBR (created by Google) are smarter versions of this.
A practical result: a brand-new TCP connection is slow at first. It needs a few round trips to "ramp up" (reach full speed). That is another reason why reusing connections is faster.
TCP: head-of-line blocking
TCP promises order. So if packet 3 is lost, packets 4, 5 and 6 may have already arrived, but the app cannot see them until packet 3 is sent again and arrives.
Arrived: [1] [2] [ ] [4] [5] [6]
▲
lost ─── everything behind it waits,
even though 4, 5 and 6 are already hereThis is called head-of-line blocking: one stuck item at the front of the line makes everything behind it wait. It is fine for downloading a file. It hurts a video call, where old data is useless.
Closing a TCP connection
Connections close with FIN ("finish") and ACK messages. The side that closes first then waits in a state called TIME_WAIT for a short time (about 60 seconds on Linux), to catch any late packets.
On a very busy server that opens and closes thousands of short connections, these waiting connections can pile up and use up the available ports. (A port is a number that picks one program on a machine.) This is one more reason to reuse connections.
UDP: just send it
UDP has no handshake, no ACKs, no retransmission and no ordering. The app gives UDP a message (called a datagram) and it is sent. The header is only 8 bytes: source port, destination port, length and checksum. A checksum is a small number used to detect damaged data.
This means:
- No setup delay. The first message leaves immediately.
- No waiting for lost packets. The app gets whatever arrives.
- The app decides what to do about loss. A video app might hide a lost frame. A game might just use the next position update.
When UDP apps still need some reliability
Many UDP apps build their own small version of the features they need. For example:
- A game sends player positions over UDP (it is fine to lose one, because a newer one comes in about 16 ms), but adds sequence numbers so it can ignore old updates that arrive late.
- A video call adds timestamps so it can play audio smoothly, and may resend only the important frames.
QUIC: the best of both
QUIC is a newer protocol, originally built at Google and now an internet standard. It runs on top of UDP but adds TCP-like reliability, built-in encryption, and many independent streams. A stream is one separate flow of data inside a connection, such as one image.
- Faster setup. It combines the connection handshake and the encryption handshake into one round trip. When you reconnect to a server you know, it can send data with zero round trips of waiting.
- No head-of-line blocking between streams. If a packet for image A is lost, image B keeps loading.
- Connection migration. If your phone switches from Wi-Fi to mobile data, the connection can keep working.
Why build it on UDP instead of creating a new protocol? Routers and firewalls (programs that block unwanted traffic) across the world only understand TCP and UDP. A brand-new protocol would be blocked. UDP lets QUIC travel through the existing internet. HTTP/3, the newest version of the web protocol, runs on QUIC.
Choosing between them
- +Every byte arrives, in order
- +The operating system handles retries, flow control and congestion control
- −Handshake before any data
- −One lost packet blocks everything behind it
- +No setup — the first message leaves at once
- +Old data is simply skipped, never waited for
- −No delivery or order guarantees
- −Some firewalls block it; needs a TCP fallback
- +Reliable and encrypted, built on UDP
- +1-RTT setup, 0-RTT on reconnect
- +A lost packet only stalls its own stream
- •Survives Wi-Fi → mobile network switches
Trade-offs
TCP
- ✅ Reliable, ordered, well understood; works everywhere.
- ✅ The operating system handles the hard parts for you.
- ❌ Handshake delay on every new connection.
- ❌ Head-of-line blocking.
- ❌ Slow start on fresh connections.
UDP
- ✅ Very low overhead and latency; no setup.
- ✅ Great for real-time data where old data is useless.
- ❌ No delivery or order guarantees; you build what you need yourself.
- ❌ Some corporate firewalls block UDP, so apps often need a TCP fallback.
- ❌ No built-in congestion control. A careless UDP app can flood a network.
When NOT to use UDP: anything where losing data gives wrong results, such as payments, orders, account updates or file uploads. Use TCP (or HTTP on top of it) instead.
In the Real World
Zoom, Google Meet and WhatsApp calls send audio and video mostly over UDP (often through WebRTC, a set of browser technologies for live calls). If a packet is lost, you might hear a tiny glitch, but the call keeps going in real time. If the network blocks UDP, these apps often fall back to TCP, and calls usually feel slower to respond.
Online games like Fortnite, Valorant or Call of Duty send player movement over UDP many times per second. Losing one update does not matter because the next one arrives a few milliseconds later. Things like purchases in the in-game store go over normal HTTPS, which uses TCP.
DNS (the system that turns names into IP addresses) mostly uses UDP. A question and an answer usually fit in one small packet each, so a handshake would double the time. If an answer is too big, DNS switches to TCP.
Google, YouTube and Cloudflare serve a large share of their traffic over HTTP/3, which runs on QUIC over UDP. Mobile users on weak or changing networks benefit the most.
Movies and recorded videos (for example on Netflix) are mostly delivered over HTTP on TCP, unlike video calls. (YouTube also uses QUIC.) Why? A recorded video is not live, so the player can buffer (download and keep) several seconds ahead. Reliability matters more than a few extra milliseconds.
Databases such as PostgreSQL and MySQL use TCP. A query result with a missing row would be a bug, not a small glitch.
Interview Questions
Q1When would you choose UDP over TCP?
When fresh data is more important than complete data: voice and video calls, multiplayer games, live telemetry, and small question-and-answer lookups like DNS. In these cases it is worse to wait for a lost packet than to skip it, and the app can add only the reliability it needs (sequence numbers, a few resends).
Q2What is head-of-line blocking, and how does QUIC avoid it?
TCP delivers bytes strictly in order, so one lost packet holds back everything that arrived after it. HTTP/2 multiplexes (sends together) many streams over one TCP connection, so one loss stalls all of them. QUIC tracks ordering per stream on top of UDP, so a lost packet only delays the stream it belongs to.
Q3Why is a brand-new TCP connection slow, and what do systems do about it?
It costs one round trip for the handshake, and slow start sends only a little data at first, so it takes several round trips to reach full speed. Systems reuse connections to avoid this: HTTP keep-alive, connection pools to databases, and long-lived connections between services.
Q4Flow control vs congestion control — what does each protect?
Flow control protects the receiver: it announces a receive window so the sender never fills the receiver's buffer (its waiting area in memory). Congestion control protects the network: TCP grows its sending rate while things go well and backs off sharply on packet loss, which usually signals a jammed path.
Q5Why was QUIC built on UDP instead of as a brand-new protocol?
Because of middleboxes. Middleboxes are the routers, firewalls and home routers (NAT boxes) on the path. They only understand TCP and UDP, and block anything else. Building on UDP lets QUIC pass through the existing internet. QUIC adds reliability and encryption inside the application (user space) instead of inside the operating system.
Key Takeaways
- TCP gives you reliable, ordered delivery. The cost is handshakes, ACKs and possible head-of-line blocking.
- UDP gives you speed and simplicity, but no guarantees. The app must handle loss itself.
- New TCP connections are slow to start, so reuse connections with keep-alive and connection pools.
- Use UDP when fresh data beats complete data: calls, games, live streams.
- QUIC (and HTTP/3) builds reliability and encryption on top of UDP, giving you much of TCP's safety with less delay.
Further Reading
- High Performance Browser Networking by Ilya Grigorik (chapters 2 and 3, "Building Blocks of TCP" and "Building Blocks of UDP")
- Computer Networking: A Top-Down Approach by Kurose and Ross (chapter 3, the transport layer)
- RFC 9293 (TCP) and RFC 9000 (QUIC), the official specifications
- Cloudflare's blog post "The Road to QUIC"
Published by Jainik · Last updated · How these lessons are made
Keep learning
Related series