DEV Community

Cover image for Why HTTP/3 Exists: The Limits of HTTP/2 and the Rise of QUIC
Nilesh Vishwakarma
Nilesh Vishwakarma

Posted on

Why HTTP/3 Exists: The Limits of HTTP/2 and the Rise of QUIC

#http #networking #webdev #performance

HTTP/2 already gave us multiplexing, binary framing, and better use of a single TCP connection.

So why did we need HTTP/3?

The answer is not really HTTP itself.

The answer is TCP.

HTTP/3 keeps familiar HTTP semantics, but it changes the transport underneath by using QUIC over UDP.

That change affects packet loss, stream independence, connection setup, and network migration.

A simple way to remember the evolution is:

HTTP/1.1 → more connections

HTTP/2 → more streams over one TCP connection

HTTP/3 → more streams over QUIC
Enter fullscreen mode Exit fullscreen mode

HTTP and QUIC Are Not the Same Thing

HTTP defines what the message means.

For example:

GET /products
Host: example.com
Enter fullscreen mode Exit fullscreen mode

HTTP also defines:

  • methods such as GET, POST, and DELETE
  • status codes such as 200, 404, and 500
  • headers
  • caching rules
  • request and response behavior

A simple mental model:

HTTP = what the message means
TCP / QUIC = how the message travels
Enter fullscreen mode Exit fullscreen mode

Conceptually:

HTTP/1.1
   ↓
TCP
   ↓
IP
Enter fullscreen mode Exit fullscreen mode 
HTTP/2
   ↓
TCP
   ↓
IP
Enter fullscreen mode Exit fullscreen mode

HTTP/3 changes the transport:

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

HTTP/3 still uses normal HTTP ideas such as GET, POST, status codes, headers, and caching. The main change is how the data moves across the network.

HTTP/1.1: More Connections for More Work

HTTP/1.1 has been used for a long time and is still important today.

A request might look like this:

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
Enter fullscreen mode Exit fullscreen mode

Modern websites need more than one file.

A page may need:

HTML
CSS
JavaScript
images
fonts
API responses
Enter fullscreen mode Exit fullscreen mode

The browser wants to download many of these quickly.

A simple analogy

Imagine a supermarket with one checkout line.

If one person has a very large cart, everyone behind that person has to wait.

HTTP/1.1 can reuse connections, and it also defined pipelining, but pipelined responses still have to come back in order.

Request A ───────────────►
Request B ───────────────►
Request C ───────────────►

Response A ◄──────── slow
Response B ◄──────── waiting
Response C ◄──────── waiting
Enter fullscreen mode Exit fullscreen mode

Even if response C is ready, it cannot simply jump ahead of response A in that pipelined sequence.

This waiting problem is one example of head-of-line blocking.

Because of this and other practical limits, browsers have historically used multiple TCP connections to get more concurrency.

HTTP/1.1: use more connections so more work can happen at the same time.

HTTP/2: Many Streams on One TCP Connection

HTTP/2 changed how HTTP data is represented and sent.

Instead of relying mainly on several separate TCP connections, HTTP/2 can place many logical streams inside one TCP connection.

TCP connection
│
├── Stream 1 → HTML
├── Stream 3 → CSS
├── Stream 5 → JavaScript
├── Stream 7 → Image
└── Stream 9 → API response
Enter fullscreen mode Exit fullscreen mode

Think of HTTP/1.1 as using several roads.

HTTP/2 is more like using one large highway with several lanes.

Several requests can move at the same time without opening a new TCP connection for every piece of work.

HTTP/2 also uses binary frames such as:

HEADERS
DATA
SETTINGS
WINDOW_UPDATE
RST_STREAM
Enter fullscreen mode Exit fullscreen mode

These frames belong to different streams and can be mixed together on the same connection.

That was a major improvement.

But one important problem remained.

All those HTTP/2 streams still share one TCP connection.

The TCP Problem in HTTP/2

TCP gives applications reliable and ordered data.

That is useful.

But ordered delivery also means missing data may need to be recovered before later bytes are passed to the application.

Imagine this:

Packet 1  ✓
Packet 2  ✗ lost
Packet 3  ✓
Packet 4  ✓
Enter fullscreen mode Exit fullscreen mode

TCP may need to recover the missing part before later ordered data can be delivered to HTTP/2.

Now remember that several HTTP/2 streams share the same TCP connection:

Stream A ─┐
Stream B ─┼──► TCP
Stream C ─┘
Enter fullscreen mode Exit fullscreen mode

