Accessibility Links

Are you ready for HTTP/2?

Post by category
Case Studies
Where did HTTP start and how did it progress?

HTTP is an old protocol; there are no two ways about it. Initially developed in 1991 and the last update occurring in 1999, the past 25 years have been spent reliant on HTTP doing all the donkey work bringing webpages to the user's browser; to put this into context, whenever you visit any website you are creating an HTTP request to a designated web server, and this happens on every single website you visit - seems like hard work right? With websites getting larger with more data-filled pages, the current HTTP just isn't cut out to provide the user experience that we require in 2016; on average, a website uses 2MB of data just to load the home pages!

HTTP/2 actually started life in 2009 when two engineers working at Google had been working on a project; SPDY. The Hypertext Transfer Protocol working group (HTTPbis) of the Internet Engineering Task Force used this work and developed it to a point where HTTP/2 was created, based on Facebook’s recommendation. The initial draft of this was published in 2012 and was almost a straight copy of SPDY with a “stream ID” nomination being the only major difference. SPDY manipulates the traffic in a way that reduces the loading latency of the web pages whilst also ensuring a greater security, and set out to:
• Allow multiplexing to occur, so multiple signals can be merged to create a stream of data across single TCP connections.
• Allow for servers to actively push through responses as opposed to waiting for new requests for each response.
• Allow browsers to recognise and prioritise resources (images, text, links etc) so that the most important resources are sent first.

Despite relative success, SPDY has seen support on modern browsers reduced with Microsoft Edge and Google Chrome having dropped it in favour of the new HTTP/2 protocol, and other browsers including Opera, Safari, and Firefox are likely to follow suit throughout 2016.

Why is HTTP/2 better than HTTP/1.1?
In Layman’s terms, webpages load much faster; data transfer speeds increase by more than 30% when compared to HTTP/1.1. This improvement is due to the creation of a constant steady connection between server and browser rather than the stop-start nature of connecting when the data needs to be transferred. The data is also transferred via binary code instead of text, which means your computer has no translating to do, with binary being the native language. As with SPDY, the multiplexing, ability to push through the servers, and ability to prioritise resources all contribute to HTTP/2 success.

Why is SPDY being dropped in favour of HTTP/2?

SPDY was developed initially to provide an example of how HTTP could be improved, however it was never intended to be a total replacement, and was instead used to provide the foundations for HTTP/2 by increasing and improving data transmission without backwards compatibility being an issue. The main changes between the two are;
• SPDY requires an SSL to encrypt the connection which allows the faster data transfer speeds, but HTTP/2 does not. This is a partially moot difference, as most popular browsers currently require a secure connection.
• HTTP/2 uses faster encrypted connections, as it makes use of a new ALPN extension (Application-Layer Protocol Negotiation) which lets the browser or server determine which protocol to use DURING the initial connection as opposed to afterwards.
• Although both allow Multiplexing, HTTP/2 can allow it to occur with different hosts at the same time, but SPDY can only allow Multiplexing on one host at once.
• In terms of compression, SPDY does leave vulnerabilities during the process but HTTP/2 has introduced “HPACK”. HPACK is a compression format, and allows for more secure and faster compression.

Do I need to change my ways of working?

No. HTTP/2 is backwards compatible with HTTP/1.1 and you would most likely have been using alternative protocols for a number of years with many browsers already supporting both SPDY and HTTP/2. This will change in the future as more servers and browsers are enabled to support HTTP/2, and your current way of working slowly becomes less efficient as optimization towards HTTP/2 takes governance.

There is no defined “launch date” due to most browsers having integrated it already, however you shouldn’t notice a real difference unless you enjoy recording load times for various websites; you will still see “http” or “https” in the address bar. Despite this, if HTTP/2 has anywhere near the longevity that HTTP/1.1 has proven, it will be a staple protocol for the next decade or more and ensures we are able to keep developing our webpages well into the future.
Add new comment