Evolution of Problem solving in Web Protocol

Visual Nuts and Bolts of 42 Webserv : Part 3: From HTTP/1.1 to HTTP/3

As I was working with my 42 webserver, it came to mind how HTTP evolved throughout the years. After delving into the problems and the solutions provided, which is my outmost curiosity. I would be giving analogies with relation of the terms throughout the post. I would pay good attention before you delve into the whole writing.

Source Credit : ByteByteGo

Let’s start with imagining the internet as a system of roads and highways, with *cars (data packets) traveling between various locations* (servers and clients).

HTTP/1.1: The Single Lane Highway

Problems:

Our first highway had a single lane(single connection), and each car had to wait(web request queueing) for the one in front of it to reach its destination before moving. This created traffic jams(head-of-line blocking) and was quite slow!

Solution:

Engineers introduced a system where cars could stop at resting points (persistent connections) along the way, and they could carry multiple passengers (chunked transfer encoding) at once.

Change: This made the journey a bit smoother and faster(reduced latency). Cars could move more efficiently without having to start and stop continuously.

HTTP/2: The Multi-Lane Expressway

Problems:

As the number of cars increased(volume of web request), even the improved single lane wasn’t enough. Cars still had to wait in queues, and if one broke down (head-of-line blocking), it delayed everyone behind it.

Solution:

The highway was expanded into multiple lanes (multiplexing). Now, cars could move side-by-side. They also introduced a system where travelers could share their plans(HPACK header compression) before the journey, reducing unnecessary chatter . Plus, some locations began sending goods in advance(server push), knowing travelers would need them.

Changes: Travel became much quicker (faster website loading). Multiple cars could move at the same time (efficient resource utilization), making better use of the road and reducing waiting times (better user experience).

HTTP/3: The Futuristic Transport System

Problems:

The multi-lane expressway(multiplexing), while better, still had issues. If an accident occurred in one lane(head-of-line blocking), all cars in that lane had to wait (TCP’s limitations). If you changed vehicles or routes(wifi -> mobile data / network interface change)on the old roads, you had to inform everyone(connection re-establish), and it often meant rerouting and starting from scratch(disruptive connection). Also, there were concerns about the security(unencrypted connection) of the goods being transported.

Solution:

Engineers developed an advanced transport system, maybe inspired by sci-fi movies or if I relate to something like the secret dungeons in Harry Potter, where each car traveled in its personal tube (QUIC protocol over UDP). This ensured that if one car had a problem(lost packet in TCP), others could continue unhindered. When switching the route or change the vehicle (mobile data -> wifi), journey isn’t interrupted(connection migration). Furthermore, every car had a security system ensuring the safety of its passengers and goods (built-in TLS encryption).

Changes: This revolutionized travel(HTTP)! The new system was secured and faster (quick and secure data exchange), ensuring that goods and passengers reached their destinations efficiently (seamless user experience).

Congratulations on reading through and finding the way how HTTP has evolved solving various issues. If you find any mistakes in the analogy feel free to reach out to me in slack mabbas or through my **email**.