Approaching Lightspeed with HTTP/2 (Part 1)
In 1991, we were introduced to the majesty of HTTP 1.0. At the time it was fine. Well, it was, up until a visit to Ebay.com could result in a flippin deluge of 84 resources being sent to the client.
Serialized What Now?
Why are that many scripts and images a problem? We can blame HTTP 1.0 and its serialized request-response protocol. (Let’s break down that blurb.)
I’m a client. I send a request to the server. They haven’t gotten back to me. Tough luck. I can’t make more requests along a TCP-based connection until I receive a response.
For example, if I ask a server for their index.html, I have to wait until I receive a reply before I ask for styles.css. Now imagine making a request for each resource. 80. Times. Excuse me while I fume quietly in a corner.
That is precisely why bundling javascript or inlining CSS files is a necessary evil. It limits the amount of requests and files sent along the serialized HTTP/1 protocol, but…
- What if we change a single line of the codebase?
- We have to re-bundle, and the user has to redownload the entire monolith of code, ruining caching strategies.
Hence, necessary evil.
Hold the phone. Don’t we already have pipelining with HTTP/1.1?
Well, yeah. Pipelining describes the idea of making multiple requests along a single connection. Voila! This is the answer to our original complication, right?
Not quite… The bottleneck now switches from requests to responses. Notice how in the diagram, the pipelined responses still need to be sent in order. This phenomenon is called Head-of-line blocking, which means that if the first response isn’t ready to be sent off or is rather large, we’ve got a queue of responses being held up by that first response.
SPDY and HTTP 2.0
Google noticed this bottleneck too, and tried to circumvent the problem by testing multiple connections between client and server. More connections mean more concurrent requests, but it’s a double-edged sword, because it also leads to significantly more congestion for servers.
With extensive experimentation, they found the goldilocks number to be 6 open connections. Does that sound hack-y? That’s because it is — the deep underlying mechanisms of TCP are optimized for a single connection, not several.
Eventually, the tech behemoth began development on a networking protocol dubbed SPDY (pronounced Speedy) around 2009: what would become the heart of HTTP/2.
SPDY’s alternative to pipelining would be a technique called multiplexing. It allows us to create both asynchronous requests and asynchronous responses. Without too much nitty gritty detail, multiplexing facilitates better performance, cheaper deployment, and a variety of bonus features like Server pushing, Prioritization, and Flow Control that make HTTP/2 so attractive (which we’ll discuss in the next blog post).
Credit for the content idea goes to Ilya Grigorik of Google and his talk on the ChangeLog podcast. If you have any corrections or comments, feel free to get in touch with me.
