HTTP/2 is the successor to HTTP/1.1, bringing significant performance improvements by fundamentally changing how requests and responses are handled.
Let’s see it in action. Imagine a simple web server serving a single HTML page that references several CSS files, JavaScript files, and images.
HTTP/1.1 Scenario:
- Browser requests
index.html. - Server responds with
index.html. - Browser parses
index.htmland discovers it needsstyle.css. - Browser requests
style.css. - Server responds with
style.css. - Browser discovers it needs
script.js. - Browser requests
script.js. - Server responds with
script.js. - …and so on for every single asset.
This sequential, one-request-at-a-time model, even with HTTP/1.1’s keep-alive, leads to a lot of overhead and latency. Each request/response pair involves new TCP connection setup (or reuse), TCP slow start, and header overhead.
HTTP/2 Scenario:
- Browser establishes a single TCP connection to the server.
- Browser sends multiple requests simultaneously over this single connection, broken down into small "frames."
- The server receives these frames, reassembles them into requests, processes them, and sends back responses, also as frames.
- The browser receives these frames and reassembles them into the original responses.
This is the core of multiplexing. Instead of multiple TCP connections, you have one. Instead of waiting for one response before sending the next request, you send many in parallel.
Here’s a simplified view of what happens on the wire:
HTTP/2 Request/Response Flow (Conceptual):
Browser -> TCP Connection -> Server
Request 1 (GET /index.html) [Header Frame, Data Frame]
Request 2 (GET /style.css) [Header Frame]
Request 3 (GET /script.js) [Header Frame]
Request 4 (GET /logo.png) [Header Frame]
Server receives frames, processes requests.
Response 1 (index.html) [Header Frame, Data Frame]
Response 2 (style.css) [Header Frame, Data Frame]
Response 3 (script.js) [Header Frame, Data Frame]
Response 4 (logo.png) [Header Frame, Data Frame]
Browser receives frames and reconstructs responses.
This single TCP connection handles all these bidirectional streams of data concurrently, drastically reducing the overhead associated with establishing and managing multiple connections.
Server Push is another game-changer. Traditionally, the server only responds to explicit requests from the client. With Server Push, the server can proactively send resources to the client that it anticipates the client will need, without the client having to ask for them.
Imagine the browser requests index.html. The server knows that index.html always requires style.css and script.js. Instead of waiting for the browser to parse index.html and then request those assets, the server can push style.css and script.js to the browser along with the index.html response. This further reduces latency because the browser doesn’t have to perform additional round trips to fetch these assets.
HPACK addresses the header overhead. In HTTP/1.1, headers are sent as plain text with every request, often repeating the same information (like User-Agent, Accept, cookies). This can be substantial, especially with many small requests. HPACK is a compression algorithm specifically designed for HTTP/2 headers. It uses techniques like static and dynamic tables to encode headers efficiently, significantly reducing their size. For example, if "User-Agent: Mozilla/5.0…" has been sent once, subsequent requests can refer to it with a small index instead of resending the entire string.
The core problem HTTP/2 solves is the head-of-line blocking inherent in HTTP/1.1. In HTTP/1.1, if a request is slow to process or a TCP packet is lost, it can block subsequent requests on the same connection from being processed, even if those subsequent requests are ready. HTTP/2’s multiplexing, by breaking communication into independent streams, ensures that a slow response on one stream doesn’t block others.
The most surprising true thing about HTTP/2 is how it achieves its performance gains not just by sending less data, but by radically changing the state management between client and server. The multiplexing, server push, and header compression all work in concert to minimize the number of round trips, reduce redundant data transfer, and allow for more efficient resource utilization on both ends. It’s less about raw speed and more about intelligent, parallelized communication.
The next concept you’ll likely encounter is how the browser and server negotiate which HTTP version to use, and what to do when one side supports HTTP/2 but the other doesn’t.