We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Api Design Protocols
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Api Design Protocols
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
HTTP/2 solved head-of-line blocking at the application layer. Multiple requests share one connection, interleaved as binary frames. But HTTP/2 runs on , and TCP has its own head-of-line blocking that HTTP/2 cannot fix. If one TCP packet is lost, the entire connection stalls while that packet is retransmitted. It does not matter that the lost packet belonged to Stream 5 and Streams 1 through 4 are complete and ready to deliver. TCP guarantees in-order byte delivery across the whole connection, so everything waits.
On a reliable data center link with 0.01% packet loss, this barely matters. On a lossy mobile network (2 to 5% packet loss), TCP-level blocking erases most of /2's multiplexing benefit. Google's QUIC team measured that on high-loss connections, HTTP/2 could actually perform worse than HTTP/1.1, which uses six separate TCP connections so a loss on one does not block the other five.
Google built QUIC (Quick UDP Internet Connections) starting in 2012, deployed it across Search, YouTube, and Gmail by 2013, and published the IETF standard as RFC 9000 in May 2021. QUIC runs on UDP instead of TCP. Each stream is independently managed at the transport layer, so packet loss on one stream never blocks another. Connection establishment drops from 2 to 3 round trips (TCP handshake plus TLS) to 1 round trip, or zero round trips for returning clients.
HTTP/3 is HTTP-over-QUIC. Same semantics as HTTP/2 (GET, POST, headers, status codes, multiplexed streams), but the transport underneath is QUIC instead of TCP. Chrome, Safari, Firefox, and Edge all support it. Cloudflare, Google, Meta, and most major CDNs serve traffic over HTTP/3. As of early 2025, over 30% of global web traffic uses HTTP/3 according to W3Techs data.
TCP was designed in 1974. It lives in the OS kernel, and changing it means getting every operating system vendor on the planet to ship a kernel update. QUIC sidesteps this by running entirely in userspace on top of UDP. The QUIC library ships inside Chrome, inside your CDN edge server, inside your . Updates deploy in days, not decades.
Independent stream multiplexing. treats the entire connection as one byte stream. If byte 4,000 is lost, the kernel will not deliver bytes 4,001 through 8,000 to the application even though they arrived fine. QUIC gives each stream its own sequence space. A lost packet on Stream 3 triggers retransmission only for Stream 3. Streams 1, 2, and 4 continue receiving data without stalling. This is the single biggest improvement over HTTP/2.
0-RTT connection establishment. A brand-new TCP connection requires a 3-way handshake (1 RTT) plus TLS 1.3 (1 more RTT) before a single byte of application data can flow. QUIC combines the transport and cryptographic handshake into 1 RTT for new connections. For returning clients, QUIC caches session keys and achieves 0-RTT: application data rides in the very first packet, before the handshake completes.
TCP + TLS 1.3: 2 round trips before first data byte
QUIC new client: 1 round trip before first data byte
QUIC returning: 0 round trips (data sent with the first packet)
On a 200ms mobile connection, 0-RTT saves 400ms per new page load. Google reported a 3% reduction in search just from 0-RTT, which translated to measurably higher search volume.
Connection migration. TCP connections are identified by the 4-tuple (source IP, source port, destination IP, destination port). When your phone switches from Wi-Fi to cellular, the source IP changes and every TCP connection drops. The browser has to reconnect, re-handshake, re-authenticate. QUIC uses a connection ID instead of the IP tuple. When the network changes, the connection ID stays the same and traffic resumes on the new path without interruption. Spotify reported that connection migration reduced playback interruptions by 20% during network transitions.