An introduction to HTTP evolution
As per mdn docs, the definition of HTTP is –
Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes.
HTTP follows a classical client-server model, with a client opening a connection to make a request, then waiting until it receives a response.
HTTP is a stateless protocol, meaning that the server does not keep any data (state) between two requests. Though often based on a TCP/IP layer, it can be used on any reliable transport layer; that is, a protocol that doesn’t lose messages silently, such as UDP.
In this blog I will be talking about evolution of HTTP from v 1.0 to 2.0 and try to answer the following questions –
1. What was there is a particular version ?
2. What were the problems faced which generated the need to create a more advanced version ?
- First browser friendly HTTP protocol was introduced in 1996.
- Supported methods – GET, POST, HEAD.
- Headers contains metadata about both request and response made.
- In HTTP/1.0 a separate connection to the same server is made for every resource request.
Let’s take example of a simple webpage with 24 resources (images), that need to be fetched from the server. If we try to open this webpage in the older version of browser which supports HTTP/1.0 then you will see that every time a new request comes up, browser made a new connection request to the server which impacts the performance of the webpage.
The download time would be negligible but still the payload will take time as there would be a series of request/response.
So, making up of a new connection every time was major the drawback of HTTP/1.0
Imagine if we still use this version for our modern websites.
HTTP/1.1 was developed by analysing the drawbacks of earlier version.
Some important features were –
- Connection Reuse – In this the page time reduced considerably because connections once made get re-used for further requests. More requests are sent over the same connection. Modern browsers supports max 6 connections at a time per unique host.
- Pipelining – It is a concept in which client can ask the server for many items in one go. It is more of a theoretical concept as the actual implementation for this is quite complex.
- Improved Caching
- Range Requests
Some of the ways to reduce number of requests to the server in order to render a web page are there to improve the web page performance. These solutions are widely used and can be considered as a cheat sheet for the connection reuse concept of HTTP/1.1.
Some of them are –
- Sprite Images – In this one large image is built using many small images that are required in the website so that we only need to make a single request to the server to get all the images.
- Inlining – Taking image and putting them inside CSS file to reduce number of requests is another way of reducing calls.
- Concatenating – It is a combination of multiple JS files together in a single file.
- Sharding – Distributing content over multiple unique hosts to get around the limitation of 6 TCP connections per host. Suppose you need to download 100 resources then as per HTTP/1.1 you are only allowed to open 6 TCP connections at a time, but if the content is spread over multiple hosts (say 3 hosts), then there could be 18 connections at a time.
But all these hacks introduce complexity in development and maintenance of the web application. Like having too many TCP connections introduce some unwanted effects like protocol overhead and connection stealing capacity from other applications that use fewer connections.
So, what is the solution now ??
HTTP/2 was developed to solve these issues and to deliver a protocol that didn’t have these flaws. It was developed for improving performance of webpages without using the HTTP/1.1 performance techniques.
Main change is how the data is framed and transported between the client and the server, all other features from HTTP/1.1 are as it is.
Some features –
- Multiplexing – One TCP connection is made to fetch all the required resources, example – If we request for two images then these images gets chopped of in tiny pieces and interleaved together and then sent over to that TCP connections. Multiplexing is done with “streams” – Streams can be reprioritised and can be at cancelled any time. – They can have dependencies.
- It is binary and mostly encrypted.
- Header compression – Headers are mostly compressed, so the size of the request is significantly smaller – and thus faster.
- HTTP/2 push – Server can push content to clients. In this HTTP/2 enabled server can send resources to HTTP/2 enabled client even before client requests them. In this example scenario, the server knows that anyone requesting index.html will need styles.css and script.js, so it can push them to the client immediately without waiting for the client to request them. If done correctly, by the time the browser finishes parsing index.html, the transfer of styles.css and script.js would have already started, or even completed. You can read more in detail here.
HTTP/1.1 performance techniques are harmful. They will make a HTTP2 website slower, so you don’t need to use them.This is an introduction to HTTP evolution which will give you a basic idea about all versions of HTTP. I will add a practical example showing all the features of HTTP/1.1 and HTTP/2 with comparison.
Thanks for reading this 🙂