HTTP/2

Published on:

Most important commands to remember

  • curl --version — check which protocol features this build supports.
  • curl --http2 — offer HTTP/2 and inspect what was negotiated.

Commands and flags

Option or syntax Meaning
--version Show curl, libraries, and feature list.
--http2 Attempt HTTP/2 for HTTPS; the server may negotiate HTTP/1.1 instead.
-sS Hide the progress meter but retain errors.
-o /dev/null Discard the response body without saving a file.
-w 'HTTP %{http_version}\n' Print the actual HTTP version and a newline after the transfer.
--max-time 10 Limit the transfer to ten seconds.

The quoted write-out string is interpreted by curl; %{http_version} is not a shell variable.

The concepts that matter

1. HTTP/2 keeps HTTP meaning but changes the wire format

Methods, status codes, URLs, and headers remain recognizable HTTP concepts. HTTP/2 carries them using binary frames rather than HTTP/1.1’s textual message layout.

An application can therefore expose the same resource through both versions. Seeing a familiar GET response does not identify its wire protocol. Client and server must agree on a supported version.

2. Streams let exchanges share a connection

A stream is an independent logical exchange within an HTTP/2 connection. Frames from multiple streams can interleave, allowing several requests to be in progress without assigning each its own TCP connection.

This multiplexing can reduce connection overhead and application-layer waiting behind another response. It does not guarantee that the server executes all requests simultaneously or that one request cannot consume shared resources.

3. Compression and flow control affect shared resources

HTTP/2 uses HPACK for header compression, reducing repeated metadata across a connection. Compression state belongs to the connection, while request semantics remain separate.

Flow control limits data at both stream and connection levels. A slow consumer can constrain its stream, and connection-wide limits can affect others. Multiplexing therefore requires resource management, not simply opening unlimited concurrent requests.

4. TCP still delivers an ordered stream underneath

HTTP/2 commonly runs over TLS and TCP. TLS ALPN negotiates the application protocol for HTTPS. Packet loss at TCP can delay bytes needed by several HTTP/2 streams because TCP must repair its ordered stream.

That transport head-of-line blocking is different from HTTP/1.1 response ordering. HTTP/2 improves concurrency without removing every shared failure or latency source. One successful request also does not demonstrate multiplexing; that requires observing overlapping streams.

One small example

Optional: run the commands with your installed curl. The public example endpoint is not assumed to negotiate HTTP/2.

curl --version
curl --http2 -sS -o /dev/null -w 'HTTP %{http_version}\n' --max-time 10 https://example.com/

Check for HTTP2 in curl’s feature list. Without it, an unsupported-option error is a local build limitation rather than server refusal. In the second result, read the actual version: 2 confirms HTTP/2 for this transfer, while 1.1 can be a negotiated fallback.

A failed transfer may report no useful negotiated version. Status, connection policy, and endpoint support can change. The body is discarded, but the GET request still happens and certificate verification remains enabled.

This checks capability and negotiation, not parallel request scheduling. No local state is changed and no cleanup is needed.

Keep this idea: HTTP/2 multiplexes streams within a connection; verify negotiation and remember that TCP loss still affects shared delivery.