Http Versions Untangled

Http Versions Untangled

#computerscience #computernetworks #HTTP #Technology #QUIC

😎🙌Greetings! 😎😎✨ Hey folks hope you guys are doing great🙌👀, so on this rainy Saturday✨✨ I thought to share my knowledge on HTTP protocol, in this post, I'm going to break HTTP & its versions in a very simple language for you🤞🤞🤞.

Assuming that you know a tad about HTTP🤷‍♀️🐱‍👓, my point is to explain the latest development in the versions of HTTP

So before moving further, I would like to describe the term “HTTP” 🐱😎. Well, HTTP (Hyper Text Transfer Protocol) is just a simple networking protocol that helps the user to interact & access a wide range of components from the “World Wide Web (WWW)” more precisely the Internet.

  • HTTP helps exchange data like HTML, images, videos, and other files between a server & a client(user).

  • HTTP works on port 80(in case you don’t have an idea about the port numbers, it is just a logical entity in a computer system that uniquely identifies a certain process, or you may call it a logical endpoint of a process running inside a computer).

  • HTTP requests are typically initiated by a client (a web browser) & sent to a web server. The intended server then responds with a message(reply) containing the requested data.

I think this much of heads-up (●'◡'●) is enough to make me explain to you about the versions of HTTP🙌😁😊.

So here goes the journey of the HTTP protocol✨✨👀:

The versions of the HTTP protocol

Now all the versions of HTTP are going to be discussed at length in simple language;-)🐱‍🚀🐱‍🚀

HTTP/1 -> HTTP version 1 came out in the year 1996🙌😃 as a “stateless protocol” (stateless implies the type of protocol where each request/response is independent of one another). This version of HTTP was built on top of the TCP connections (HTTP over TCP) to exchange the request/reply from the user to the web server and vice-versa.

HTTP version 1

The main downside😢🤔 of this version was that it required a separate TCP connection for each request/response while exchanging the messages between a client & server which naturally pulled this version down to have a hell lot of overhead making the communication process tedious & tepid🤷‍♀️🤔😒.

As you can see every time a client wants to talk to the server it will have to make a separate TCP call every time, which was a completely boring notion🤔😒😒.

HTTP/1.1 -> Soon back in 1997 an updated version of HTTP/1 was launched which introduced the concept of a “keep-alive” 😃✨ mechanism.

HTTP/1.1 version supports persistent connection

  • The major update in this version was that the client’s web browser could reuse the same TCP connection for multiple requests😎😎 made by the user to the intended web server on the internet, which eventually reduced the overhead found in the earlier version of the HTTP😎👌👌✨.

  • The “keep-alive” mechanism succeeded in reducing the latency😎👌😍 (time taken by a request made by the user to reach the server & get back the reply, generally measured in milliseconds(ms)).

  • The next thing I wanna add about this version of HTTP is that it also gives us a sense of “pipelining” theoretically🤷‍♂️ which implies the user can send multiple requests to the server before waiting for each of the individual responses from the server.

Pipelining in HTTP/1.1

  • But the concept of a pipeline in HTTP was quite tough to implement🐱‍🚀🐱‍🚀🤔 as at that time, many proxy servers sitting between the clients & a server was not ready to handle this theoretical concept properly which leads to its removal from many of the web browsers of that era😢.

  • The main downside of HTTP/1.1 was it suffered from a phenomenon renownedly acknowledged as “Head of Line Blocking (HOL)” 🤦😢 (which means that when a client makes multiple requests to a server over a single TCP connection & if one request takes longer to process than the others. In this situation, the server cannot send responses to the other requests until it finishes processing the slow request, even if it has already completed the processing of the other requests. This is because HTTP requires responses to be sent in the order in which the requests were received).

HTTP/1.1 suffered Head of Line Blocking (HOL) issue

  • To keep the browser performance at an acceptable level generally, every web browser keeps multiple TCP connections to the same webserver to send the request in a parallel fashion✌🐱‍🐉.

HTTP/2 -> After a long interval there was a comeback😃🙌 of HTTP with another version HTTP/2 in the year 2015.

  • Version 2 introduced the concept of “HTTP streams” 👍🐱‍👓 where streams are referred to as an independent, bidirectional sequence of frames that are exchanged between the client and server over a single TCP connection resulting in the reduction of latency. Each HTTP/2 connection can have multiple streams, and each stream is identified by a unique 31-bit integer identifier.

HTTP/2 uses the “streams” concept

  • This version of HTTP came with a good number of upsides👌😎✨✌ as it doesn't require in-order/out-order delivery of the packet, which was a major development.

  • This version also solved the “Head of Line Blocking (HOL)” issue✔👍😎 at the application layer but the problem still persists at the transport layer in the TCP🤔.

  • This version also introduced a “PUSH” capability😎🙌✨ which allows the intended web servers to send an update to the client whenever new data is up, without requiring any client to poll for the updates frequently😎.

HTTP/3 -> This latest version of HTTP was rolled back in the year 2022, which was the recent advancement😎👀 in the efficient development of HTTP protocol.

  • Version 3 uses a new underlying protocol known as “QUIC (Quick UDP Internet Connections)” which uses UDP (User Datagram Protocol) instead of TCP connections🤷‍♀️.

  • This version prioritizes the streams as first-class citizens🙌👍 (that means the streams were given the highest priority) at the transport layer (TL).

HTTP/3 uses UDP connections

  • No additional 3-way handshakes were required between the client & the webserver to exchange the data between them.

  • All the streams used in this version of the protocols use an independent streams concept which led to the reduction of packet failure👍✌.

🐱‍🐉🐱‍🐉Additional Knowledge: 👀😎

  • QUIC- QUIC (Quick UDP Internet Connections) is a kind of UDP protocol rolled out by Google Inc. in the year 2012 that was designed by the company to improve web performance & for mobile heavy internet usage😁🙌👌.

Nowadays we keep on switching the phone internet connection from 3G/4G/5G/Wi-Fi 🤷‍♀️🤷‍♀️😒which is a slothful process if it's done by a TCP connection😒 but for QUIC protocol which uses a “Connection ID” to switch in & out between different networks & interfaces in quick succession with reliability😎.

QUIC protocol

  • This new protocol helped in the improvement😊😎✨👌 of congestion control & switching between multiple connections (MUX) at a time for the users.

Note: Nowadays HTTP uses TLS/SSL protocols in combination which gives “HTTPS” (HTTP+TLS) as a result, running at port number 443, which is highly concerned about the security of a client when he/she is visiting a malicious(unsafe)🤦‍♂️ website, it will give you a red flag in advanced if the website is not running on HTTPS & warns you not to visit it😒😒🤦‍♂️.

Website using HTTPS

A website with only an HTTP connection👀

Website using HTTP

So it's time to give some rest to my keyboard & my fingers obviously 😁😁, hope you like this post, please feel free to ask me anything about this post.

✔✔Like, Share & Subscribe🙌🙌🙌

Thank You✌😎🤞