HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0

On This Page

HTTP/1.0

HTTP/1.1

HTTP/2.0

HTTP/3.0

The Whole Chain

HTTP has been through four versions. Each one fixed a bottleneck the previous one created, so the story is easiest to follow as a chain of problems rather than a list of features.

HTTP/1.0

Every request opens a new TCP connection, and that connection closes once the response arrives.

The protocol is stateless, so no session information is kept between requests. Messages are text-based, with basic headers for content negotiation and caching.

For a page that is one document with almost nothing else on it, that is fine. For anything with images, stylesheets and scripts, it means paying for a fresh connection over and over.

The bottleneck: connection setup, repeated for every single resource.

HTTP/1.1

Persistent connections. The TCP connection stays open across multiple requests and responses. That removes the repeated setup cost, and it is why HTTP/1.1 loads a page of many resources with far less latency than HTTP/1.0.

Chunked transfer encoding. Data can be sent in chunks, so a server can start sending a response before it knows the total size.

Better caching. Improved headers allow more useful caching strategies.

The Host header. A request now says which host it is for, which lets many domains share a single IP address. That is what makes virtual hosting possible.

HTTP/1.0 opens and closes a connection for every resource, while HTTP/1.1 keeps one connection open and sends the requests through it in turn

Pipelining, sending the next request before the previous response arrives, was allowed but rarely worked well in practice.

The bottleneck: the requests still go through the connection one at a time. A slow response blocks the ones behind it. That is head-of-line blocking.

HTTP/2.0

A binary protocol. Messages are encoded in a binary format rather than text, which is more efficient to parse and less error-prone.

Multiplexing. Many requests and responses can be in flight at the same time over a single connection, which is what ends head-of-line blocking at the HTTP layer. Nothing has to wait for the response in front of it.

Header compression (HPACK). HTTP headers repeat heavily from request to request. Compressing them cuts bandwidth.

Server push. The server can send a resource to the client proactively, before the client asks, anticipating what it will need next.

Under HTTP/1.1 the responses queue behind each other on one connection, and under HTTP/2.0 they are interleaved so a slow one blocks nothing

The bottleneck: HTTP/2.0 still runs on TCP. TCP guarantees ordered delivery of its own stream, so one lost packet stalls every multiplexed stream sharing that connection. The blocking moved down a layer rather than disappearing.

HTTP/3.0

Built on QUIC. HTTP/3.0 replaces TCP with QUIC (Quick UDP Internet Connections), which runs over UDP. That is the change everything else follows from.

Faster connection setup. QUIC establishes connections more quickly, including a zero round trip time (0-RTT) handshake for a repeat connection.

Better handling of packet loss. Because QUIC is not bound by TCP's single ordered stream, a lost packet affects only the stream it belonged to. This is why HTTP/3.0 holds up better than HTTP/2.0 in real conditions with loss.

Encryption built in. QUIC integrates TLS 1.3, so transport encryption is part of the protocol rather than a layer added on top.

Header compression (QPACK). The same idea as HPACK, adapted for QUIC's independent streams.

HTTP/2.0 multiplexes over TCP so one lost packet stalls every stream, while HTTP/3.0 multiplexes over QUIC on UDP so a loss affects only its own stream

The Whole Chain

	HTTP/1.0	HTTP/1.1	HTTP/2.0	HTTP/3.0
Connection	New per request	Persistent	Multiplexed over one	QUIC over UDP
Encoding	Text	Text	Binary	Binary
Header compression	No	Limited	HPACK	QPACK
Encryption	Optional	Optional	Usually with TLS	Built in, TLS 1.3
Under packet loss	Poor	Poor	Better	Best
Suits	Simple static pages	Dynamic sites	High-traffic interactive apps	Real-time and streaming

Read it left to right and the pattern is one bottleneck at a time: connection setup, then request queueing, then transport-level blocking.

💡 The detail worth knowing for an interview is that HTTP/2.0 did not eliminate head-of-line blocking, it moved it. Saying "HTTP/2 fixed head-of-line blocking at the HTTP layer, but TCP's ordered stream reintroduced it, which is why HTTP/3 went to QUIC" is a complete explanation of why a third rewrite was needed.

Key takeaway: HTTP/1.0 opens a new TCP connection per request. HTTP/1.1 keeps the connection persistent, adds chunked transfer and the Host header that lets many domains share one IP, but requests still queue. HTTP/2.0 goes binary, multiplexes many streams over one connection, compresses headers with HPACK and can push resources. HTTP/3.0 moves to QUIC over UDP, which sets up faster, survives packet loss better, and builds in TLS 1.3.

The next lesson, URL vs. URI vs. URN, sorts out three terms that get used as if they meant the same thing.

Mark as Completed

Idan Chen

· 4 months ago

Show 1 reply

On This Page

HTTP/1.0

HTTP/1.1

HTTP/2.0

HTTP/3.0

The Whole Chain