HTTP versions

HTTP Versions — Interview-Ready Notes (with HTTP/3 & QUIC)

HTTP/1.0

Model: One request → one response → one TCP connection

Problem: Very high overhead

Key points

HTTP/1.1

Improvement: Persistent (keep-alive) connections

Limitation: Application-level head-of-line (HOL) blocking

Key points

HTTP/2

Goal: Fix HTTP/1.1 performance bottlenecks

How: Multiplexing over a single TCP connection

Key points

HTTP/3

Goal: Eliminate TCP-level head-of-line blocking

How: HTTP over QUIC, which runs on UDP

Key points

Head-of-Line Blocking (Quick Recall)

One-Line Comparison

Version Main Limitation Key Improvement
HTTP/1.0 One request per connection —
HTTP/1.1 App-level HOL Persistent connections
HTTP/2 TCP-level HOL Multiplexing + binary framing
HTTP/3 — QUIC over UDP, independent streams

Modern Architecture Usage

Browser note

60-Second Polished Interview Script

“HTTP has evolved mainly to reduce latency and head-of-line blocking.

HTTP/1.0 used one TCP connection per request, which was simple but inefficient.

HTTP/1.1 added persistent connections, but requests were still processed sequentially, causing application-level head-of-line blocking.

HTTP/2 fixed this with multiplexed streams over a single TCP connection, along with binary framing and header compression, but it still suffers from TCP-level head-of-line blocking.

HTTP/3 removes TCP entirely by running over QUIC on UDP. QUIC implements reliability and congestion control in user space and uses independent streams, so packet loss in one stream doesn’t block others. This significantly improves performance, especially on mobile and lossy networks.

In practice, systems use HTTP/2 and gRPC internally for performance, and HTTP/3 at the edge where supported.”

If you want, next I can:

HTTP / HTTP-2 / HTTP-3 — Rapid-Fire Flashcards

Flashcard 1 — Why was HTTP/1.0 inefficient?

A: One request per TCP connection, causing high latency due to repeated handshakes.

Flashcard 2 — What did HTTP/1.1 improve?

A: Persistent connections, allowing multiple requests over the same TCP connection.

Flashcard 3 — Main problem with HTTP/1.1?

A: Application-level head-of-line blocking due to sequential request processing.

Flashcard 4 — Why wasn’t HTTP/1.1 pipelining widely used?

A: It was fragile and still suffered from head-of-line blocking.

Flashcard 5 — Core goal of HTTP/2?

A: Eliminate application-level head-of-line blocking and reduce latency.

Flashcard 6 — How does HTTP/2 achieve this?

A: Multiplexed streams over a single TCP connection using binary framing.

Flashcard 7 — Why does HTTP/2 still have HOL blocking?

A: TCP enforces in-order delivery, so packet loss blocks all streams.

Flashcard 8 — What is TCP-level HOL blocking?

A: A lost packet stalls all streams until it’s retransmitted.

Flashcard 9 — What problem does HTTP/3 solve?

A: TCP-level head-of-line blocking.

Flashcard 10 — What does HTTP/3 run on?

A: QUIC, a transport protocol built on UDP.

Flashcard 11 — Why does QUIC use UDP?

A: UDP allows QUIC to implement transport logic in user space, enabling faster evolution.

Flashcard 12 — How does QUIC ensure reliability?

A: It implements acknowledgements, retransmissions, congestion control, and flow control itself.

Flashcard 13 — How does QUIC eliminate HOL blocking?

A: Each stream is independently ordered, so packet loss affects only that stream.

Flashcard 14 — Why is HTTP/3 better on mobile networks?

A: Independent streams, better loss recovery, and support for connection migration.

Flashcard 15 — What is connection migration?

A: QUIC connections survive IP changes using connection IDs.

Flashcard 16 — What is 0-RTT in QUIC?

A: Allows sending data immediately when resuming a connection, reducing latency.

Flashcard 17 — Risk of 0-RTT?

A: Data can be replayed, so it must be used cautiously.

Flashcard 18 — Why didn’t HTTP/2 just fix TCP?

A: TCP changes require OS kernel updates; QUIC evolves faster in user space.

Flashcard 19 — Why don’t browsers expose HTTP/2 streams to JavaScript?

A: The browser abstracts the protocol for security and simplicity.

Flashcard 20 — Why are WebSockets still used?

A: They provide full-duplex, long-lived connections accessible from JavaScript.

Flashcard 21 — Why does gRPC require HTTP/2?

A: It relies on multiplexing, bidirectional streaming, and header compression.

Flashcard 22 — Why can’t browsers use native gRPC?

A: Browsers don’t expose low-level HTTP/2 primitives.

Flashcard 23 — What is gRPC-Web?

A: A browser-friendly adaptation of gRPC using a proxy.

Flashcard 24 — When is HTTP/1.1 still acceptable?

A: For simple APIs and maximum legacy compatibility.

Flashcard 25 — One-line evolution summary?

A: HTTP/1.1 has app-level HOL, HTTP/2 has TCP-level HOL, HTTP/3 removes HOL using QUIC.

Flashcard 26 — Modern architecture pattern?

A: REST over HTTP at edges, gRPC over HTTP/2 internally, HTTP/3 where supported.

10-Second Mental Hook (Memorize This)

“HTTP/1.1 blocks at the app, HTTP/2 blocks at TCP, HTTP/3 doesn’t block at all.”

If you want next:

Just tell me.