Introduction:
HTTP has been since a long period. Now the amount of data transferred for a single page has been tripled. We are using HTTP for various things other than what is was designed it for. Design choices make complete sense back then, are now becoming a burden both in terms of development and performance. Some of the current best practices like concatenating all your javascript into a single file solely exist to workaround the shortcomings of HTTP/1. this is where HTTP/2 comes in, being backward compatible it solves the biggest issues which HTTP 1 has. We will now see how HTTP/2 is different from HTTP/1 and how these differences adds effectiveness to our requests.
HTTP/1 problems:
HTTP/1 doesn’t work well for the increasing number of requests. Let us see some of the problems related to it.
- Head Of Line blocking:
HOL means when one request blocks others from completing. A browser can open six connections simultaneously to the same server, that means six requests can be in flight simultaneously. A round trip time for sending a request and receiving a response can take upto 20-50ms. Lets do a quick math, think of a site needs to send 100 requests, we can handle six requests in parallel, hence 100/6=17 requests per connection is needed, each request needs a round trip time averaging 35ms, which yields 525ms. This means around half a ms of doing nothing just for sending and receiving, this time might increase for large file data. HTTP/2 has overcome this problem.
- Uncompressed headers:
A lot of websites compresses assets using gzip or various other compression algorithms. This model compresses the data sent and received, but what about the headers? The headers are simple data which gives us the kind of request and responses, and most of the headers repeat a lot of times. In google research papers state that on an average, headers take up about 800bytes. Lets take a look at the potential savings we could have. If a site needs 100 requests, then 800 bytes * 100 = 8Kb of data would be eaten up by the headers itself and as said most of that would be redundant. We could save a lot of space if we could compress the headers. This is not supported in HTTP/1, but with HTTP/2 we can.
- HTTP/1 Security:
E-commerce has become the norm, handling sensitive data like credit cards and contracts. Its fair to call it gross negligence if websites handled this kind of data without TLS. That’s why TLS is the required part of specification in HTTP/2. There is an un-encrypted version of HTTP/2 but all major browsers are opted out of supporting it.
HTTP/2 improvements:
- Human readable headers in HTTP/1 in text format take up lots of bytes when a single bit is sufficient to do the same work. HTTP/2 solves this using compressed headers which in-turn improves performance. There are tools which shows the headers while using HTTP/2 for our reference. HTTP/2 has a compressor which doesnt only compress the headers wiht Gzip, but the engineers came up with HTTP/2 compression that is tailored towards the specific structure of the headers and the multiplexing feature
- HOL problem is solved using Multiplexing in HTTP/2. HTTP/2 uses a single connection instead of 6, but it uses the single connection differently. A dedicated connection in HTTP/1 is now called stream in HTTP/2 and all streams share that single connection. These streams are split up into frames and are being multiplexed on to that single connection. When one stream is blocked the other stream can make good use of the connection what would have been an idle time in HTTP/1, Head of line blocking be gone.
All streams not only share the connection but also the compressor. this means the headers never have to be sent twice since the shared compressor recognizes the already sent header and sends a reference, instead of the whole header. This compression algorithm used is HPACK – which uses table and indexing concepts to store and retrieve the headers. Reference: https://http2.github.io/http2-spec/compression.html
As far as we know HTTP/2 woks in the same way as HTTP/1. What changes is that the performance and precautions you have to take. Try using HTTP/2 in your server and look for a drastic performance improvement.