What Are The Differences Between TCP, UDP, And QUIC, And When Should I Use Each

The one question that decides the transport

Every one of these protocols answers the same question differently: when a packet is lost, is a late retransmit better or worse than just moving on without it? TCP always says "wait, retransmit." UDP always says "don't wait, move on." QUIC gets to choose per stream. That single design choice is what determines which real systems can use each one — and it is also where a popular explanation of this topic goes wrong (see the correction below).

TCP — reliable, ordered, congestion-controlled

TCP opens with a 3-way handshake (SYN, SYN-ACK, ACK — 1 round trip) before any application byte moves. Every byte gets a sequence number; the receiver ACKs what it has, and the sender retransmits anything un-acked after a timeout. The receiving application only ever sees bytes in order — if byte 1,000 is lost, bytes 1,001–2,000 sit buffered and unusable until the retransmit of byte 1,000 arrives. That is head-of-line (HOL) blocking: one lost packet stalls everything queued behind it, even other, unrelated HTTP/2 requests multiplexed on the same TCP connection. TCP also runs congestion control (slow start, then AIMD — additive increase, multiplicative decrease on loss), so a brand-new connection ramps up speed gradually rather than sending at full rate immediately.

UDP — unreliable, unordered, the app builds what it needs

UDP sends independent datagrams with no handshake, no acknowledgment, and no ordering. A lost or reordered datagram is simply never fixed by the transport — if the application needs reliability, sequencing, or retransmission, it has to implement that itself (or use a library that does, like RTP for media or a QUIC-style stack). The payoff is minimal latency: nothing waits for a lost packet, because UDP never notices one was lost.

QUIC — HTTP/3's transport, TCP-like guarantees minus the cost

QUIC runs over UDP but re-implements TCP's reliability and ordering itself, per stream, in user space. Two things follow from "per stream": first, a connection can carry many independent streams, and a lost packet only stalls its own stream — other streams keep flowing, so QUIC does not suffer TCP's cross-stream HOL blocking. Second, QUIC folds the transport handshake and the TLS 1.3 handshake into a single round trip (1-RTT for a new connection), and can send data in the very first flight on a repeat connection (0-RTT, using a session ticket from before). QUIC also assigns each connection a connection ID independent of IP/port, so a phone switching from Wi-Fi to cellular can keep the same QUIC connection alive — connection migration, something TCP's 4-tuple identity cannot survive.

Correcting a common myth: what live & VOD streaming actually run on

A widely copied explanation claims Twitch, YouTube Live, and Netflix stream over UDP "so the stream stays smooth." That is wrong. Mainstream streaming — both live and on-demand — is delivered as HLS or DASH: the encoder segments video into small files (2–6 second .ts or .m4s chunks), and the player fetches those files over ordinary HTTP, over TCP (or QUIC/HTTP-3), the same way a browser fetches images. The player deliberately buffers 6–30 seconds of video before playing, which is exactly why a TCP retransmit (tens to low-hundreds of ms) is invisible to the viewer — there's no need to trade away reliability for a stream that isn't actually latency-sensitive at that timescale. Ingest (the broadcaster uploading to the platform) is also TCP-based, typically RTMP over TCP.

UDP is reserved for interactive, sub-second real-time media: video calls, conferencing, and cloud gaming, carried as RTP/SRTP over UDP (what WebRTC uses). There, a dropped frame is concealed or skipped, because a video call cannot afford to buffer 10 seconds waiting for a retransmit — the "worse than a drop" side of the trade-off actually applies. The traced diagram below makes the contrast concrete.

When to use each

Need	Protocol	Why
Web pages, APIs, file transfer, email, databases	TCP	Correctness & ordering matter more than shaving milliseconds; retransmit cost is acceptable.
Interactive real-time media (video calls, cloud gaming)	UDP (via RTP/SRTP, often inside WebRTC)	A late retransmit is worse than a drop; the app conceals/skips loss instead.
Modern web & API traffic where you control both ends	QUIC (HTTP/3)	TCP-like reliability, faster handshake, no cross-stream HOL blocking, survives network changes.
Live & VOD streaming (Twitch, YouTube Live, Netflix)	TCP via HTTP (HLS/DASH), increasingly QUIC/HTTP-3	Segmented delivery already buffers seconds of video, so it can afford — and benefits from — full reliability and CDN caching.

