HTTP/2
HTTP, multiplexedHTTP/2 changes how HTTP travels, not what it says. The methods, headers and status codes are unchanged, but it carries many requests at once over one TCP connection, compresses repeated headers away, and is binary rather than text — ending the era of six connections per origin.
HTTP/2 keeps HTTP’s meaning and multiplexes it into one binary connection — many requests in flight, headers compressed.
How it works
Each request/response pair is a numbered stream; frames from many streams interleave freely.
Headers repeated on every request are sent once and referenced by index afterwards.
A client can say which streams matter, and either end can throttle per stream.
The gain is real but it stops at the transport: because everything shares one TCP connection, a single lost packet still stalls every stream underneath it — the head-of-line blocking QUIC was built to remove.
What HTTP/2 does, step by step
ALPN inside the TLS handshake agrees “h2” before any request is sent — no extra round trip.
Each request takes a new odd-numbered stream ID; many can be open on the connection at once.
HEADERS and DATA frames from different streams interleave, so nothing waits its turn.
The far end sorts frames by stream ID back into the requests and responses HTTP has always had.
In cybersecurity
Everything true of HTTP is still true here — plus new state to exhaust: streams, header tables and priority trees are all things a client can abuse cheaply.
CVE-2023-44487: open and cancel streams endlessly to make a server do unbounded work.
SETTINGS_MAX_CONCURRENT_STREAMS is the throttle that keeps one client from taking the server.
A crafted header table can expand into far more memory than the bytes sent suggest.
Downgrading h2 to HTTP/1.1 at a proxy re-introduces boundary disagreements.
Browsers only speak h2 over TLS, so the transport is encrypted by default.
Binary framing means tooling that grepped HTTP text no longer sees anything useful.