System Design Fundamentals

0% completed

HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0

How QUIC is handling package loss on UDP ?

Idan Chen · 2026-04-03T09:18:22.209Z

How QUIC is handling package loss on UDP ?

On This Page

Why Page Loads Were Slow

HTTP/1.0

HTTP/1.1

The Problem HTTP/1.1 Left

HTTP/2.0

The Problem HTTP/2 Left

HTTP/3.0

Which Version Is Used Today

Key Takeaways

Practice Questions

You open a product page in an online store. To show it, the browser needs about 80 files: the HTML page, stylesheets, scripts, fonts, and many images.

How the browser fetches those 80 files has changed three times. Each new version of HTTP fixed a delay that the previous version created.

This lesson follows four versions of HTTP in order. For each one, it explains what changed, why it helped, and which problem was left for the next version to solve.

Why Page Loads Were Slow

The previous lesson showed that a TCP connection starts with a handshake. The handshake costs one round trip, which is the time for a message to reach the server and come back. HTTPS adds a TLS handshake on top, which costs at least one more round trip.

A round trip between a user and a server often takes 50 to 150 ms. So every new connection adds a noticeable delay before any file data moves.

This cost matters for everything that follows. Most changes to HTTP were about opening fewer connections and waiting less on each one.

HTTP/1.0

In HTTP/1.0, every request opens a new TCP connection, and the connection closes after the response.

It uses a simple request and response model.
It is stateless, so the server keeps no session information between requests.
Messages are plain text, with basic headers for content type and caching.

For a page that is one document with a few images, this is fine. For a page with 80 files, it is slow.

Here is the cost in numbers. Suppose a round trip takes 100 ms. Opening 80 connections one after another adds 80 x 100 ms, which is 8 seconds of handshakes. And that does not count the time to send the file data.

The problem it left: a new connection for every single file.

HTTP/1.1

HTTP/1.1 fixed the biggest cost of HTTP/1.0, and it added several other features.

Persistent connections. The TCP connection stays open after a response, so the browser can send many requests over it. Setting up one connection replaces setting up 80. This greatly reduces latency for pages with many files.

Chunked transfer encoding. A server can send a response in pieces, called chunks, as it creates them. It does not need to know the total size before it starts sending.

Better caching. New headers, like Cache-Control and ETag, give browsers and servers more control over what to store and when to check for a newer version.

The Host header. Every request now names the website it wants, like Host: shop.example.com. So one server, with one IP address, can host many websites. The server reads the Host header to decide which site to serve. This is called virtual hosting.

HTTP/1.0 opens and closes a new connection for every file, while HTTP/1.1 opens one connection and reuses it for many requests

The Problem HTTP/1.1 Left

On one HTTP/1.1 connection, requests still go one at a time. The browser sends a request, waits for the full response, then sends the next one.

So if one response is slow, like a large image, every request behind it waits. This is called head-of-line blocking: the first item in the line blocks everything behind it.

HTTP/1.1 did allow pipelining, which means sending several requests without waiting for each response. But the responses still had to come back in the same order, and many servers handled it badly. So browsers rarely used it.

Instead, browsers opened about six connections to each domain at the same time. This helped, but every extra connection needed its own handshakes. And each connection still handled only one request at a time.

HTTP/2.0

HTTP/2.0 changed how messages travel over a connection. It kept the same methods, status codes, and headers. It is usually written as HTTP/2.

A binary format. Messages are sent in a binary format instead of plain text. Binary is faster for computers to read, and computers make fewer mistakes reading it than reading text.

Frames and streams. HTTP/2 splits every message into small pieces called frames. Each request and its response form a stream, and each stream has a number.

Multiplexing. Frames from many streams can be mixed together on one connection. Many requests and responses are in progress at the same time, over a single connection. The browser puts the frames back together by stream number.

Under HTTP/1.1 a slow response makes the next requests wait, while under HTTP/2 many streams share one connection and each response arrives when it is ready

Multiplexing ends head-of-line blocking at the HTTP layer. A slow image no longer makes the stylesheet wait. So one connection per domain is enough again.

Header compression with HPACK. Requests to the same site repeat many of the same headers, like cookies and the browser name. HPACK compresses headers and avoids sending the same values again, which saves bandwidth.

Server push. A server can send a file to the browser before the browser asks for it. For example, when the browser requests the HTML page, the server can also push the stylesheet it knows the page needs. In practice, server push was hard to use well, and major browsers later removed support for it.

In practice, browsers use HTTP/2 only over HTTPS. So HTTP/2 almost always runs with TLS encryption.

