HTTP 2 Server Push

A year ago, I posted an article explaining the general concept of HTTP 2.0. Today we can finally use it for building websites as it is now supported by major browsers. This article will focus on HTTP 2.0 - Server Push, from what it is, the problems it solves, how to implement it (using commons.host), how to verify that it works and its impact on your website's performance.

Download the POC from GITHUB

Abstract

In order to explain what HTTP 2.0 server push does, we have to understand the problems associated with its predecessor (HTTP 1.1). We will analyze the intricacies associated with loading assets from an HTTP server and how it affects the performance of websites.

In order for a browser to load a website, it needs to send an HTTP request to retrieve the initial HTML file and once the server sends it back, the browser analyzes the HTML and identifies the other resources (CSS, JS, Images) required to render the web page.

The image above illustrates the process used by HTTP 1.1 compliant server/clients to download all resources required by a website to render.

HTTP 1.1 Issues

Since the browser needs to parse the HTML file for it to fully identify all the assets it needs to completely render a web page, we can conclude that:

The initial HTTP request and parsing of the HTML file blocks the full download of relevant assets.

To make things worst, in order for a browser to send the initial HTTP request (for HTML file) it needs to perform the following tasks:

  • Resolve the DNS of the domain where the website is hosted. (1 Round-trip with DNS server)
  • Undergo a round trip between the web server and client machines to open a TCP socket. (Done for each asset)
  • Transfer is subjected to Payload Weight * Latency * Network Bandwidth factors.

What make things even worst is after the initial HTTP request completes, the browser would have to issue more HTTP request for the additional assets which depends on the dependency graph (Referenced JS, CSS, IMGs, HTMLs via iFrame) and behavior of the downloaded asset. These subsequent assets all have to undergo the same download process like how the initial HTML file was downloaded which results to exponential performance (Nn) deterioration.

Comparing HTTP 1.1 and 2.0 Asset Download Mechanisms

In order to clearly present the problems with the behavior of HTTP 1.1, I created a simple website showing the Eiffel tower's photo with three static JS and CSS files. We would be using this website to perform some observations on the differences between how HTTP 1.1 and 2.0 compliant parties transfer assets over the web.

I have checked-in an HTTP 1.1 and 2.0 version of the test website over a repository in Github. In order to replicate the test in your machine, you can clone or download the repository on your local machine and install the NPM dependencies on both folders.

Diagnosing HTTP 1.1 Issues

If you have successfully installed the NPM dependencies, please run the demo app using http-server on the HTTP 1.1 folder. Once the server is running, browse http://localhost:8080 on Google Chrome and open developer tools and navigate to the network tab.

Google Chrome's network waterfall diagram is used for diagnosing behavior associated with loading assets belonging to a web page. It presents a list the assets retrieved by the browser from web servers to render a web page. Each line in the diagram represents an asset retrieved by the browser. The waterfall bars on the right represents the time taken by the browser to download each asset.

Key Points

  • A longer bar in the diagram signals a longer download time.
  • The position of the bar (Left to Right) in the diagram represents its position in the asset download sequence (Subjected to sorting of the list).
  • The empty space from the left side of each waterfall bar represents the asset is in stalled (Pending) mode.

HTTP 1.1 Analysis

If you pay attention to the diagram, you would notice that there is a single green bar at the start of the diagram and all the remaining bars are plotted after a gap at the end of the first bar. The GAP between represents the time the remaining assets were stalled due to parsing of downloaded HTML file.

The scenario above happens because of the browser's failure to detect the dependencies until it parses the initial HTML and this is the exact problem why HTTP 2.0 server push was formulated.

PS: Please note that the diagram above does not reflect latency factor. The website is hosted on my machine and do expect an inferior performance on websites hosted on remote web servers.

HTTP 2 Server Push

In order to solve the browser's incapacity to quickly detect web page dependencies, HTTP 2.0 introduced the concept of Server Push. Server push is a mechanism that enables web servers to send browsers the list of assets they need to download to completely render a web page.

Testing HTTP 2.0

In order to present the advantages of HTTP 2.0, I will be utilizing Commons Host Server. It is used for hosting web pages on HTTP 2.0 and was built by Commons Host. If you want to perform an identical test on your machine, You can download or clone the source code from Github.

Pre-requisites

In order for you to run the code from the repository above, you would need the following:

  • NodeJS 10+ Installed
  • NPM
  • Google Chrome.

After downloading the HTTP 2.0 folder from the Github repository, you can use the following command to run the web server.

After running the script above on your terminal, navigate to https://localhost:4433. NOTE: HTTP 2.0 enforces accessing websites via HTTPS protocol.

