What is HTTP/2 and it’s benefits

Table of Contents

Introduction To HTTP1.1 and HTTP/2

If we want to talk about how HTTP/1.1 changed into HTTP/2, we should take a quick trip back to the 1990s. HTTP was a simple protocol for getting files from a web server to your computer. This was because the first websites were pretty simple and mostly used text documents with just a few pictures.

HTTP was used to transfer “hypertext” documents in the early 1990s. These were HTML pages with style and hyperlinks. Text and visuals predominated. By 1996, most agreed on version 1.0. This version was elegant and straightforward for the internet demands of the mid-1990s: connect, download, close.

Things altered by the late 1990s. More and more, it was evident that the web was becoming more than a worldwide version of “Choose Your Own Adventure” More people acquired items, therefore protecting them became crucial. People wanted more than simply images. They wanted to view movies, update papers, and send animated greeting cards online. “One connection, one file” was too sluggish for new apps.

In 1999, HTTP 1.1 was released by the w3c, which oversees managing the HTTP standard. This change to the 1.0 standard was just a temporary fix to help web servers run faster on the “hypermedia” web of the future.

Then, the new ideas kind of stopped coming. You probably know that the web changed a lot from 1999 to 2015, but for those 16 years, we made do with the old HTTP/1.1 standard, fitting more and more advanced apps into its small space.

Development milestones

Date	Milestone
December 20, 2007	First HTTP/1.1 Revision Internet Draft
January 23, 2008	First HTTP Security Properties Internet Draft
Early 2012	Call for Proposals for HTTP 2.0
October 14 – November 25, 2012	Working Group Last Call for HTTP/1.1 Revision
November 28, 2012	First WG draft of HTTP 2.0, based upon draft-mbelshe-httpbis-spdy-00
Held/Eliminated	Working Group Last Call for HTTP Security Properties
September 2013	Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard
February 12, 2014	IESG approved HTTP/1.1 Revision to publish as a Proposed Standard
June 6, 2014	Publish HTTP/1.1 Revision as RFC 7230, 7231, 7232, 7233, 7234, 7235
August 1, 2014 – September 1, 2014	Working Group Last call for HTTP/2
December 16, 2014	Submit HTTP/2 to IESG for consideration as a Proposed Standard
December 31, 2014 – January 14, 2015	IETF Last Call for HTTP/2
January 22, 2015	IESG telechat to review HTTP/2 as Proposed Standard
February 17, 2015	IESG approved HTTP/2 to publish as Proposed Standard
May 14, 2015	Publish HTTP/2 as RFC 7540
February 2020	RFC 8740: HTTP/2 with TLS 1.3

A Look at the Change from HTTP/1.1 to HTTP/2

Before HTTP/2 came out in 2015, HTTP/1.1 had already reached its limit. In fact, Google has been working on its own replacement for HTTP/1.1 since the early 2010s. It’s called SPDY (which is pronounced “speedy”). This protocol used the framework that had already been set up for HTTP/1.1, but it changed how the framework handled requests. SPDY could download multiple resources at once over a single connection by using multiplexing. By adding a translation layer, it could also be “back-ported” to applications that were already in use.

Google is a natural leader in this area because they have been making web-based programs like Gmail and Google Apps that work more like desktop software than websites. Because SPDY was so well-designed, HTTP/2 is based on it.

Because of this, all of the major browsers now support HTTP/2, which is based on SPDY and was officially approved by w3 in 2015.

How HTTP/2 Outperforms HTTP/1.1 in Speed

Nowadays, the concept of “webpages” is about as dated as the concept of “videotaping” anything on a smartphone. Modern websites, like modern apps, need a constant two-way flow of data to do their main jobs.

When you type in a Google Doc, like I am doing right now, data is sent to Google’s servers. After you send the information to Google’s servers, your browser will get updates with the text you entered, as well as suggestions, the latest status of the document’s changes, and more. When you use HTTP/1.1, every time you hit a key, a new connection is made to the server, and the character you type is sent. If you added the character you see on your screen, your browser would have to repeatedly “ping” Google’s server to see how the document is doing. There are a lot of links to keep up, and each one takes time.

A closer look

