HTTP/2 and HTTP/3

HTTP defines the meaning of requests and responses. A method such as GET asks for a resource. A status such as 404 reports an outcome. Fields carry metadata. Content carries the representation.

HTTP/2 and HTTP/3 keep those semantics. They change how messages travel between one HTTP client and its immediate peer.

That distinction is the first mental model:

HTTP semantics stay stable
        |
        +-- HTTP/2: binary HTTP framing over TCP
        |
        +-- HTTP/3: HTTP framing over QUIC

An application does not become a different API because the connection uses HTTP/3. A proxy can receive HTTP/3 from a user agent and use HTTP/2 to an origin. Each hop negotiates its own protocol version.

Why newer mappings exist

HTTP/1.1 can reuse a connection, but it does not provide a multiplexing layer. Clients often use several TCP connections for concurrent requests. Pipelining only partly addresses concurrency and retains application-layer head-of-line blocking.

HTTP/2 puts each request and response exchange on a stream. Frames from several streams can be interleaved on one connection. A stalled HTTP message does not prevent another stream from making progress at the HTTP layer.

HTTP/2 still runs over TCP. TCP delivers one ordered byte stream. If a TCP segment is lost, later bytes wait until the missing bytes arrive. That transport-level head-of-line blocking can delay every HTTP/2 stream sharing the connection.

HTTP/3 maps HTTP onto QUIC. QUIC provides reliable, ordered delivery within each stream, but it does not impose one total order across all streams. Loss affecting one stream does not stop delivery on another stream whose data has arrived.