What Changed in HTTP/2 (Multiplexing, Header Compression)

A Limitation in HTTP/1.1

HTTP/1.1 (the version underlying the basic HTTP/HTTPS note earlier in this project) generally processes requests over a connection one at a time - a browser loading a page with many resources (images, scripts, stylesheets) often opens multiple separate connections just to fetch them in parallel, adding real overhead.

Multiplexing: Many Requests, One Connection

HTTP/1.1:  Connection 1 -> Request A
           Connection 2 -> Request B
           Connection 3 -> Request C   (multiple separate connections needed)

HTTP/2:    Single Connection -> Request A, Request B, Request C all interleaved together

HTTP/2 allows many requests and responses to be interleaved over a single TCP connection simultaneously - eliminating the need to open several separate connections just to achieve parallelism, and reducing the overhead each new connection setup would otherwise require.

Header Compression: Reducing Repetitive Overhead

HTTP headers (cookies, user-agent strings, and more) are often very similar across many requests to the same server. HTTP/2 compresses this repeated header information using a dedicated compression technique (HPACK), meaningfully reducing the overhead sent with every single request.

Server Push: Sending Resources Before They're Even Requested

HTTP/2 also introduced the ability for a server to proactively send resources it anticipates a browser will need next - for example, sending a stylesheet immediately alongside the requested HTML page, before the browser has even had a chance to parse the page and request that stylesheet itself.

Why These Changes Meaningfully Improved Real-World Performance

Together, multiplexing and header compression directly address two of HTTP/1.1's most significant real-world performance bottlenecks, which is exactly why HTTP/2 saw such widespread and rapid adoption once it became available.