Last week, I had to reconfigure my workplace’s Computer and after finishing installing the usual software needed Microsoft Office, Acrobat Pro etc. The time came to install a Web Browser and something that I read back in February caused me to halt and thought for a while. What I read was about HTTP/2, the successor of HTTP/1.x which is based on SPDY. I remembered reading, that in order to test the new protocol you had to use Google Chrome’s Canary channel and since I never got the time to try it before, it was the perfect time now and so did I.
Canary was installed and since I had no idea how to enable the feature, a quick search about it provided me with required knowledge. Here’s how:
But little did I knew that Google Chrome has had HTTP/2 enabled by default since a while now until I found out that even my colleague has been enable to test it on this standard Chrome browser. Okay I am all set to test HTTP/2! Now all that I need is to find a server that supports HTTP/2 to connect with. This is where Akamai became one of my friend. For those who don’t know, Akamai is a Content Delivery Network or CDN. It is used by various websites to store and deliver files such videos, images, audio and other data. By the way, Facebook also uses Akamai servers partially.
Akamai has implemented HTTP/2 on a limited beta but does provide a little demo site which allows you to compare the two protocols in terms of latency and loading time.
This is the demo loaded using an ADSL connection of 1 Mbps:
See the different values of load time? Notice that HTTP/2 is 24.14 percent faster than HTTP/1.1 with loading time of 9.40 and 38.93 seconds respectively. Interesting right? However, if you look further, you will notice that HTTP/2 has a greater latency than HTTP/1.1 why? I don’t have a concrete explanation but my best speculation is that since HTTP/2 uses Header Compression with HPACK, the amount the time that the servers take to compress the headers is what adds to the latency time.
Something however, sounded a bit fishy. The address bar of the browser didn’t change to anything like http2:// but stayed the same typical http:// we used to know. So stupid as it seemed, I did check the code of the website to see if the HTML communicates with the server in a different manner and not surprisingly; no! Euh… this is not another version of HTML anyway its HTTP/2 an improved protocol. Silly me! So I decided to go the official page of HTTP/2 to find more details and Tada…! There is the answer:
“HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.”
This is clear, no one should expect to see the protocol on their address bar change when accessing a HTTP/2 compatible website. It’s just the way the communication happens that has changed. Besides Header Compression, one the principal reason of improvement behind HTTP/2 might be that it uses only one TCP connection compared to HTTP/1.x on which browsers may open up to eight connection per origin causing an overflow. Another feature that speeds up web respond is Server Push, “Server Push allows the server to avoid […] round trip of delay by “pushing” the responses it thinks the client will need into its cache.” You will find more information about HTTP/2 and its improvement on their FAQ page.
Wait that’s not all. In order to look deeper into the functioning of the demo site, I started a grabber project using Internet Download Manager which allowed me to download the whole demo website at http://http2.akamai.com/demo/ and what I found was stunning!
The Globe picture which loads in the demo site is not a picture but a lot of pictures together, 378 precisely. 378 tiny tiles that are put up together by a frame to form the beautiful planet earth Globe.
What could this mean? This can only show that HTTP/2 has great powers. Your browser has to request 378 images from Akamai’s servers. Loading one single image is one thing and using several tiny images is another. This shows that HTTP/2 will really improve the way we experience the web.