Pitfalls

• Equating "real-time" with UDP. Live streaming is real-time content, but it is not real-time delivery — the player buffers 6–30s, so ordinary TCP/HTTP delivery works fine and is what's actually deployed.
• Forgetting ingest. The broadcaster-to-platform leg (RTMP) is TCP-based too — it isn't only the viewer-facing leg that avoids UDP.
• Assuming raw UDP gets you QUIC's guarantees for free. Plain UDP has no reliability, ordering, or congestion control — QUIC's guarantees come from a full protocol built on top, not from UDP itself.
• Thinking HTTP/2 solved head-of-line blocking. HTTP/2 multiplexes streams but still runs them all over one TCP connection, so one lost packet still blocks every stream on it; only QUIC/HTTP-3 fixes this.

Judgment layer: choosing the transport

• Bulk/API/web (TCP) — use it when correctness must be exact and the workload isn't latency-critical at the sub-second level. Trade-off vs QUIC: TCP is simpler, universally supported, and needs no extra library — but it pays a full handshake and is exposed to HOL blocking.
• Interactive real-time (UDP via RTP/WebRTC) — use it when a stale retransmit is actively worse than a drop (calls, gaming). Trade-off vs TCP: much lower, more predictable latency, but you must build your own loss concealment/jitter buffer/FEC — there is no free reliability.
• Modern web (QUIC/HTTP-3) — use it when you control (or can influence) both client and server and want TCP's reliability without its handshake and HOL-blocking costs, plus resilience to network changes on mobile. Trade-off vs TCP: some middleboxes/firewalls throttle or block UDP, forcing a TCP fallback, and QUIC costs more CPU (crypto and congestion control run in user space) — but for latency at web scale it's usually a net win, which is why Google, Meta, and Cloudflare have shipped it broadly.
• Live/VOD streaming (TCP-based HTTP, HLS/DASH) — use it because buffering already hides jitter, so you get exact byte delivery (no visual artifacts) and reuse ordinary CDN/HTTP infrastructure, instead of building custom UDP streaming plumbing that only pays off for sub-second interactivity you don't actually need here.

Takeaways

• The transport choice hinges on one question: is a late retransmit better or worse than a drop, for this workload?
• Mainstream streaming (Twitch, YouTube Live, Netflix, live sports) is delivered as segmented HLS/DASH over HTTP/TCP (or QUIC) — not raw UDP; UDP is reserved for interactive real-time media like calls and cloud gaming.
• QUIC is HTTP/3's transport: TCP-like reliability per stream over UDP, with a combined 1-RTT (or 0-RTT) handshake and no cross-stream head-of-line blocking.
• Name the actual constraint before picking a protocol: correctness (TCP), latency-over-completeness (UDP), or both at once (QUIC).

---

Re-authored for this guide, correcting a factual error in an earlier version of this page that claimed Twitch, YouTube Live, and Netflix stream over UDP — mainstream live and VOD streaming is HLS/DASH over HTTP/TCP (or QUIC/HTTP-3); only interactive real-time media (WebRTC calls, cloud gaming) uses UDP/RTP. Follows the TCP/UDP/QUIC RFCs (RFC 9000 for QUIC) and HLS/DASH/WebRTC delivery practice. See also: TCP Deep — Congestion Control & Head-of-Line Blocking, The Layered Network Model.

I just read a lesson on **What Are The Differences Between TCP, UDP, And QUIC, And When Should I Use Each** (System Design) and want to truly understand it. Explain What Are The Differences Between TCP, UDP, And QUIC, And When Should I Use Each from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **What Are The Differences Between TCP, UDP, And QUIC, And When Should I Use Each** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **What Are The Differences Between TCP, UDP, And QUIC, And When Should I Use Each** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **What Are The Differences Between TCP, UDP, And QUIC, And When Should I Use Each** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.