The Problem HTTP/2 Left

HTTP/2 still runs on TCP. TCP delivers one ordered stream of bytes, and it does not know about HTTP streams.

So when one TCP packet is lost, TCP holds back all the data that arrived after it until the lost packet is sent again. That data may belong to many different HTTP streams. One lost packet stalls every stream on the connection.

HTTP/2 fixed head-of-line blocking at the HTTP layer, but the same problem remains in TCP underneath. On networks that lose packets often, like busy mobile networks, HTTP/2 can even be slower than HTTP/1.1 with six connections.

Over TCP one lost packet stalls every HTTP/2 stream, while over QUIC a lost packet affects only the stream it belongs to

HTTP/3.0

HTTP/3.0, usually written as HTTP/3, replaces TCP with a new transport protocol called QUIC. QUIC runs over UDP. Its name originally stood for Quick UDP Internet Connections.

QUIC rebuilds the parts of TCP that HTTP needs, like reliable delivery and congestion control. But it handles lost data separately for each stream.

Better handling of packet loss. QUIC knows about streams. When a packet is lost, only the stream that the packet belongs to waits for the resend. All other streams keep moving. This is why HTTP/3 handles packet loss better than HTTP/2 on real networks.

Faster connection setup. QUIC combines the connection handshake and the TLS handshake into one step. A new connection needs one round trip before the first request. A browser that has connected to the server before can often use 0-RTT, which means zero round trips: it sends its request immediately.

Encryption built in. QUIC includes TLS 1.3 as part of the protocol. Encryption is always on, not an optional layer added on top.

Header compression with QPACK. QPACK does the same job as HPACK, but it is designed for QUIC's independent streams.

Connection migration. A TCP connection is tied to the IP addresses and ports of both sides. When a phone moves from Wi-Fi to mobile data, its IP address changes, and TCP connections break. QUIC identifies a connection with a connection ID instead, so the connection can continue on the new network.

With a 100 ms round trip, HTTP/2 over TCP and TLS 1.3 waits about 200 ms before the first request, a new HTTP/3 connection about 100 ms, and a resumed one about 0 ms

One caution about 0-RTT. Data sent with 0-RTT can be captured and sent again by an attacker, which is called a replay. So servers accept 0-RTT only for requests that are safe to repeat, like reading a page.

Which Version Is Used Today

Most large websites and CDNs support HTTP/1.1, HTTP/2, and HTTP/3 at the same time.

The browser and the server agree on a version automatically.

During the TLS handshake, they choose between HTTP/1.1 and HTTP/2.
The server can also announce that it supports HTTP/3, with a response header called Alt-Svc. The browser then tries HTTP/3 on later requests.
If UDP traffic is blocked, for example by a company firewall, the browser uses HTTP/2 over TCP instead.

HTTP/1.1 is still very common too. Many simple tools, internal services, and older systems use it, because it is easy to read and debug.

	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	TCP	QUIC over UDP
Connections	New one per request	Persistent, about 6 per domain	One, multiplexed	One, multiplexed
Message format	Text	Text	Binary	Binary
Head-of-line blocking	Yes	Yes, per connection	Only in TCP, on packet loss	No, loss affects one stream
Header compression	No	No	HPACK	QPACK
Encryption	Optional	Optional	In practice, always TLS	Always, TLS 1.3 built in

Read the table from left to right. Each version removed one delay: first repeated connections, then waiting in line on a connection, then waiting on lost TCP packets.

Key Takeaways

HTTP/1.0 opens a new TCP connection for every request and closes it after the response.
HTTP/1.1 adds persistent connections, chunked transfer encoding, better caching, and the Host header, which lets many websites share one IP address.
HTTP/1.1 still handles one request at a time per connection, so slow responses cause head-of-line blocking.
HTTP/2 uses a binary format and multiplexes many streams over one connection. It adds HPACK header compression and server push.
HTTP/2 still runs on TCP, so one lost packet stalls every stream on the connection.
HTTP/3 runs on QUIC over UDP. It handles packet loss per stream, sets up connections faster with 0-RTT for repeat visits, and builds in TLS 1.3.
Browsers and servers agree on a version automatically, and use an older one when needed.

Each version of HTTP kept the same idea of requests and responses, and changed how they travel. The next lesson, URL vs. URI vs. URN, explains three terms for naming the resources that those requests ask for.

Practice Questions

Try each question first, then open the answer.

1. A page needs 30 files, and a round trip takes 50 ms. How much time do TCP handshakes add under HTTP/1.0, if the files load one after another? How much under HTTP/1.1 with one persistent connection?