PlayInfoBox

Home /Network /HTTP/1.1 vs HTTP/2 vs HTTP/3: How the Web's Protocol Evolved

HTTP/1.1 vs HTTP/2 vs HTTP/3: How the Web's Protocol Evolved

The web's core protocol has quietly gone through three major redesigns β€” here's what changed at each step and why.

HTTP/1.1 introduced persistent connections

Earlier versions opened a new TCP connection for every single request. HTTP/1.1 standardized "keep-alive," letting one connection handle multiple requests in sequence.

But requests on one connection still queued up

Because a single HTTP/1.1 connection processed requests largely in order, browsers worked around this by opening several parallel connections per domain (commonly around six) to load resources faster.

HTTP/2 added multiplexing on a single connection

Released in 2015, HTTP/2 splits requests and responses into binary "frames" that can be interleaved over one TCP connection, removing the need for multiple parallel connections per domain.

Header compression cut redundant overhead

HTTP/2 introduced HPACK header compression, reducing the bandwidth wasted on repeating largely identical header fields with every request.

A weakness remained underneath HTTP/2

Because HTTP/2 still runs on TCP, a single lost packet forces every multiplexed stream on that connection to wait for retransmission β€” a problem known as TCP-level head-of-line blocking.

HTTP/3 replaced TCP with QUIC

Standardized in 2022, HTTP/3 runs on QUIC, a transport protocol built on UDP. A lost packet now only stalls the one stream it belongs to, not the entire connection.

Faster setup and built-in encryption

QUIC bakes in TLS encryption by default and can resume connections in fewer round trips, advantages that show up most clearly on mobile networks with higher packet loss.

Why the upgrades happened when they did

Each version targeted the bottleneck of its era: HTTP/1.1 formalized connection reuse for the early web, HTTP/2 tackled the overhead of pages that had ballooned to dozens of resources, and HTTP/3 addressed packet-loss recovery specifically for the mobile, Wi-Fi-heavy web where TCP's retransmission delays hurt the most.

You're probably already using more than one version

Most browsers and servers negotiate the best available protocol automatically during the connection handshake, so a single browsing session might use HTTP/2 for one site and HTTP/3 for another β€” there is usually nothing to configure manually.

Frequently Asked Questions

Do I need to do anything to use HTTP/2 or HTTP/3?

No. Modern browsers and servers negotiate the protocol automatically. If a server does not support the newer version, the browser falls back to an older one without any visible interruption.

Is HTTP/3 always faster than HTTP/2?

Usually, especially on lossy or high-latency connections like mobile networks. On a fast, stable wired connection the practical difference can be small, since HTTP/2 rarely triggers its TCP head-of-line blocking problem.