Resources

Articles

HTTP/1, HTTP/2, and HTTP/3 — What Are the Differences?

Modern web access looks simple from the outside. You enter a URL, the browser connects to a website, and the page appears. Under the hood, however, the browser and the server may use very different generations of HTTP: HTTP/1.1, HTTP/2, or HTTP/3.

All three can deliver the same HTML page, the same CSS files, the same JavaScript, and the same images. In most everyday situations, the user won't even notice which version was used. But the differences become important when a page consists of many resources, when the network is not perfectly stable, or when a security gateway has to inspect, control, or troubleshoot the traffic.

The short story is this: HTTP/1.1 was simple and robust, but the modern web outgrew its one-request-at-a-time connection model. HTTP/2 fixed much of that by introducing multiplexed streams over one TCP connection. HTTP/3 keeps the multiplexed HTTP model, but moves it from TCP to QUIC over UDP, mainly to reduce a transport-layer limitation that HTTP/2 could not escape.

This article explains the practical differences from a browser and gateway perspective.

1. The Short Version: What Each Generation Tried to Fix

HTTP did not evolve because the previous generation was useless. Each version solved real problems of its time and introduced new trade-offs.

Version Main transport Main idea Practical effect
HTTP/1.1 TCP Text-based request/response protocol with persistent connections Simple and widely supported, but no practical multiplexing on one connection
HTTP/2 TCP Binary framing and many HTTP streams over one TCP connection Much better fit for modern web pages with many resources
HTTP/3 QUIC over UDP HTTP semantics similar to HTTP/2, but with QUIC streams instead of a TCP byte stream Reduces transport-level head-of-line blocking and improves behavior on some unstable network paths

That table is useful, but it hides the most important part of the story: HTTP/2 was not created because HTTP/1.1 could not download a file. It was created because websites had become collections of many dependent resources. And HTTP/3 was not created because HTTP/2 had bad HTTP semantics. It was created because HTTP/2 still relied on TCP, and TCP delivers data as one ordered byte stream.

2. A Single Resource Is Not the Hard Case

If a browser downloads only one resource over a reliable network, HTTP/1.1, HTTP/2, and HTTP/3 will look very similar from a user perspective.

Imagine a simple request for one large file. The browser connects to the server, sends a request, and receives bytes in response. If the connection is already established, the network is stable, packet loss is low, and the server is not overloaded, all three protocol generations can deliver comparable results.

HTTP/2 and HTTP/3 still have improvements, such as more efficient framing and header compression. But for one simple transfer, these features are usually not the main performance factor. The dominant factors are often server capacity, network latency, available bandwidth, TLS setup, congestion control, and the size of the object.

This is why protocol comparisons based only on a single file download can be misleading. They test a valid case, but not the case that motivated most of the protocol evolution.

The modern browser problem is not one object. It is a page.

3. Real Web Pages Changed the Problem

A normal web page is not just the first HTML document. The HTML file usually references additional resources:

  • CSS files
  • JavaScript bundles
  • images
  • fonts
  • icons
  • API calls
  • tracking or analytics resources
  • dynamically refreshed JSON data

The browser has to discover these resources, schedule them, request them, receive them, and render the page while more resources are still arriving.

This is where the differences between HTTP generations become visible. The question is no longer simply: "How fast can one response be downloaded?" The question becomes: "How efficiently can the browser fetch many resources at the same time, over a connection model that behaves well under latency and packet loss?"

HTTP/1.1, HTTP/2, and HTTP/3 answer that question very differently.

4. HTTP/1.1: Simple, Robust, but Connection-Hungry

HTTP/1.1 is the classic web protocol that shaped the internet for many years. It is text-based, easy to inspect, and conceptually straightforward: the client sends a request, and the server sends a response.

HTTP/1.1 introduced persistent connections, so the browser does not have to open a new TCP connection for every single resource. A browser can reuse an existing connection for another request after the previous response has completed.

But on one HTTP/1.1 connection, the practical model is still sequential:

  1. send a request,
  2. receive the response,
  3. send the next request,
  4. receive the next response.

That is not a good fit for a page that needs dozens or hundreds of resources.

