DEV Community

Cover image for HTTP/3: Why the Web Finally Moved Beyond TCP
Anik Sikder
Anik Sikder

Posted on • Originally published at aniksikder.hashnode.dev

HTTP/3: Why the Web Finally Moved Beyond TCP

#http #web #performance #backend

In the previous article, we explored how HTTP/2 transformed web communication.

Instead of opening multiple TCP connections, HTTP/2 introduced multiplexing, allowing many streams to share a single connection.

This was a major breakthrough.

Websites loaded faster.

Connections became more efficient.

Servers handled resources more intelligently.

For a while, it seemed like the web's communication problems had finally been solved.

But engineers soon discovered an uncomfortable truth:

HTTP/2 solved many of HTTP's problems.

It did not solve all of TCP's problems.

And because HTTP/2 still relied on TCP, some bottlenecks remained.

To understand those bottlenecks, imagine you're watching a Netflix movie on your phone.

You're connected to your home Wi-Fi.

Everything is smooth.

Then you leave your house.

Your phone switches from:

Wi-Fi
↓
5G
Enter fullscreen mode Exit fullscreen mode

For a brief moment, the video freezes.

A loading spinner appears.

A few seconds later, playback continues.

Most users blame the network.

But engineers ask a different question:

Why did the connection have to struggle in the first place?

Questions like this eventually led to one of the biggest protocol changes in the history of the web:

HTTP/3.

The Hidden Success of HTTP/2

When HTTP/2 arrived, it solved a huge problem.

Instead of opening many TCP connections:

Browser
 ├── TCP 1
 ├── TCP 2
 ├── TCP 3
 ├── TCP 4
 ├── TCP 5
 └── TCP 6
Enter fullscreen mode Exit fullscreen mode

HTTP/2 introduced multiplexing.

Now everything could travel through one connection.

One TCP Connection
│
├── HTML
├── CSS
├── JavaScript
├── Images
└── Fonts
Enter fullscreen mode Exit fullscreen mode

Less overhead.

Better efficiency.

Faster websites.

For a while, it looked like the problem was solved.

Then reality struck.

The Problem Nobody Could See

Imagine a highway with five lanes.

Cars are moving perfectly.

Suddenly a truck crashes in Lane 2.

What should happen?

Common sense says:

Lane 2 slows down.

Lanes 1, 3, 4, and 5 continue moving.

But TCP behaves differently.

TCP says:

Nobody moves until the missing vehicle is accounted for.

Everything waits.

Even traffic that wasn't affected.

This is essentially what happens when packet loss occurs.

Understanding Packet Loss

Data sent across the internet is divided into packets.

Imagine sending:

Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Enter fullscreen mode Exit fullscreen mode

Now suppose Packet 3 disappears.

Maybe a router drops it.

Maybe Wi-Fi interference occurs.

Maybe a mobile network briefly weakens.

The receiver gets:

Packet 1 ✅
Packet 2 ✅
Packet 3 ❌
Packet 4 ✅
Packet 5 ✅
Enter fullscreen mode Exit fullscreen mode

Humans would probably say:

Great.

We already have 1, 2, 4, and 5.

Let's continue.

TCP disagrees.

TCP's Obsession With Order

TCP was designed decades ago.

Its primary mission was reliability.

If data is sent:

1
2
3
4
5
Enter fullscreen mode Exit fullscreen mode

TCP guarantees:

1
2
3
4
5
Enter fullscreen mode Exit fullscreen mode

No missing pieces.

No reordering.

No shortcuts.

This reliability is amazing for:

  • Banking

  • Email

  • File Downloads

  • Database Replication

But for modern web applications, it creates a hidden cost.

The Waiting Game

Imagine five HTTP/2 streams:

Connection
│
├── Stream A → HTML
├── Stream B → CSS
├── Stream C → JavaScript
├── Stream D → Images
└── Stream E → Fonts
Enter fullscreen mode Exit fullscreen mode

Now one packet carrying image data gets lost.

Logically, only the image should be affected.

But because all streams share one TCP connection:

HTML        ⏳ Waiting
CSS         ⏳ Waiting
JavaScript  ⏳ Waiting
Images      ⏳ Waiting
Fonts       ⏳ Waiting
Enter fullscreen mode Exit fullscreen mode

Everything slows down.

Even resources that arrived successfully.

This is called:

TCP Head-of-Line Blocking.

And it became one of the biggest remaining performance problems on the modern web.

Why Mobile Networks Made Things Worse

