News Ticker

HTTP/2.0: Why Do We Need It?

Introduction

We have been using HTTP/1.1 successfully for the last 15 years so why do we need HTTP/2.0? What is the motivation for the new version of the HTTP protocol? Let’s start by looking at the problems with HTTP/1.1.

I often post about HTTP/2.0 on Twitter. 

Problem with HTTP/1.1

What’s in a Web page?

If you decompose a web page you will see that it consists of many resources: images, CSS style sheets, JavaScript files and so on. All theses resources are loaded and rendered by the browser.

In fact over the last five years, since April 2011, the average size of a top 1000 web page has increased by over 300% to 2101 bytes according to the HTTP Archive and the average web page now loads over 120 resources.

web page resources

How does the browser load a web page?

The browser requests the web page and finds that it requires a number of resources. It then starts to request these resources one at a time.

In the beginning, HTTP/1.0 allowed only one request to be made via a single TCP connection. In HTTP/1.1 this was addressed with pipelining, the browser can make multiple requests

450px-http_pipelining-svg

A request is sent for all the required resources. A request is sent for style_1.css, image_1.pgn and javascript_1.js and the browser waits for the server to respond with the requested resources. The server will respond in the order in which the resources were requested, but what happens if the image returns quickly and the JavaScript takes time to return to the client: the browser must wait until the JavaScript file is returned, the other requested resources are not returned until the server responds with the JavaScript file. This is called: head of line blocking.

Solution to Head-Of-Line Blocking

What are the ways we solved this problem?

Multiple Connections

Multiple connections are set up. On connection one, the browsers loads the style_1.css file on connection two, it loads the javaScript_1.js file and so on. This solution has two main issues.

  1. TCP sockets are expensive to create and
  2. For a given browser there is maximum number of connection per host

Given these restrictions, we looked for a different way to optimize page loading.

HTTP/1.1 Optimisation

Many of the solution devised to address these issue are workarounds to overcome the shortcomings in HTTP/1.1. So what are these hacks?

CSS/JavaScript File Concatenation

Create one large CSS file containing all the site’s styles and one large JavaScript file with all the required dynamic logic, even the page itself could contain all it’s required CSS and JavaScript.

Image Sprite Sheet

The pages icons are contained within one image file and are cut from this it into the separate icons and images.

Domain sharding

Locate the resources on different machines. The style_1.css  on one machine and the JavaScript_1.js on another machine.

Inlined Assets

Resources can be embedded inside the web page. we have seen that the CSS and JavaScript can be embedded but it is possible to embed an image into the HTML as well. The image is base64 encoded and insert it into the web page then when the web page is loaded the code it is extracted and decoded using base 64.

A lot of time is spent encoding and decoding and caching cannot be easily done.

Related Articles

Get an overview of the changes coming in HTTP/2.0 and how these are implemented in Java EE 8. I this article we talk about the specification and the support that will be available in Java 9 and JavaEE 8.

One of the most important developments in JavaEE 8 and Java 9 will be support for HTTP/2. Tomcat 9 supports HTTP/2 but it must be configured to use TLS. Head on over to Configure Tomcat 9 for HTTP/2 to find out how to add the appropriate configurations.

The adoption of HTTP/2.0 has stagnated over the last four months. In this new article, we show how server providers are not migration to HTTP/2.0.

I often post about HTTP/2.0 on Twitter.
%d bloggers like this: