What is HTTP2

All you need to know about the HTTP2 protocol

The technology that drives the internet is an ever evolving, mutating, complicated mess. The internet doesn’t exist today as it was meant to exist when it was created more than two decades ago. Surely, in another two decades, it’ll look completely different than it does today. So, it’s not complicated to understand why we have to constantly revise and change the technology that drives the internet. One of those most recent changes has been the new HTTP2 specification.

What is HTTP2?

Before we begin to explain what HTTP2 is, we need to understand what HTTP is. HTTP has been revised multiple times since its introduction and standardization. Though the internet requires multiple technologies to work, HTTP is the tech standard that we use to construct, organize, and send information web pages and information from one computer (a web server) to another computer (your laptop).

HTTP2 is a subsequent protocol revision of the older HTTP 1.1 specification. HTTP2 was standardized and implemented in 2015. It’s important to note that HTTP2 is not a full protocol revision itself, but it’s more of an add-on to HTTP 1.1.

HTTP2 offers a number of improvements in HTTP1.1. All of those improvements build on network efficiency and security, though. Hence why HTTP2 is more of an add-on to HTTP1.1 and less of a replacement protocol. HTTP2 still depends on things like the GET and POST commands as well as the standards to draw and render a webpage.

HTTP2 does have competing protocols. Its main competitor is SPDY (pronounced speedy) released by Google. SPDY was released before HTTP2, but HTTP2 has become an international standard. Both protocols have similar benefits.

How does HTTP2 work?

HTTP 1.1 is an insecure resource hog. There are no two ways around that. It was built for a different era of the internet which had different requirements. Because of that, we’ve had to hack the HTTP protocol to pieces to make things work the way we needed them to. That’s how we ended up with things like cookies. HTTP2 fixes some of those issues.

The first big benefit HTTP2 adds is the ability to use a single TCP connection to send and receive multiple pieces of data. Traditionally a single TCP connection could only be used for a single resource request. That means every time you requested an image, a font file, a CSS file, etc… your web browser needs to make a new TCP connection to the web server. A single website today can require hundreds of different resources. If a new TCP connection is required every time your web browser needs to request another resource, your internet connection is going to get flooded quick. This issue is only compounded on the web server as the web server is providing resources to multiple clients.

Instead of requiring a single TCP connection for each resource, HTTP2 allows the same TCP connection to stay open and keep being used for multiple resources. This lowers the network and system resources needed by both the client and the web server. As another benefit, the HTTP2 protocol makes this a multiplexing connection so data can go both ways simultaneously.

HTTP2 built on that idea and also started streamlining resource requests with a sort of prediction understanding. With HTTP1.1, a web browser wouldn’t request a resource until it understood it needed it. HTTP2 resolves this by allowing a website to prefetch data. A single line of code can tell a web server that X data is going to be needed later in the webpage. So, the web server sends X data along with everything else so the client can cache that data and use it later on.

The efficiencies HTTP2 offers only builds on top of that notion of streamlining data. Engineers realized long ago that they could compress the contents of a webpage to transport it across a connection in a smaller file. This certainly made huge improvements, but the header of a request couldn’t be compressed, only the contents. HTTP2 not only combines large chunks of data together with stateless, multiplexing connections and caching, but it can also let you compress the headers of requests. This means that a web server can combine a large amount of data together, compress it all together to save more space, send it over one connection, and compress the entire request into one small, well-wrapped package.

Why should I switch to HTTP2?

HTTP2 has huge benefits. I encourage every system admin to update their web servers to use HTTP2 as soon as possible if it hasn’t already been done. It’s an easy process with huge returns on investment and time. Let me tell you why.

First, HTTP2 is fully compatible with HTTP1.1. You won’t break anything by implementing it. If a client or website isn’t compatible with HTTP2, then the web server falls back to HTTP1.1 with no issues.

Second, your webservers will respond faster which means that websites will load quicker on people’s PCs. People have the attention span of a goldfish. It’s proven that websites only have a few seconds to capture someone’s attention before they lose interest and move on. The quicker you can get your website in front of the reader, the better. Whether you own and operate your own web server for your own website, or you are a managed host provider, it makes sense to make sure your web server can load websites as fast as possible.

Third, HTTP2 reduces operating and expenditure costs. Your network won’t need to be as robust. You’ll be able to do more with the resources you already own. Your hardware requirements won’t increase as quickly. Your network won’t get as saturated. In every possible way, the cost of running and serving a webpage is reduced with HTTP2.

Finally, we have better security. Security is a huge concern. We will see more legislation regarding network security and personal data security in the future. It’s not a matter of if, but when, it will happen. It will be up to the business to adhere to those laws and protect personal information. Though we didn’t touch too heavily on it in this article, HTTP2 integrates with TLS much more heavily then HTTP1.1 does. If you can offer better security with very little overhead, why wouldn’t you do it?