Moving towards HTTP/2
What HTTP/2 is and means to the future of the World Wide Web.
To have accessed this blog post, you first sent a request to medium which then responded initiating the cycle of sending multiple requests back and forth to deliver the content needed for Medium to work.
As a matter of fact, this process happens for every website you visit and actually has a name. The formal definition of this process is called the HTTP request/response life cycle and has been an essential part of the web since it’s early days. However, we’ve started to realize that the life cycle that consists of HTTP/1 requests between both client and server are no longer the most efficient way of handling transactions on the internet, ultimately formulating what we now call HTTP/2. This article won’t talk too much about HTTP/1 or how HTTP in general works, but if you’re not familiar with either that should be okay. This article will simply discuss some basic HTTP/1 concepts, the differences between HTTP/1 & 2, and when we will likely see a standardization of the protocol.
HTTP/1
Formally introduced in 1997, HTTP/1 served as a major foundation to creating the internet we all know and (love/hate) today. Ever since it’s conception however, there has been no major revisions to the actual protocol itself and rather optimizations made on networking hardware that take advantage of how the protocol works.
Well, what’s so bad about it then?
Nothing. There isn’t anything particularly bad about the protocol itself, rather there are some inefficiencies that inhibit the maximum capabilities of the computers we have today. For instance, going back to the HTTP life cycle, your computer had to make multiple TCP connections to process multiple requests simultaneously for correctly loading this page. If you were loading simply just text, this would be okay. As text isn’t inherently large, but instead you’re loading tons of images, CSS, JavaScript, and other asset files in order to properly get this page to work. When your Browser makes all of these requests, your network resources are unfairly allocated to prioritize these TCP connections, slowing down anything you or anyone on your network might be doing over the internet.
It doesn’t stop there though. With multiple requests being issued by the browser, data duplication occurs on the physical data transmission wires. Because of the data duplication occurring, there had to be extra protocols created to handle the extraneous information being sent over the wire without corrupting the legitimate parts of it.
While HTTP/1 has served us greatly for the last 20+ years, it’s lack of capabilities are starting to catch up with it and the extra protocols we build around it are only crutches that address symptoms of the problem, and not the problem itself.
Introducing, HTTP/2
In 2009, Google started a project called SPDY, an open source networking protocol for manipulating HTTP traffic sent “over the wire” to improve the end users overall experience. SPDY aimed to reduce web page load latency and improving web security through data compression, multiplexing, and prioritization. While development continued on the project for another 6 years, in 2015 it would ultimately come to an end as the IETF would release the final ratification of the HTTP/2 standard.
The IETF was very interested in Googles project as it addressed the issues of HTTP by centering the protocol itself around three qualities you don’t normally find within a single network protocol:
- Simplicity
- High performance
- Robustness
So, what is HTTP/2 actually capable of?
Multiplexed streams
In HTTP/1, in order to request multiple resources the browser has to instantiate multiple TCP streams in order to get those resources. As for reasons stated previously, this is extremely inefficient. What HTTP/2 introduces is something called Multiplexed streams. To put it simply, multiplexed streams are exactly what they say they do.
Multiplexed — incorporate into a multiplex signal or system.
Stream — transmit or receive (data, especially video and audio material) over the Internet as a steady, continuous flow.
By Multiplexing the multiple different TCP connections that would have to be opened up through standard HTTP/1 transaction, we allow the HTTP payload to be broken up into frames that are small and independent of any one given frame. Once the information is successfully sent to the client, it can then be reconstructed in the proper order.
This improvement reduces the overall total amount of TCP streams your browser would have to open per website to just one, reducing the overall network resources utilized by your browser.
HTTP/2 Server Push
In the standard HTTP life cycle, Communication would look like this:
Over time, the client initiates the life cycle by sending a request which then the server responds and fulfills the request. In this type of transaction, the server is only allowed to ever send as much as it is requested. This enforces that the client is only allowed to receive all that it asks for, although it will most likely request the same things every time it visits that certain page which is pretty counter intuitive.
Server push allows the server to send additional information to the client that it knows will be anticipated in future requests. The communication would now look like this:
In the example on the left, we can see that an additional request is made by the client to the server to request the CSS. On the right side, the server knows that since the user is requesting an HTML page, it’s going to want the styling that is referenced in it as well. The server then sends the CSS after the html and the client is able to properly load the web page without having to make anymore requests.
Binary protocols
HTTP/1 is known for being a textual protocol, meaning that the way it operates is based off of simplistic text commands like GET and POST to complete the actions that it needs to do. HTTP/2 still uses the same text commands for development, but under the hood will convert those commands to binary for compatibility. While binary may take more energy from a developers standpoint to work with, it’s technological advantages far out weigh it’s disadvantages. More specifically, some of the categories it excels in are…
- Low overhead when parsing binary data
- Lighter network footprint
- Reduced network latency and improved throughput
Stream prioritization
Stream prioritization in HTTP/2 allows clients to specify the preference to what kind of data it prioritizes receiving. However, this has not been fully sorted out with the reason being that stream prioritization has a lot of variables that surround the actual implementation of it. In order for stream prioritization to be beneficial there has to be a widely adopted mechanism for it that will benefit most to all end user experiences. If this were to be finalized today, the benefits could include Reduced time to deliver the most important content first, optimized communication between client and server, and highly effective network resource utilization.
Stateful header compression
Every single request that you send to a web server includes a header that specifies information about the type of request you’re making. As you can imagine, in an HTTP/1 environment where you’re opening up multiple TCP streams you’re also sending a lot of redundant information that has already been specified in other requests being sent to the server. HTTP/2 solution to this is to utilize stateful header compression to compress headers as simply and secure as possible. By compressing every header and then using the compressed header for looking up the fully contsructed version of itself, the transfer size of each stream reduces in size rapidly, allows stream prioritization to still be effective, and reduces the overall amount of resource overhead.
Conclusions and wrapping up
While HTTP/2 is still being formalized, It’s the future of the internet and what appears to be a very promising one. I estimate that we will see a massive shift to HTTP/2 anywhere from the years 2022–2025. I pick this time not because of the standardization process itself, but rather the fact that hardware has been specifically optimized to cater towards the HTTP/1 protocol that enable it to be as fast as it is today. Before we can see any real change, hardware companies are going to need to start looking into ways they can create networking hardware that will allow the protocol to be as effective and as impactful as HTTP/1 has been for us for the last 20 years. Overall, I’m excited to see where the future of the web has to go and the technologies and people that are going to be powering it. Till next time.