HTTP/2 allows two-way streams over a single connection, unlike prior protocols. Your browser constantly requests new information from Google’s server. No need to “send data,” “wait for a response,” “refresh the screen,” etc. All at once. A Google Doc or comparable online “document” may update so often it seems like a computer program.

These are some of the high-level differences between HTTP1 and HTTP2:

Unlike its predecessor, HTTP1, HTTP2 uses binary data instead of text.
HTTP2 is fully multiplexed, as opposed to ordered and blocked.
1. Parallelism in HTTP2 may be achieved through the use of a single connection.
By shrinking headers, HTTP2 saves money.
Servers can “push” responses to client caches in advance using HTTP2.

A closerer look

Multiplexing:

When using HTTP/1.1, resources are loaded sequentially; if one fails to load, it prevents the loading of subsequent ones. HTTP/2, on the other hand, may transport many streams of data over a single TCP connection, ensuring that no single resource is blocking any others. As a result, HTTP/2 segments data into binary-code messages, each of which is assigned a number that identifies its stream within the client.

Server push:

A server only sends information to a client when the client asks for it. This strategy doesn’t always work for modern websites, where the client may have to ask for dozens of resources. This problem is fixed by HTTP/2, which lets servers send information to clients even before they ask for it. As if Bob had sent Alice a Table of Contents for his book before sending it, the server also sends a message that tells the client what to expect in the push.

Header compression:

Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet. Given the volume of HTTP packets involved in loading even a single webpage, those bytes add up quickly, resulting in faster loading.

The Case for Migrating to HTTP/2

One of the most common and important suggestions most agencies make during technical audits of websites is to switch from HTTP/1.1 to HTTP/2. We can often improve a website’s functionality by a lot with little work and money.

Perhaps your firm isn’t very dynamic. Like the early days of the internet, maybe most of your pages are mostly just text and pictures that don’t change. This is great, and HTTP/2 is an easy win for you. If you change your hosting to use HTTP/2, all of your page’s content will come down the pipe on one connection instead of many. This will speed up the delivery of your content to users by a lot.

If we use Google’s Lighthouse to test a website, the tool doesn’t even provide ideas to improve your HTTP/1.1 delivery; instead, it just advises to update to HTTP/2, suggesting that this may be a pass/fail test in Google’s algorithm.

Server software

Apache .. supports HTTP/2 via the module mod_h, although appropriate patches must be applied to the source code of the server in order for it to support that module As of Apache . all patches are included in the main Apache source tree, although the module itself was renamed mod_http. Old versions of SPDY were supported via the module mod_spdy, however the development of the mod_spdy module has stopped.
Apache Tomcat supports HTTP/2 with version . and newer with a configuration change.
Apache Traffic Server supports HTTP/2.
Caddy supports HTTP/2.
Charles Proxy supports HTTP/2 since version Charles .
Citrix NetScaler .x supports HTTP/2.
Sucuri Supports HTTP/2.
F BIG-IP Local Traffic Manager . supports HTTP/2.
Barracuda Networks WAF (Web Application Firewall) supports HTTP/2.
ho was built from the ground up for HTTP/2 support.
HAProxy . supports HTTP/2.
Jetty . supports HTTP/2.
lighttpd .. supports HTTP/2.
LiteSpeed Web Server . supports HTTP/2.
Microsoft IIS supports HTTP/2 in Windows , Windows Server , and Windows Server .
Netty . supports HTTP/2.
nginx .. supports HTTP/2, released on September , , using module ngx_http_v_module and HTTP/2 Server Push since version .. on February , .
Node.js Stable support since … (. supports HTTP/2 with a module and Node . introduced experimental built-in support for HTTP/2.)
Kestrel web server for ASP.NET Core supports HTTP/2 since .NET Core ..-preview .
OpenLiteSpeed .. and .. supports HTTP/2.
Proxygen supports HTTP/2.
Pulse Secure Virtual Traffic Manager . supports HTTP/2.
Radware Alteon NG supports HTTP/2.
ShimmerCat supports HTTP/2.
Vert.x . supports HTTP/2.
Warp (Haskell web server, used by default in Yesod) supports HTTP/2.
Wildfly supports HTTP/2.
Envoy proxy supports HTTP/2.

Here’s a little more information on implementations

https://github.com/httpwg/http2-spec/wiki/Implementations

What is HTTP/2 and it’s benefits