There was an attempted improvement called HTTP pipelining. With pipelining, the client could send multiple requests without waiting for each response first. In theory, that reduced waiting time. In practice, it had serious deployment problems. Responses still had to arrive in order, intermediaries did not always handle pipelined traffic correctly, and one slow response could delay everything behind it. Browser support was limited, cautious, or disabled. As a result, HTTP pipelining never became the reliable solution the web needed.

Browsers therefore solved the problem in a more pragmatic way: they opened several parallel HTTP/1.1 connections to the same server. That allowed multiple resources to be fetched at once.

HTTP/1.1 diagram: browser opens multiple TCP connections, each carrying one sequential request/response exchange
HTTP/1.1 — the browser opens multiple TCP connections to fetch resources in parallel. Each connection handles one request at a time. — click to enlarge

This worked, but it had costs. More TCP connections mean more handshakes, more TLS sessions, more server state, more congestion-control instances, and more operational overhead. Domain sharding, where websites spread resources over several hostnames to increase parallelism, made this even more complex.

HTTP/1.1 was robust and successful. But the browser had to work around its connection model.

5. HTTP/2: Multiplexing Fixes the Page-Load Model

HTTP/2 was designed to address these limitations without changing the meaning of HTTP itself. Requests and responses still exist. Headers, methods, status codes, and URLs still exist. But the way data is transferred over the connection changed substantially.

HTTP/2 introduced a binary framing layer. Instead of treating one TCP connection as one request/response exchange at a time, HTTP/2 splits messages into frames and assigns them to streams. Many streams can be active on the same TCP connection at the same time.

For browsers, this was a major improvement. A single HTTP/2 connection can carry the HTML document, CSS files, JavaScript, images, fonts, and API responses in parallel. The browser no longer needs to open many TCP connections just to get basic parallelism. The server can interleave response data from different resources on the same connection.

HTTP/2 diagram: many streams multiplexed over one TCP connection, frames interleaved
HTTP/2 — many streams multiplexed over a single TCP connection, with response frames interleaved across streams. — click to enlarge

HTTP/2 also introduced HPACK header compression. This matters because HTTP requests often repeat many of the same headers: cookies, user-agent information, accepted content types, language preferences, and so on. With many small resources, reducing repeated header overhead can be useful.

Another HTTP/2 feature was server push, where the server could proactively send resources before the browser explicitly requested them. This sounded promising, but it did not age well. In practice, browser and server behavior was hard to optimize, pushed resources were often unnecessary or badly timed, and major browsers moved away from relying on it. Server push is therefore more of a historical note than a key reason to use HTTP/2 today.

The real success of HTTP/2 is multiplexing. It made the protocol match the structure of modern web pages much better than HTTP/1.1.

But HTTP/2 still had one important limitation.

6. The Remaining Problem: TCP-Level Head-of-Line Blocking

HTTP/2 multiplexes many HTTP streams, but it still runs over TCP.

TCP provides a reliable, ordered byte stream. That is one of its strengths. The application receives bytes in the correct order, and TCP handles retransmission if packets are lost.

But for HTTP/2, that strength can become a limitation.

HTTP/2 may have many logical streams, but TCP does not know about those streams. TCP only sees one ordered sequence of bytes. If a TCP segment is lost, later bytes cannot be delivered to the application until the missing data has been retransmitted and the byte stream is complete again.

This is known as transport-level head-of-line blocking.

HTTP/2 head-of-line blocking diagram: a lost TCP segment halts all streams until retransmission completes
HTTP/2 TCP head-of-line blocking — a single lost TCP segment stalls all HTTP/2 streams until the gap in the byte stream is filled by retransmission. — click to enlarge

A simple example makes the problem easier to see.

Imagine a web application that shows important live status updates. The browser polls a small JSON resource every few seconds. At the same time, the user starts a large download from the same origin. With HTTP/2, both the small JSON responses and the large download may share one TCP connection.

If packet loss affects part of the large download, TCP has to recover the missing data. During that recovery, later bytes in the same TCP connection may be held back, even if they logically belong to a different HTTP/2 stream. The small live-status update can be delayed because the shared TCP byte stream is temporarily blocked.

In that specific moment, two independent HTTP/1.1 connections might have behaved better: one connection for the large download, another for the small status update. But going back to many parallel connections is exactly what HTTP/2 was trying to avoid.

That tension explains why HTTP/3 exists.

HTTP/2 solved the browser multiplexing problem at the HTTP layer. But it could not solve TCP's ordered-delivery behavior underneath.

