TCP, UDP, and QUIC

TCP is connection-oriented. A three-way handshake establishes state on both ends, then the protocol guarantees that every byte arrives, exactly once, in order — via sequence numbers, acknowledgements, and retransmission. It also manages flow (the receive window stops a fast sender overwhelming a slow receiver) and congestion (slow start ramps the sending rate up and backs off on loss). Slow start is why a brand-new connection is slower than a warm one for the first few round trips, and why connection reuse matters for performance.

Its cost is head-of-line blocking. Because TCP presents a single ordered stream, one lost packet stalls delivery of everything behind it — even bytes that already arrived. HTTP/2 multiplexes many logical streams over one TCP connection, so a single lost packet stalls all of them. HTTP/2 solved application-layer HOL blocking and could not solve the transport-layer version.

UDP sends independent datagrams with no handshake, no ordering, no retransmission, no congestion control. It is not "worse" — it is the right base when late data is useless. Live video and voice would rather drop a frame than pause for it, and DNS queries are a single small request/response where a connection setup would double the cost. If you need reliability on UDP you build it yourself, which is exactly what QUIC does.

QUIC runs over UDP and provides reliability, ordering, and congestion control per stream, so a lost packet stalls only its own stream. It integrates TLS 1.3 into the handshake, cutting connection setup to one round trip and zero on resumption. Connections are identified by a connection ID rather than the IP/port four-tuple, so switching from Wi-Fi to cellular survives without reconnecting. That is HTTP/3, and the practical wins are largest exactly where networks are worst — mobile, lossy, high-latency.

Because QUIC lives in user space rather than the kernel, it can evolve without OS updates — but it also faces middleboxes that block or throttle UDP, which is why clients keep a TCP fallback.

This is the layer under every "why is HTTP/3 faster" and "why do we still see slow first loads" question, and it explains real behaviour you can observe: why the first request on a cold connection is slow, why one dropped packet degrades an entire HTTP/2 page, and why a video call survives conditions that would stall a download. It also grounds the frontend advice to reuse connections and reduce origins.

• TCP guarantees reliable in-order delivery through sequence numbers, acknowledgements, and retransmission, at the cost of a handshake and connection state.
• Slow start means a new TCP connection ramps up over several round trips, so reused warm connections are meaningfully faster.
• Head-of-line blocking is a transport-level property: one lost packet stalls every HTTP/2 stream sharing that connection.
• UDP is the right choice when stale data is worthless — voice, video, game state, DNS — because retransmission would arrive too late to matter.
• QUIC provides per-stream reliability over UDP, so loss affects only the stream that lost a packet.
• QUIC folds TLS 1.3 into the transport handshake, giving 1-RTT connection setup and 0-RTT on resumption.
• QUIC connection IDs survive an IP change, so a network switch does not drop the connection.
• QUIC is user-space and evolvable, but UDP-blocking middleboxes mean a TCP fallback is still required.