Just by simply looking at the title, an obvious question might come up in your mind, life is so beautiful with REST over HTTP/1.1, why are we even talking about changing it? In order to address this question, let’s take a step back to see how things have changed over the years in the software world.
The original design goal of HTTP was to be a protocol which can facilitate a document retrieval system for the web. The widely deployed and most prevalent HTTP version (i.e. HTTP/1.1), came to life in 1997, that was 20 years back. So much has changed on the web since then and it’s very far from what it used to be at that time. Average page size has quadrupled in these year and we have started building all sorts of crazy things using web and REST over HTTP.
Although HTTP/1.1 has served us well for so many years, it definitely not the most efficient way to build modern systems. Some of the drawbacks with using HTTP/1.1 are:
TCP Slow Start: HTTP is an application layer protocol and it relies on TCP to manage connections and reliable message delivery. TCP itself carries some bagage with it’s design to ensure reliability and optimal network usage:
- Three way handshake, which happens at the start of the TCP connection and involves 3 packets (SYN-SYN+ACK-ACK) exchange between both the ends of the connections.
- To avoid overwhelming the network with too many packets causing network noice, instead of bombarding the network with the full capacity of network adaptor, number of packets are slowly increased to reach to the optimal level.
This is an over simplification, exact implementation is quite involved but not important for this discussion. The point being highlighted here is creating a TCP connection is a costly affair, if done too frequently or too many times.
Per Domain max connection limit: Browsers typically impose a limit on the max number of connection a web app can open to the same domain. The actual number varies based on the browser, but it’s somewhere in the range 6-10 connections. Once again the point being made is too many HTTP requests, involve too many connections which result in the waiting period because of this limit.
Request Pipelining and Head of the Line Blocking: HTTP/1.1 allows clients to pipeline multiple request on the same connection, without fully receiving the response for the first request. Now this might sound a big improvement but in reality it has issues. What if the first request sent in the pipeline take way too much time for the server to respond? In that case even though client has promptly sent several requests in the pipeline, it’s of not much use since the whole pipeline is being blocked by the request which is taking too much time. This behavior is called “Head Of The Line Blocking”.
HTTP Headers: HTTP headers are verbose, repetitive and eat up a lot of bandwidth being shuttled back and forth alongwith each request. This is undoubtedly sub-optimal.
Text Based Protocol: HTTP protocol is text based, it means while parsing the request we need to check and wait for the separators/de-limiters as opposed to binary protocol where we can do the parsing using mem-copies and byte counts. Text based parsing is quite slow as compared to binary
No Two Way Communication: HTTP works on request/response model, where client opens the connection, request a resource and receives the response. There is no built in way for servers to send messages without clients asking for it. To achieve this currently we resort to WebSockets/Long Polling/Server Sent Events/Forever frames or similar methods, and most of them are nothing more than a hack.
HTTP/2 standard got finalised in 2015, so it’s been close to two years already since it came to life.
All the major browsers are already supporting HTTP/2, a substantial part of the web we interact with on the daily basis is already using HTTP/2. Let’s see what it is and what it offers.
HTTP/2 solves all the problems mentioned above:
Binary Frame Based Protocal: It is a binary protocol, where the smallest logical unit on the wire is called a
frame. A frame typically has a header section and an optional payload section. header section carries the type, flags, stream identifier and lengh information. Some of the important frame types are: Header Frames, Data Frames and Setting Frames.
Enforces SSL/TLS: HTTP/2 is an upgrade protocol, that means the communication/handshake starts with a different protocol and then upgrades to HTTP/2. There are two ways this upgrade can happen:
ALPN (Application Layer Protocol Nagotiation): In this case, handshake happens on SSL/TLS layer, where
h2protocol is send to the other party in the
ALPNextenstion of TLS. This is what’s supported by most of the browser, hence if you want to use HTTP/2 then you have to use SSL/TLS.
h2c: There is another clear text version of protocol upgrade mechanism. In this case handshake information is sent in HTTP/1.1
upgradeheaders. Most browsers do not support this and might not be supporting it even in future.
Streaming and Multiplexing: One connection can be used to multiplex several requests/response in parallel using streams. Each request/response can be mapped to a stream which is composed by multiple frames and each frame has the stream identifiers associated with them. This allows both ends of the connection to interleave frames from different streams, which avoids the Head Of the Line blocking issue.
HPACK Headers Compression: We are familiar with the gZip compression for the request body, but HTTP/2 also enables compression on the HTTP headers using
HPACK. This is really cool.
Two Way Communication and Server Push: HTTP/2 enables servers to send data to clients without clients asking for it, using
websocketsmight not be as cool as they are currently, probably it’s too soon to say this, only time will tell.
What does it change for the Web Developers
Not much actually, since HTTP/2 still follows the exact same semantics as HTTP/1.1, in fact as far as your application is concerned, it’s still dealing with the same HTTP request verbs/headers and what not.
What it does going to change is
PERFORMACE, it’s like just turning the nob to tap out the performance. Also some of the best practices (or hacks) like image spriting, concatenating style, js files, inlining etc might not yield into a different result.
Migrate to HTTP/2 as soon as you possibly can, it’s has only good things to offer without you putting in too much effort.