Boost Web Application Performance with HTTP/2 and Server-Push

HTTP/2

In February of 2015, the IETF’s steering group for publication as standards-track RFCs approved the HTTP/2 and associated HPACK specifications.

http2-graphic

After more than 15 years, the Hypertext Transfer Protocol (HTTP) received a long-overdue upgrade. HTTP/2 is largely based on Google’s experimental SPDY protocol, which was first announced in November 2009 as an internal project to increase the speed of the web.

Benefits of HTTP/2 over HTTP/1

At a high level, HTTP/2:

  • is binary, instead of textual
  • is fully multiplexed, instead of ordered and blocking
  • can therefore use one connection for parallelism
  • uses header compression to reduce overhead
  • allows servers to “push” responses proactively into client caches

image_1

Apache HTTP/2 Web Server Setup on Ubuntu 14.04

Prerequisites

To upgrade an existing Apache system to use HTTP/2, follow these simple instructions:

The above commands add the latest apache2 repository to your system and updates the list of available packages your system is aware of.

Enable the http2 apache mod.

Edit your Apache2 virtual host configuration to include the Protocols directive.

Server Push

Server push is a simple way of sending file updates to a browser. It is not true streaming, though it can feel a lot like it when done well. It is quite different from AJAX/XMLHttpRequest or equivalent techniques, because the browser does not need to keep asking for updates. Instead, the server tells it when there is an update, and sends it to the browser.

It is most commonly used in Webcams, to serve a new image to the browser every few seconds, without the browser needing to check if an updated image is available.

Apache 2.4.18 has been released with support for Server Push. To use HTTP2’s server push features with Apache, you must add a Link header to your response. When a Link has the rel=preload attribute, it will be pushed as long as the browser supports it.

How Server Push works

The process is very simple. When the browser requests a file (typically an image), the server responds with a multipart mixed-replace content type header, instead of the normal MIME type for the file, as follows:

(In reality, a much longer boundary should be used, to avoid the possibility that one of the files served as data could contain the boundary, written on its own line after a blank line, with two dashes before it.)

The server never closes the connection, always pretending it has not finished sending the content to the browser. Whenever the server has some data to send to the browser, it sends the boundary, preceded by two dashes, with a blank line before it. It then sends the correct content-type header, followed by a blank line, followed by the data for that frame. Apart from the MIME type of the initial header, this is the same approach as used by MIME email to include attachments.

Since the server never properly ends the content, the browser remains connected to it, waiting for more data to arrive. Each time the browser receives the data for a frame, it uses that to replace the previously displayed content.

If you have a suggestion or issue with the above commands, please leave a comment below:

Comments