Analyzing HTTP 2.0 Server Push

HTTP 2.0 waterfall diagram of the Paris website.

The waterfall diagram for the HTTP 2.0 web page reveals that the web page's dependencies were downloaded before the end of the initial HTML file's download time (You can read this from the diagram through the translucent blue bars). This signifies the elimination of the idle time wasted for downloading and parsing the initial HTML through HTTP 1.1.

What does the translucent blue bars mean?

The translucent bars in the waterfall diagram signifies the push receive time. This bars are present because the web server pre-emptively pushed the web assets (dependencies) together with the initial HTML file to the browser's cache storage.

How about the solid blue bars?

The solid blue bars represent the push read time. This bars represent the act of retrieval of the web assets stored in the cache of the browser. Since the dependencies are pushed pre-emptively, browsers don't have to open TCP connections to retrieve the asset from the remote server and don't have to wait for the download completion of the initial asset to complete before retrieving the remaining assets.

How did the magic happened?

Thanks to Commons Host, I was able to setup a manifest file that tells the server to pre-emptively push the dependencies of the index.html file on the web browser. You can read more on how to do it from Commons Host Gitlab Page.

Conclusion

HTTP 2.0 Server Push eliminates the time wasted by HTTP 1.1 clients on waiting and parsing of the initial HTML file to download all the web page's dependencies.

Please Support HTTP 2.0 Initiative

My friends and I are currently looking for developers that are willing to volunteer to help in the development of web servers that are capable of HTTP 2.0 server push. This initiative aims to eliminate the need to write manifest files and fully implement server push on protocol level. Anybody interested in helping our noble initiative can contribute in the following ways:

  • Help us write code!
  • Hosting a kick-ass POP server on your house!

Feel free to contact Sebastian Deckers to know how can you contribute to HTTP 2.0 server push initiative!

Why don't you become a web performance specialist?

Comments

Post a Comment

Popular posts from this blog

Microservices: Picking the .NET Framework for your containerized applications.

Image
The objective of this blog post is to explain the factors that should be considered when picking a framework for a .net application that you intend to deploy in containerized fashion. .Net Core Generally, .Net Core is the preferred option when building applications that were intended to be deployed in containers due to the fact that .Net Core is built using modular architecture (.net core app images contains only the dependencies it requires to run). .NET Core apps are packaged using Windows Nano Server which is a far smaller compared to the OS required by the standard .NET runtime (Windows Server Core) therefore producing lighter images (end product of building containerized application). On the image above, you will see an image built for .Net Core app that prompts "Hello World". Please take note of the size of the image (251 MB) as it would be critical to demonstrating the difference of the two frameworks. Download Demo Apps from GITHUB
Read more

API Gateway in a Nutshell

Image
In this article, we will explore what are API gateways, the use-cases that you wanna solve with it and the benefits that you rip out of using them. This will be an introductory post to a series of articles that will showcase API gateway development using ASP.net Core, NodeJS and Docker. Articles in the Series This article belongs to a series of articles that explains the importance of API gateways and how to build them using ASP.net Core. If you're interested to learn more about API gateways, it might be a good idea to spend some time reading the articles listed below. Part 1: API Gateway in a Nutshell. Part 2: Building Simple API Gateways with Ocelot. Part 3: API Response Aggregation using Ocelot Part 4: API Def
Read more

API Gateway: Response Aggregation with Ocelot and ASP.net Core

Image
In the previous article , we've learned how to setup an API gateway using ASP.net Core and Ocelot. This article supplements the previous article by introducing downstream response aggregation through the use of API gateways. You can download the application used in this article by cloning it from GITHUB . Articles in the Series This article belongs to a series of articles that explains the importance of API gateways and how to build them using ASP.net Core. If you're interested to learn more about API gateways, it might be a good idea to spend some time reading the articles listed below. Part 1: API Gateway in a Nutshell. Part 2: Building Simple API Gateways with Ocelot. Part 3: API Response Aggregation using Ocelot P
Read more

Security: HTTP headers that expose web application / server vulnerabilities

Image
Today's blog post will cover how ASP.net response HTTP headers can expose security holes in your web application and servers. The post will also contain steps on how to remove this headers and mitigate chances of getting attacked using C# and ASP.net MVC. Problem When an attacker performs an attack on a web server, the first thing he /she needs to do is to identify the profile of his target. To profile a target web application / server, an attacker would have to perform the following steps: Identify the address of the web application. Identify the OS where the web application resides Identify the type of server (IIS, Apache, etc) that was hosting the web application Identify the frameworks (ASP.net MVC, PHP, JSF) used by the applications After an attacker gathers the following information, the attacker would proceed on using penetration to
Read more