Back in the early 2000s:

  • Desktop computers dominated

  • Wired connections were common

Today:

  • Smartphones dominate traffic

  • Users move constantly

  • Networks change frequently

A user may switch:

Home Wi-Fi
      ↓
Coffee Shop Wi-Fi
      ↓
4G
      ↓
5G
Enter fullscreen mode Exit fullscreen mode

Packet loss is normal.

Temporary interruptions are normal.

Modern protocols must assume imperfect networks.

TCP was designed for a different era.

Engineers Asked a Radical Question

For decades the stack looked like this:

HTTP
 ↓
TCP
 ↓
IP
Enter fullscreen mode Exit fullscreen mode

Nobody questioned it.

Using TCP felt as natural as using electricity.

Then engineers asked:

What if HTTP doesn't need TCP?

That question changed everything.

Meet QUIC

Google engineers began experimenting with a new transport protocol called QUIC.

Instead of building on TCP:

HTTP/2
   ↓
 TCP
Enter fullscreen mode Exit fullscreen mode

They built on UDP:

HTTP/3
   ↓
 QUIC
   ↓
 UDP
Enter fullscreen mode Exit fullscreen mode

At first, this sounds crazy.

UDP is famous for being unreliable.

The Pizza Delivery Analogy

Think of TCP as a delivery company.

Every pizza must arrive.

Every pizza must arrive in order.

If Pizza #3 is delayed:

Pizza 4 waits
Pizza 5 waits
Pizza 6 waits
Enter fullscreen mode Exit fullscreen mode

Maximum reliability.

But sometimes unnecessary waiting.

UDP works differently.

Send Pizza
     ↓
Hope It Arrives
Enter fullscreen mode Exit fullscreen mode

Much faster.

Much simpler.

But not reliable enough for the web.

QUIC combines the best of both worlds.

The Genius of QUIC

QUIC provides:

UDP Speed
      +
TCP Reliability
Enter fullscreen mode Exit fullscreen mode

But it adds one critical improvement.

Streams become independent.

Imagine:

Stream A
Stream B
Stream C
Enter fullscreen mode Exit fullscreen mode

If Stream A loses a packet:

Stream A waits
Enter fullscreen mode Exit fullscreen mode

But:

Stream B continues
Stream C continues
Enter fullscreen mode Exit fullscreen mode

This is the breakthrough.

One problem no longer freezes everything.

Why This Matters

Think about modern applications:

  • YouTube

  • Netflix

  • ChatGPT

  • Discord

  • Google Docs

  • Figma

These applications constantly exchange data.

Small delays affect user experience.

Reducing unnecessary waiting directly improves responsiveness.

HTTP/3 was designed for exactly this world.

Another Hidden Superpower: Faster Connections

Traditional HTTPS connections require several steps:

TCP Handshake
      ↓
TLS Handshake
      ↓
Data Transfer
Enter fullscreen mode Exit fullscreen mode

Every step adds latency.

QUIC combines and optimizes much of this process.

In some situations, returning users can send data immediately.

This is called:

0-RTT (Zero Round Trip Time)

Less waiting.

Faster interactions.

Happier users.

Connection Migration: The Mobile Superpower

Remember the Netflix example?

With TCP, changing networks often means starting over.

With QUIC:

Wi-Fi
   ↓
5G
Enter fullscreen mode Exit fullscreen mode

The connection can survive.

The session continues.

The user experiences fewer interruptions.

This is one reason HTTP/3 performs so well on mobile devices.

The Big Picture

Every major HTTP version solved the biggest bottleneck of its era.

HTTP/1.1
↓
Too Many Requests

HTTP/2
↓
Connection Inefficiency

HTTP/3
↓
Transport-Level Blocking
Enter fullscreen mode Exit fullscreen mode

The story of HTTP is really the story of engineers continuously removing obstacles between users and information.

Key Takeaways

  • HTTP/2 solved many HTTP/1.1 inefficiencies through multiplexing.

  • TCP-level Head-of-Line Blocking still remained.

  • Packet loss on one stream could affect unrelated streams.

  • Modern mobile networks made this limitation more noticeable.

  • QUIC was built on UDP to provide a more flexible transport layer.

  • HTTP/3 uses QUIC instead of TCP.

  • Independent streams reduce unnecessary waiting.

  • Features like 0-RTT and Connection Migration improve real-world performance.

One-Sentence Summary

HTTP/2 made one connection smarter; HTTP/3 made sure one lost packet could no longer slow down the entire conversation.

Top comments (0)