What’s the fuss about HTTP/2

Wednesday, September 23, 2015

Fundamentals of HTTP and the problems with the existing HTTP protocol

Hypertext Transfer Protocol (HTTP) has been around since the bubble of the World Wide Web and we’re all familiar with it. Whenever we access a website, the HTTP request-response protocol sends out a message to the server to say, “I wish to see content on this site, please send it to me”. That’s when the respective servers start replying by displaying all HTML files and other contents back to you.

These days, the logic behind HTTP runs almost instantaneously. In fact, on average a website needs to load at a lightning speed of under 3 seconds to be considered ‘fast’ according to a study by PerTestPlus Inc. Most developers achieve this speed loading target by site optimization through enabling compression, minifying CSS, JavaScript, HTML and more i.e reducing the file size of the website.

However as we browse the internet daily and feed on tons of information, we demand faster if not extreme loading speed. From a users’ perspective, 0.1 seconds is the response time for ‘instantaneous’ speed – this means 3 seconds loading speed may be fast, but definitely not fast enough for the human eyes. But with so many dynamic contents being displayed across websites, site optimization has its limits and HTTP/1 has finally shown is true maximum capacity in relaying messages.

Speed up with HTTP/2

In February 2015, HTTP/2 was introduced and approved by Internet Engineering Steering Group (IESG) – a committee that provides final technical review of Internet standards – promising faster loading speed. HTTP/2 is based on Google SPDY (pronounced as ‘speedy’) and offers improved performance with better use of network resources.

See how HTTP/2 speeds things up:

Textual Binary

Only one request between connection at a time

Multiple request and response messages at the same time

Browsers open 4 to 8 connections per orgin

Browsers open only one connection for parallelism

Existing TCP Slow Start Mechanism causes headers to load several rounds

Uses header compression to reduce overhead

Requires response from server before content can be sent out

Allows servers to “push” content without waiting for browsers to examine the first response

Encryption with the new HTTP/2

Transport Layer Security (TLS) or Secure Socket Layer (SSL), a security protocol for encrypting messages over the internet has lasted for as long as HTTP/1. With SSL/TLS, HTTP becomes HTTPS and this secure form has worked well over the past 20 years to secure private information.

With HTTP/2 however, TLS is not a requirement in its standards but its higher performance can make encryption easier. Major web browsers such as Google Chrome and Firefox have stated that they only support HTTP/2 with TLS, which makes encryption de facto mandatory.

As we shift towards HTTP/2, it is important for site owners to regularly check if their SSL certificate is still compliant and supported by these browsers. After all, browsers is the software application that displays the https security protocol such as the green secure padlock, not the standards. As always, web visitors should continue to trust sites that are only certified by a trusted Certificate Authority for the most up-to-date compatibility.

ashleeAbout Ashlee Ang

Ashlee is a content writer at Cyber Secure Asia where she writes about introductory topics on cyber security and cyber-related happenings in Singapore & South East Asia.

Share :    

Back to Blog