7. HTTP/3: Same HTTP Idea, Different Transport

HTTP/3 keeps the high-level idea of HTTP/2: many streams can be active in parallel, and the browser can fetch many resources efficiently.

The big change is the transport.

HTTP/3 does not run over TCP. It runs over QUIC, and QUIC runs over UDP. QUIC implements reliability, stream handling, packet loss recovery, congestion control, connection migration, and TLS 1.3 integration in the transport layer above UDP.

This sounds like a technical detail, but it changes the behavior of multiplexing.

QUIC understands streams. If data for one QUIC stream is lost, that does not automatically prevent already received data from another independent stream from being delivered to the application. In other words, HTTP/3 reduces the transport-level head-of-line blocking that HTTP/2 inherited from TCP.

HTTP/3 diagram: packet loss on one QUIC stream does not block the other independent streams
HTTP/3 — packet loss on one QUIC stream does not block the other independent streams. — click to enlarge

That is the central reason HTTP/3 matters.

For users on excellent wired networks, the difference may be modest. But many real-world connections are not perfect. Wi-Fi can be noisy. Mobile networks can have changing latency and loss. Paths can change. Packets can arrive late or be dropped. In such environments, the ability to keep independent streams moving can be valuable.

HTTP/3 also changes connection setup. QUIC integrates TLS 1.3 into the transport handshake, and repeat connections can benefit from 0-RTT resumption for faster setup. This does not make every page automatically faster, but it gives HTTP/3 a more modern foundation for encrypted web transport.

HTTP/3 uses QPACK for header compression — a variant of HTTP/2's HPACK, adapted for QUIC's out-of-order delivery model where the dynamic table updates must not block independent streams.

From an HTTP feature perspective, HTTP/3 is closer to HTTP/2 than to HTTP/1.1. The major difference is not the web semantics. The major difference is that the stream model is no longer forced through TCP's single ordered byte stream.

8. Summary and Outlook

The evolution from HTTP/1.1 to HTTP/2 to HTTP/3 is not just a version-number story.

HTTP/1.1 gave the web a simple and robust request/response model, but browsers had to open several parallel connections to load complex pages efficiently.

HTTP/2 fixed the page-load model by multiplexing many HTTP streams over one TCP connection. That reduced connection overhead and made modern pages fit much better onto a single encrypted connection.

HTTP/3 keeps that multiplexed model, but moves it to QUIC. The reason is not that HTTP/2's HTTP semantics were wrong. The reason is that TCP's ordered byte stream can block independent HTTP/2 streams when packet loss occurs. QUIC gives HTTP/3 independent streams at the transport layer.

HTTP/3 is not magic, and the speed experience can vary. For more information on that topic, read Speed of H3 — What We Learned So Far.

For details on how the browser and the website decide which HTTP version is actually used, see How do Browser and Website Negotiate Which HTTP Version is Used?.

Looking across the Internet, the adoption trend shows that HTTP/3 is no longer only a future topic. W3Techs reported in June 2026 that HTTP/3 was used by 39.5% of all websites in its survey, while HTTP/2 was used by 35.2%. The same data shows that HTTP/2 had a higher peak in the past and has since declined, while HTTP/3 has grown into mainstream deployment. These are website-level measurements, not exact browser traffic shares, but they are a strong signal: HTTP/3 support is now common enough that it must be considered in real-world testing.

For normal users, the browser usually hides these details. The page either loads or it does not. For network engineers, web administrators, and security gateway operators, the details matter.

HTTP/1.1, HTTP/2, and HTTP/3 can all carry encrypted web traffic. But they stress the network path differently, behave differently under loss, and create different inspection challenges for gateways.

In practice, almost all web security gateways support HTTP/1.1, and major enterprise gateways commonly support HTTP/2 as well. HTTP/3 support, however, is still not as common. As a result, websites that a browser might normally reach over HTTP/3 on a direct connection may effectively fall back to HTTP/2 when accessed through such a gateway. SSE TestCenter can help you understand and test exactly that behavior.

An even more problematic situation can occur if security settings allow browsers to connect directly to HTTP/3 sites and thereby bypass the security gateway. That behavior can also be tested with SSE TestCenter.

We hope that security vendors will continue to upgrade their products to include HTTP/3, so that secure browsing can cover the complete modern HTTP protocol family.

References and Data Points