HTTP: The Evolution of HTTP

HTTP/1.1 vs HTTP/2 vs HTTP/3 explained from first principles

Most developers use HTTP every single day

Few actually stop and ask:

Why did we need HTTP/2?

HTTP/1.1 was already working right?

And now suddenly HTTP/3 exists too?

This article is not going to throw RFC definitions at you

We’re going to understand why the internet itself started struggling and how engineers slowly redesigned HTTP to survive modern applications

Because once you truly understand this evolution, a lot of backend engineering concepts suddenly start clicking together

Latency Connection management TCP limitations Browser optimization Streaming Multiplexing QUIC Head-of-line blocking

All of them start feeling intuitive instead of magical buzzwords

So let’s go back to the beginning

The Internet Before Modern Apps

Early websites were tiny

A webpage mostly meant:

• One HTML file
• Maybe one CSS file
• Maybe a few images

That’s it

A browser would:

1. Open a TCP connection
2. Request a file
3. Get response
4. Close connection

Simple life ….WE CHILL ..

HTTP/1.0 was built for this world

Then the Internet Became Heavy

Suddenly websites evolved into applications

Think about opening YouTube, Instagram, LinkedIn, Amazon, or Netflix today

One single page may load:

• Hundreds of images
• JavaScript bundles
• Fonts
• API requests
• Analytics
• Ads
• Videos
• CSS
• Real-time updates

And all of this needs to happen FAST

Users don’t care about protocols

If your app feels slow, they’ll leave ..and hence we needed to evolve.

Enter HTTP/1.1

HTTP/1.1 tried solving some major inefficiencies

The biggest one was this:

Problem: Creating TCP connections is expensive

Every new connection requires:

• TCP handshake
• Congestion window setup
• Resource allocation

Doing this for every request was terrible

So HTTP/1.1 introduced:

Persistent Connections

Instead of:

Open → Request → Close

We now had:

Open → Multiple Requests → Close

This was huge

Now one TCP connection could handle multiple requests

Much faster and very fewer resources wasted

Sounds great right?

Well…

A new problem appeared

The Queue Problem

Imagine a single-lane road

Only one car can pass at a time

HTTP/1.1 behaved similarly

Inside one TCP connection:

Request A
Request B
Request C

Responses had to come back in order

So if Request A became slow…

Everything behind it got stuck

This became known as:

Head-of-Line Blocking

One slow request blocks everything else behind it

Now imagine loading 100 resources on a webpage

You’ll prefer shifting to Mountains 💀

Browser Engineers Started Doing Weird Hacks

This part is actually funny

Instead of fixing the protocol immediately, browsers started doing “survival engineering”

They opened multiple TCP connections simultaneously

That’s why browsers still maintain several connections per domain

Because engineers were basically saying:

“Fine. If one lane is blocked, we’ll build six roads”

This improved performance

But it also created problems:

• More memory usage
• More congestion
• More TCP handshakes
• More server overhead

The internet was becoming inefficient again

HTTP/1.1 had reached its limits

HTTP/2: The Big Redesign

HTTP/2 was not just a “faster HTTP”

It fundamentally changed how data travels

The biggest idea was:

Multiplexing

Instead of sending one request at a time sequentially:

A → wait
B → wait
C → wait

HTTP/2 broke data into tiny frames

Now requests could interleave like this:

A1 B1 C1 A2 C2 B2

Everything travels simultaneously over ONE connection

This was revolutionary

Now one slow request no longer blocks others at the HTTP layer

Huge performance gains

Binary Instead of Text

HTTP/1.1 was text-based

Example:

GET /home HTTP/1.1
Host: example.com

Humans can read this easily

Computers don’t care

HTTP/2 switched to binary framing

Machines process binary much faster and more efficiently

Less parsing overhead Less ambiguity Better optimization

This is one reason HTTP/2 feels significantly faster

Header Compression

Modern requests contain massive headers

Cookies alone can become gigantic

Imagine sending:

Authorization
Cookies
User-Agent
Accept

again and again and again

HTTP/2 introduced HPACK compression

Meaning repeated headers no longer wasted bandwidth repeatedly

Small optimization individually

Massive optimization globally

So Did HTTP/2 Solve Everything?

Not exactly

Because there was still one giant problem hiding underneath

TCP

And this is where things get REALLY interesting

The Real Villain Was TCP

Remember:

HTTP runs on top of TCP

Even though HTTP/2 multiplexed requests beautifully…

TCP itself still guarantees ordered delivery

Meaning:

If one TCP packet gets lost…

TCP pauses and waits for retransmission

Even unrelated streams get blocked

So although HTTP/2 solved HTTP-level blocking…

TCP-level blocking still existed

This became another form of:

Head-of-Line Blocking

Just deeper in the stack

And this became extremely painful on:

• Mobile networks
• Unstable WiFi
• High packet loss environments

Engineers needed a bigger redesign

HTTP/3 Changed the Transport Layer Itself

This is the biggest conceptual jump

HTTP/3 does something radical:

It stops using TCP entirely

Instead, it uses:

QUIC

Which runs on UDP

Now if you’re thinking:

“Wait… UDP is unreliable”

Exactly

That’s what makes this fascinating

QUIC rebuilds reliability manually in user space

Meaning it takes:

• Reliability
• Ordering
• Retransmission
• Congestion control

and implements them smarter than traditional TCP

Why QUIC Matters

In HTTP/3:

Different streams are isolated

If packet loss happens in Stream A…

Stream B continues normally

That’s massive

Especially for modern apps where dozens of things load simultaneously

This dramatically improves real-world latency

Particularly on mobile internet

Faster Connection Establishment

Remember TCP handshake + TLS handshake?

That setup time hurts performance

QUIC combines and optimizes this process

Some connections can even become:

Zero Round Trip

Meaning data starts flowing almost immediately

This is insanely valuable at internet scale

Milliseconds matter

At companies like Google, Amazon, Netflix:

Even tiny latency reductions can mean millions of dollars

Literally

The Hidden Engineering Lesson

The evolution of HTTP teaches something deeper about engineering

Most scalability problems don’t appear initially

Systems fail gradually

A small workaround becomes a standard

Then that workaround creates new bottlenecks

Then engineers redesign the entire architecture

HTTP evolved exactly like real software systems evolve

First:

Simple system

Then:

Traffic increases

Then:

Temporary hacks

Then:

Scaling pain

Then:

Architectural redesign

This cycle exists everywhere:

• Databases
• Distributed systems
• Microservices
• Operating systems
• Networking

Learn to see these patterns early…Helps soo muchh. Personally telling you, I was learning Django recently, just to prove to myself that “Frameworks are just wrappers” and IT’S SOO TRUE !! You just have to recognise patterns. Be soo good at fundamentals , that all of it feels obvious and intutive…back to article..

HTTP Versions in One Line

HTTP/1.1

Efficient connections, but sequential request handling

HTTP/2

Multiplexed requests over TCP

HTTP/3

Multiplexed requests over QUIC/UDP with reduced transport-level blocking

Final Thought

Most people memorize protocols

Very few understand the pressure that created them

That pressure is where real engineering intuition lives

Because technology evolution is rarely random

It’s usually engineers desperately trying to remove bottlenecks created by the previous generation of solutions

And honestly?

That’s backend engineering in one sentence

Next in Under the Hood: We leave the application layer and descend deeper into the machine itself.

Threads, processes, context switching, and why your CPU is basically performing controlled chaos every second

Got questions or something that didn’t click? Drop a comment. I’m learning this out loud, and the best part of that is figuring it out together.

LinkedIn | Github | awasthijay825@gmail.com | X (Twitter).