Packets get lost. Networks reorder them, duplicate them, and deliver them late. Every transport protocol is one answer to a single question: what should happen when a packet does not arrive?
TCP says: stop everything and fetch it. UDP says: carry on without it. QUIC says: fetch it, but only stall the part of the conversation that needed it.
Everything above — HTTP, your database driver, your game loop — inherits whichever answer you picked.
TCP: no byte is ever lost
TCP presents an ordered, reliable stream of bytes. What you write at one end emerges at the other, complete and in sequence, or the connection fails loudly.
It buys that with four mechanisms.
A three-way handshake. SYN, SYN-ACK, ACK before any data moves. Both sides agree on starting sequence numbers and confirm the other is really there. That costs one round trip before the first useful byte, and a further one or two if TLS follows.
Sequence numbers and acknowledgements. Every byte is numbered. The receiver acknowledges what it has, and anything unacknowledged is retransmitted.
Flow control. The receiver advertises how much buffer space it has, so a fast sender cannot drown a slow receiver.
Congestion control. The sender infers network capacity from loss and delay and backs off when the path is saturated. This is why TCP is a good citizen: a million connections sharing a link converge on a fair share rather than collapsing it.
The cost is the guarantee
TCP's weaknesses are not bugs. They are its guarantee, viewed from the other side.
Head-of-line blocking is the important one. Packets 1, 2 and 3 are sent; packet 2 is lost. Packet 3 arrives and sits in the receiver's buffer, complete and correct — and the application is not allowed to see it, because in-order delivery was promised. Everything waits for the retransmission of 2.
That is fine for a file. It is disastrous for anything where fresher data has already superseded the missing data.
HTTP/2 made this sharper. It multiplexes many requests over one TCP connection, so one lost packet on one stream stalls every stream sharing that connection — the protocol solved application-level head-of-line blocking and then hit the transport-level version underneath it.
UDP: send it and move on
UDP is barely a protocol. It adds ports and a checksum to raw IP and stops there.
No handshake, so the first packet carries data. No acknowledgements, no retransmission, no ordering, no connection state on either side. A packet that is lost is simply lost, and one that arrives out of order arrives out of order.
This is not a weaker TCP. It is a different contract: UDP gives your application the network as it actually is, and lets you decide what reliability means for your data. You can build retransmission on top of it for the messages that need it, and skip it for the ones that do not — something TCP does not let you choose.
It is also the only option for multicast and broadcast, and its lack of connection state is why DNS uses it.
Why real-time systems choose loss over delay
A first-person shooter sends the player's position around sixty times a second. Consider a lost position update.
Over TCP, everything after it waits — perhaps a couple of hundred milliseconds — for a retransmission of a position that is, by the time it arrives, several updates out of date. The client stalls, then jumps. Worse, the correction it eventually applies is stale.
Over UDP, that update is simply gone. The next one arrives sixteen milliseconds later and supersedes it entirely. Nobody notices.
When data expires faster than it can be retransmitted, retransmission is worse than useless — it costs latency to deliver something already obsolete. Voice, video and game state all have this property.
Games layer three techniques on top of the loss:
Client-side prediction. The client moves your character immediately on input rather than waiting for the server, so control feels instant.
Interpolation. Other players are drawn slightly in the past, between two known positions, which smooths straight over a missing update.
Lag compensation. The server rewinds the world by the shooter's latency before deciding whether a shot hit, so aiming at what you saw is correct.
Turn-based games and in-game chat go back to TCP, because there the data does not expire and losing a message matters.
QUIC: reliability without the shared stall
Diagram, as text
- Image 1 leads to Packet lost
- Packet lost leads to Images 2-10 wait
QUIC is a transport built on top of UDP, in userspace, with reliability, ordering and congestion control reimplemented above it. HTTP/3 is HTTP over QUIC.
Building on UDP is a deployment decision, not a technical preference. TCP is implemented in operating-system kernels and enforced by middleboxes worldwide; a genuinely new transport would take a decade to deploy. UDP is the escape hatch that lets a new protocol ship as an application update.
Four things fall out of that freedom.
Independent streams. A QUIC connection carries many streams, each with its own ordering. A lost packet stalls only the stream whose data it held; the others deliver as normal. This is exactly the head-of-line blocking that HTTP/2-over-TCP could not fix.
Faster setup. Transport and TLS 1.3 handshakes are merged into one exchange, so a new connection is 1-RTT instead of the 2–3 that TCP plus TLS requires. Resuming a previous connection can be 0-RTT — data in the very first packet.
Connection migration. A QUIC connection is identified by a connection ID, not by the four-tuple of addresses and ports. Move from wi-fi to mobile data and your IP changes, but the connection ID does not, so downloads and calls survive. A TCP connection is defined by its addresses and dies with them.
Encryption is mandatory. TLS 1.3 is part of QUIC, not a layer bolted above it, so there is no unencrypted mode and far less of the header is visible to intermediaries.
The costs: it runs in userspace, so it uses noticeably more CPU per byte than a kernel TCP stack; some restrictive networks still block or throttle UDP; and the tooling around it is younger.
Choosing
| TCP | UDP | QUIC | |
|---|---|---|---|
| Setup before data | 1 RTT, plus TLS | None | 1 RTT, 0 on resumption |
| Reliability | Guaranteed | None | Guaranteed, per stream |
| Ordering | Global, one stream | None | Per stream |
| Head-of-line blocking | Across the connection | None | Within one stream only |
| Congestion control | Yes | None, you build it | Yes, and more adaptable |
| Survives an IP change | No | Not applicable | Yes |
| Encryption | Optional (TLS) | None | Always on |
| Runs in | Kernel | Kernel | Userspace |
TCP for anything where every byte matters and connections are long-lived: databases, SSH, file transfer, most existing HTTP traffic.
UDP where data expires: live video and voice, game state, telemetry, DNS — and anywhere you need multicast.
QUIC for modern web and mobile clients, where many parallel requests, lossy networks and changing addresses are all normal. This is what HTTP/3 gives you and it is why major browsers and CDNs default to it.
Check your understanding
Common mistakes
Calling UDP "unreliable TCP". It is a different contract that hands reliability decisions to the application, which is the point when different messages need different guarantees.
Assuming TCP is always slower. For bulk transfer over a good link it is excellent. Its weakness is latency-sensitive traffic with loss, not throughput.
Rebuilding TCP badly on top of UDP. Retransmission and congestion control are genuinely hard. If you need everything TCP offers, use TCP or QUIC.
Forgetting congestion control when you do use UDP. A UDP sender that never backs off can saturate a link and hurt every other flow on it, including its own.
Treating head-of-line blocking as a TCP bug. It is the direct consequence of in-order delivery. The only way out is per-stream ordering.
Expecting UDP to work everywhere. Some corporate and mobile networks block or throttle it, which is why QUIC deployments keep a TCP fallback.
Practice
You are choosing a transport for three features in one product: uploading a 2 GB video, a live cursor showing where each collaborator is pointing, and fetching a page of search results. Pick a transport for each and justify it in one sentence.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
For each, ask what a late piece of data is worth compared with a missing one.
Show a strong answer
- The 2 GB upload — TCP (or QUIC). Every byte matters and none of it is time-sensitive, so ordered, reliable delivery is exactly right; a retransmission costs a moment and saves a corrupt file.
- Live cursors — UDP. A cursor position from 200 ms ago is worthless the instant a newer one exists, so retransmitting it would waste bandwidth to deliver stale data and delay the fresh position behind it. Losing one update is invisible; delaying all of them is not.
- Search results — QUIC if available, otherwise TCP. The data must be complete, but the request is one of many the page makes, so the win is avoiding head-of-line blocking between them and reusing an established connection rather than paying a fresh handshake.
The general rule: reliability is worth its cost when late data is still useful, and harmful when it is not.
Your mobile app's users complain that switching from wifi to mobile data 'kills' whatever they were doing. Explain why this happens with TCP, and what QUIC changes.
Write your own answer first, on paper or in a note. Then compare.
Show a hint
What identifies a TCP connection, and which part of that identity just changed?
Show a strong answer
Why it breaks on TCP. A TCP connection is identified by the four-tuple of source address, source port, destination address and destination port. Moving from wifi to cellular gives the device a new IP address, so the old four-tuple no longer exists. From TCP's point of view the connection is simply gone — not migrated, not paused. The app must open a new connection, redo the TCP handshake, redo the TLS handshake, and restart or resume whatever was in flight. On a mobile network that is several round trips, and any request that was mid-flight fails.
What QUIC changes. QUIC identifies a connection by a connection ID carried in the packets, not by the addresses underneath. When the address changes, the endpoint recognises the same connection ID and continues — no new handshake, no lost state, and in-flight requests survive. This is called connection migration, and it is one of the strongest practical arguments for QUIC on mobile.
What it does not fix: if the new network is genuinely worse, throughput still drops. Migration preserves the connection; it does not conjure bandwidth.
Key takeaways
- Every transport is an answer to what happens when a packet is lost: TCP retransmits and waits, UDP carries on, QUIC retransmits without stalling unrelated streams.
- TCP's handshake, ordering, retransmission, flow control and congestion control give a reliable ordered byte stream at the cost of at least one round trip before data.
- Head-of-line blocking is TCP's guarantee seen from the other side — correct data already received is withheld because something earlier is missing.
- UDP is a different contract, not a worse one: no handshake, no ordering, no retransmission, and the application decides what reliability means.
- Real-time systems prefer UDP because stale data is worthless — retransmitting an expired position costs latency to deliver something already superseded.
- QUIC runs over UDP in userspace and delivers per-stream ordering, 1-RTT (or 0-RTT) setup, connection migration across network changes, and mandatory TLS 1.3.
- Use TCP where every byte matters, UDP where data expires, QUIC for modern web and mobile clients.
Further reading
- RFC 9293, Transmission Control Protocol — the current consolidated TCP specification.
- RFC 768, User Datagram Protocol — three pages, and worth reading in full.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport, and RFC 9114, HTTP/3.
- Van Jacobson, "Congestion Avoidance and Control" (SIGCOMM 1988) — where TCP's backoff behaviour comes from.
- Adam Langley et al., "The QUIC Transport Protocol: Design and Internet-Scale Deployment" (SIGCOMM 2017) — measured results, including connection migration.