DEV Community

Ahmed Omeiza
Ahmed Omeiza

Posted on

HTTP/1.1 vs HTTP/2 vs HTTP/3: What Actually Changed?

HTTP started simple:

Client sends a request. Server sends a response.

But modern applications don't make just one request.

A typical web page might load dozens or hundreds of resources — APIs, images, JavaScript, CSS, fonts, and more.

That is where HTTP/1.1 started showing its age.

HTTP/2 improved things significantly. HTTP/3 changed the underlying transport completely.

Let's break down what actually changed.

HTTP/1.1: Simple, But Sequential

HTTP/1.1 uses TCP and traditionally processes requests in a way that can cause head-of-line blocking.

Imagine this:

Request 1 ────────> Response 1
Request 2 ────────────────> Response 2
Request 3 ─────────────────────> Response 3
Enter fullscreen mode Exit fullscreen mode

If Request 1 is delayed, other requests can be affected.

Browsers worked around this by opening multiple TCP connections, but that came with additional overhead.

HTTP/1.1 also introduced useful features such as:

  • Persistent connections
  • Chunked transfer encoding
  • Better caching mechanisms
  • Pipelining support, although it was rarely used effectively

It worked — but the web had become much more demanding.

HTTP/2: Multiple Requests Over One Connection

HTTP/2 kept TCP but changed how HTTP messages are transferred.

The biggest improvement?

Multiplexing.

Instead of waiting for one request to finish before processing another, multiple streams can share the same TCP connection.

             ┌── Request 1
             ├── Request 2
TCP ─────────┼── Request 3
             ├── Request 4
             └── Request 5
Enter fullscreen mode Exit fullscreen mode

This reduces the need for multiple connections and makes it much more efficient to load many resources.

Binary Instead of Text

HTTP/1.1 messages are text-based.

HTTP/2 uses a binary framing layer.

That allows the protocol to break requests and responses into smaller frames and efficiently interleave them.

Header Compression

HTTP/2 introduced HPACK.

Instead of repeatedly sending the same HTTP headers, connections can compress and reuse header information.

Server Push

HTTP/2 also introduced server push, allowing servers to send resources before the client explicitly requested them.

However, browser support and real-world usefulness were limited, and server push has since been removed from modern browser implementations.

HTTP/3: HTTP Over QUIC

HTTP/3 makes the biggest architectural change.

Instead of:

HTTP → TCP → IP
Enter fullscreen mode Exit fullscreen mode

HTTP/3 uses:

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

Don't let the use of UDP fool you.

QUIC provides the reliability, ordering, congestion control, and security mechanisms needed for HTTP traffic.

And it does this at the transport layer.

The Big Difference: Head-of-Line Blocking

Here's where HTTP/3 becomes particularly interesting.

With HTTP/2, multiple streams share one TCP connection.

If a TCP packet is lost, TCP needs to retransmit it before the affected data can be delivered.

That can cause transport-level head-of-line blocking.

HTTP/3's QUIC uses independent streams.

HTTP/2

TCP Connection
├── Stream 1 ── X
├── Stream 2 ── X
└── Stream 3 ── X

Packet loss can affect the connection's delivery.

HTTP/3

QUIC Connection
├── Stream 1 ── X
├── Stream 2 ── ✓
└── Stream 3 ── ✓

Other streams can continue progressing.
Enter fullscreen mode Exit fullscreen mode

That's especially useful on networks where packet loss is common.

Connection Establishment

HTTP/3 also improves connection setup.

QUIC integrates TLS 1.3 into the protocol.

This reduces the number of round trips required to establish a secure connection compared with traditional TCP + TLS setup.

QUIC also supports connection migration.

For example, if your device moves from Wi-Fi to mobile data, a QUIC connection can potentially continue without establishing an entirely new connection.

HTTP/1.1 vs HTTP/2 vs HTTP/3

Feature HTTP/1.1 HTTP/2 HTTP/3
Transport TCP TCP QUIC over UDP
Multiplexing Limited Yes Yes
Binary framing No Yes Yes
Header compression — HPACK QPACK
Transport HOL blocking Yes Yes No
TLS Separate Separate Built into QUIC
Connection migration No No Yes

The important thing isn't memorizing the table.

It's understanding the progression:

HTTP/1.1
   ↓
Multiple connections

HTTP/2
   ↓
Multiplexing over TCP

HTTP/3
   ↓
Multiplexing over QUIC
Enter fullscreen mode Exit fullscreen mode

What Should Developers Care About?

You usually don't implement HTTP/2 or HTTP/3 yourself.

Your web server, reverse proxy, CDN, browser, and networking stack handle most of the protocol details.

As a backend developer, what's important is understanding the implications.

For example, if you're building an API:

Client
   ↓
HTTP/3
   ↓
CDN / Reverse Proxy
   ↓
ASP.NET Core API
   ↓
Database
Enter fullscreen mode Exit fullscreen mode

Your application code can remain largely the same while the underlying HTTP protocol changes how efficiently requests travel across the network.

The Key Takeaway

HTTP/1.1 made the modern web possible.

HTTP/2 made multiple requests much more efficient through multiplexing.

HTTP/3 takes that further by moving HTTP onto QUIC, reducing the impact of packet loss and improving connection establishment and migration.

So don't think of HTTP/3 as simply:

"HTTP/2 but faster."

It's a fundamental change in how HTTP communicates over the network.

HTTP/1.1 optimized connections.
HTTP/2 optimized streams.
HTTP/3 optimized the transport underneath them.

Top comments (0)