HTTP/1.1, HTTP/2 and HTTP/3

The characteristics, advantages, problems, real world and evolution.

The beginning HTTP/1.1

The HTTP/1.1 was introduced at 1997, Text-based protocol w/ headers + body in plain text and keep-alive. It uses one TCP connection per request/response.

There are some "problems" with this version:

Head of line blocking -> if one request is slow, others should wait;
Too many TCP connections opened, browsers can open +/- 6 connections;
High latency because many round trips.

Real world

Usually it's used in common APIs;
Most servers fallback to HTTP/1.1 if HTTP/2/3 is not available/supported.

Evolution to HTTP/2

The HTTP/2 was lauched at 2015, this means messages are encoded in a compact, machine-readable binary format rather than plain text.

Uses multiplexing, multiple request over single TCP connection.

The advantages of HTTP/2 on HTTP/1.1 are:

No head-of-line blocking (at HTTP layer);
Faster page loads (parallel requests);
Much better bandwidth utilization.

The common problem continues yet. If the packet lost all the other streams stall until retransmission.

Real world

Most CDNs (Cloudflare, Akamai) and modern browsers default to HTTP/2 if available;
Huge win for web apps, APIs, gRPC.

The final so far. HTTP/3

Launched at 2022 RFC 9114, runs over UDP + TLS 1.3 and keeps benefits of HTTP/2 (multiplexing, compression) but avoids TCP issues.

HTTP/3 has some great advantages:

No TCP head-of-line blocking (independent streams);
QUIC integrates TLS 1.3 so it means 1 round trip to establish secure connection (faster handshake);
If your IP changes (e.g., WiFi → 4G), connection persists.

Possible "problems"

Not all infra supports QUIC (some firewalls block UDP);
More CPU intensive (QUIC implemented in user space, not kernel).

Real world

Google, YouTube, and Facebook serve most traffic over HTTP/3;
Chrome, Edge, Safari, Firefox → HTTP/3 enabled;
Cloudflare/CDNs support HTTP/3 out of the box.