If TCP has to wait for missing data, several HTTP/2 streams can be delayed.

Train analogy

Imagine HTTP/2 streams as passengers sitting in different train compartments.

The passengers are separate, but they are all on the same train.

If the train stops because the track is blocked, every compartment stops too.

That is why HTTP/2 multiplexing does not completely remove TCP-level head-of-line blocking.

HTTP/3: Change the Transport

HTTP/3 keeps the idea of multiple streams, but moves them from TCP to QUIC.

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

QUIC is a transport protocol built on UDP.

That does not mean HTTP/3 simply sends unreliable UDP packets and hopes for the best.

QUIC adds transport features HTTP needs, including:

  • reliable delivery
  • congestion control
  • flow control
  • loss recovery
  • encryption
  • multiple streams
  • connection migration

So this explanation is too simple:

HTTP/3 = HTTP over UDP
Enter fullscreen mode Exit fullscreen mode

A better explanation is:

HTTP/3 runs over QUIC, and QUIC uses UDP as its foundation.

Why QUIC Streams Matter

QUIC allows several streams inside one connection.

QUIC connection

├── Stream A → HTML
├── Stream B → CSS
├── Stream C → JavaScript
└── Stream D → Image
Enter fullscreen mode Exit fullscreen mode

Now imagine Stream B loses some data:

Stream A ─── ✓ ─── ✓ ─── ✓ ───►

Stream B ─── ✓ ─── X ──────────►
                  lost

Stream C ─── ✓ ─── ✓ ─── ✓ ───►
Enter fullscreen mode Exit fullscreen mode

Stream B may need to wait for its missing data.

But Stream A and Stream C do not automatically have to stop and wait for Stream B.

That is one of the most important differences between HTTP/2 over TCP and HTTP/3 over QUIC.

Does HTTP/3 remove all head-of-line blocking?

No.

If data is missing inside one QUIC stream, later data in that same stream may still need to wait.

The important improvement is that one blocked stream does not inherently block unrelated streams in the same way TCP's ordered delivery can affect HTTP/2 streams.

HTTP/2 vs HTTP/3: The Simple Version

HTTP/2:

Stream A ─┐
Stream B ─┼──► One TCP connection
Stream C ─┘

Packet loss in TCP
        ↓
Several streams may wait
Enter fullscreen mode Exit fullscreen mode

HTTP/3:

Stream A ───► QUIC Stream A
Stream B ───► QUIC Stream B
Stream C ───► QUIC Stream C

Loss in Stream B
        ↓
Stream B waits

A and C can still make progress
Enter fullscreen mode Exit fullscreen mode

This is a conceptual explanation. Real packet handling is more complex.

QUIC Also Integrates Security

HTTP/2 normally uses TLS over TCP for secure web traffic.

A simplified view is:

HTTP/2
   ↓
TLS
   ↓
TCP
Enter fullscreen mode Exit fullscreen mode

QUIC was designed together with TLS 1.3.

Conceptually:

HTTP/3
   ↓
QUIC + TLS 1.3
   ↓
UDP
Enter fullscreen mode Exit fullscreen mode

This can reduce some connection setup delay, depending on the network and whether the connection is new or resumed.

It does not mean HTTP/3 is always faster.

What Is 0-RTT?

QUIC can support 0-RTT data in some resumed connections.

Very simply:

First visit:
Client ── handshake ── Server

Later visit:
Client ── early data ──► Server
Enter fullscreen mode Exit fullscreen mode

This can save time in some situations.

But 0-RTT data has replay risks, so applications have to be careful about which operations are allowed to use it.

0-RTT can help some repeat connections start sooner, but it is not used for everything.

Connection Migration: Useful on Mobile Networks

Imagine you are using your phone at home on Wi-Fi.

Then you walk outside and your phone switches to mobile data.

Your network path may change.

QUIC supports connection migration using Connection IDs and path validation.

Wi-Fi
  ↓
QUIC connection
  ↓
Server
Enter fullscreen mode Exit fullscreen mode

Then:

Mobile network
  ↓
Same logical QUIC connection can continue
  ↓
Server
Enter fullscreen mode Exit fullscreen mode

The real process includes security checks and path validation, but the basic idea is simple:

QUIC is designed to handle some network changes without always throwing away the whole connection.

HTTP/1.1 vs HTTP/2 vs HTTP/3

