HTTP has kept the same core job for decades: define how clients and servers exchange web resources. The transport underneath it, however, has changed dramatically. HTTP/1.1, HTTP/2, and HTTP/3 represent different answers to the performance limits discovered as the web became more interactive.
HTTP/1.1: simple and widely compatible
HTTP/1.1 sends textual requests and responses over TCP. Persistent connections reduce connection setup overhead, but one connection still has ordering constraints that make packet loss and multiple resource downloads expensive. Browsers therefore opened several connections in parallel.
Why HTTP/1.1 became difficult to scale
Modern pages can require HTML, CSS, JavaScript, fonts, images, and API calls. Sending these resources efficiently over multiple TCP connections adds overhead. Head-of-line blocking at the application stream level and repeated headers also limit efficiency.
HTTP/2: multiplex many streams
HTTP/2 keeps TCP but introduces a binary framing layer and multiplexed streams. Multiple requests and responses can share one connection instead of waiting for each other in a strictly sequential sequence. Header compression with HPACK also reduces repetitive metadata.
Streams, frames, and priorities
HTTP/2 breaks messages into frames associated with streams. Because frames from multiple streams can be interleaved, a single connection can carry many resources at once. This removes a large amount of HTTP/1.1-era connection management complexity.
HTTP/3: HTTP over QUIC
HTTP/3 changes the transport from TCP to QUIC, which runs over UDP and provides reliable streams, encryption, connection migration, and modern congestion control mechanisms. Crucially, loss on one stream does not force unrelated streams to wait for the same ordered byte stream.
The practical comparison
| Version | Transport | Key idea | Typical strength |
|---|---|---|---|
| HTTP/1.1 | TCP | Persistent connections | Compatibility and simplicity |
| HTTP/2 | TCP | Multiplexed streams | Efficient resource delivery |
| HTTP/3 | QUIC/UDP | Independent streams | Better behavior on lossy networks |
Does HTTP/3 make every website faster?
No. Protocol improvements are only one part of latency. Server processing, database queries, JavaScript execution, image size, caching, and geographic distance can dominate. HTTP/3 is especially interesting for environments where connection setup and packet loss are meaningful, but good application engineering still matters.
How to inspect it
Open browser DevTools, inspect the Network panel, and look for the protocol column. Command-line tools such as curl -I are also useful, while browser connection details can reveal whether a site negotiated h2 or h3.
What to learn next
Protocols make more sense when you connect them to the full page-load pipeline. Readwhat really happens when you type a URLand then explore the networking foundation in ourOSI model guide.