HTTP/3 and QUIC Explained

A Deeper Problem HTTP/2 Still Couldn't Fully Fix

HTTP/2's multiplexing (covered in the previous note) happens over one single TCP connection - but if even one TCP segment on that shared connection is lost, TCP's own ordering guarantee (covered earlier in this project) blocks all the multiplexed requests on that connection from proceeding, not just the affected one. This is known as "head-of-line blocking."

HTTP/3's Foundation: Built on UDP Instead of TCP

HTTP/1.1 and HTTP/2:   built on top of TCP
HTTP/3:                 built on top of QUIC, which itself runs over UDP

HTTP/3 is built on QUIC, a new transport protocol running over UDP rather than TCP. As covered in the UDP note earlier in this project, UDP itself provides no reliability - QUIC implements its own custom reliability and ordering logic on top, specifically designed to solve the head-of-line blocking problem.

How QUIC Solves the Problem HTTP/2 Couldn't

QUIC tracks reliability and ordering per individual stream, rather than for the connection as a whole. A lost piece of data affects only its own specific stream - other streams multiplexed alongside it can continue completely unaffected, genuinely solving the problem TCP's connection-wide ordering guarantee created.

A Secondary Benefit: Faster Connection Establishment

QUIC also combines what used to be separate connection and encryption setup steps into a more streamlined process, often reducing the number of round trips needed before actual data can start flowing - directly improving the time it takes to establish a brand-new connection.

Why HTTP/3 Represents a Genuinely Deeper Architectural Change

Unlike the jump from HTTP/1.1 to HTTP/2 (which kept the same underlying TCP transport), HTTP/3 changes the transport layer itself entirely - a more fundamental shift specifically aimed at solving a problem that couldn't be fixed by improvements at the application layer alone.