Area HTTP/1.1 HTTP/2 HTTP/3
Main transport TCP TCP QUIC over UDP
Multiplexing No HTTP/2-style multiplexing Yes Yes
Typical concurrency Multiple TCP connections Multiple streams on one TCP connection Multiple streams on one QUIC connection
Field compression No HPACK/QPACK HPACK QPACK
Secure web traffic TLS over TCP TLS over TCP TLS integrated with QUIC
Connection migration No QUIC-like native feature No QUIC-like native feature Supported by QUIC
Main strength Compatibility Mature multiplexing Better stream independence
Main tradeoff Limited per-connection concurrency TCP-level blocking can still matter More deployment and implementation complexity

Is HTTP/3 Always Faster?

No.

HTTP/3 can have advantages when:

  • latency is high
  • packet loss happens
  • many resources are transferred at once
  • users move between networks
  • connection setup time matters

But on a fast and stable network with an already-open HTTP/2 connection, the difference may be small.

Performance also depends on:

  • browser implementation
  • server implementation
  • CDN
  • congestion control
  • packet loss
  • round-trip time
  • bandwidth
  • resource size
  • connection reuse

So it is better to say:

HTTP/3 can perform better in some network conditions, but it is not automatically faster everywhere.

HTTP/3 Has Tradeoffs Too

HTTP/3 solves some problems, but it also adds new ones.

UDP may be blocked

Some networks, firewalls, or middleboxes may block or interfere with UDP.

That means a client may need to fall back to HTTP/2 or HTTP/1.1.

Try HTTP/3
    │
    ├── works → use HTTP/3
    │
    └── fails → use TCP-based HTTP
Enter fullscreen mode Exit fullscreen mode

QUIC is not simple

QUIC still has to handle:

reliability
loss detection
congestion control
flow control
streams
encryption
connection management
path validation
Enter fullscreen mode Exit fullscreen mode

The complexity did not disappear.

It moved into QUIC.

Infrastructure needs support

Servers, CDNs, load balancers, firewalls, and monitoring tools may need proper QUIC support.

So moving to HTTP/3 is not only a browser change.

It can also be an infrastructure decision.

Which Version Is Better?

There is no universal winner.

A better question is:

Which version fits the situation?

HTTP/1.1

Useful when:

  • compatibility matters most
  • older systems are involved
  • traffic is simple
  • infrastructure is intentionally basic

HTTP/2

Useful when:

  • HTTP/2 support is already mature
  • you want multiplexing
  • your TCP-based infrastructure already works well
  • adding QUIC would add unnecessary complexity

HTTP/3

Useful when:

  • users are often on mobile networks
  • latency is important
  • packet loss is common
  • many resources are transferred at once
  • users may switch between Wi-Fi and mobile data
  • the infrastructure already supports QUIC well

The version number alone should not decide the choice.

The Evolution in One Diagram 

HTTP/1.1
More connections for concurrency

        ↓

HTTP/2
More streams on one TCP connection

        ↓

HTTP/3
More streams on a transport designed
to keep them more independent
Enter fullscreen mode Exit fullscreen mode

Or, using a road analogy:

  • HTTP/1.1: use more roads
  • HTTP/2: use one highway with many lanes
  • HTTP/3: redesign the transport so those lanes are less dependent on each other

TL;DR 

HTTP/1.1
More connections

HTTP/2
More streams over TCP

HTTP/3
More streams over QUIC
Enter fullscreen mode Exit fullscreen mode

HTTP/3 is not automatically faster everywhere.

Its main advantage is that QUIC is designed around independent streams, integrated security, connection migration, and a transport model that handles some forms of packet loss better than HTTP/2 over TCP.

That makes HTTP/3 especially useful when latency, packet loss, and mobile connectivity matter.

Final Thoughts

HTTP/3 is not interesting simply because it uses UDP.

The real change is QUIC.

HTTP/1.1 commonly used more connections to get more concurrency.

HTTP/2 put many streams on one TCP connection.

HTTP/3 moved those streams onto a transport designed with stream independence, security, loss recovery, and network changes in mind.

That does not make HTTP/3 magically faster everywhere.

But it gives the web a transport model that can behave better when latency, packet loss, and changing networks matter.

If you remember only one thing, remember this:

HTTP/1.1 opened more connections. HTTP/2 added more streams. HTTP/3 changed the transport underneath those streams.

References

This article is based mainly on the following IETF standards:

If you found this useful, feel free to share your experience with HTTP/2, HTTP/3, or QUIC in the comments.

Top comments (1)