HTTP/2 & HTTP/3

Follow one HTTP/2 message through frames and streams

HTTP/2 divides messages into typed binary frames. A request or response belongs to one stream, while the connection carries frames from many streams:

1. 1

   Identity

   Open a stream

   The initiating peer assigns a stream identifier. The stream has an explicit lifecycle from idle through open or half-closed to closed.

2. 2

   HEADERS

   Send the field section

   Pseudo-fields such as :method, :scheme, :authority, and :path carry request control data. HPACK indexes repeated fields within the connection.

3. 3

   DATA

   Interleave content

   DATA frames from other streams can appear between this stream's frames, so one slow application response does not monopolize the connection.

4. 4

   END_STREAM

   Close independently

   Each direction closes separately. A stream error can reset one exchange, while a connection error affects every stream on that connection.

Bound concurrency and flow control

• SETTINGS_MAX_CONCURRENT_STREAMS limits how many peer-initiated streams may be open. New work waits or uses another connection when the peer's limit is reached.
• HTTP/2 applies flow control to DATA at both the stream and connection level. WINDOW_UPDATE grants more credit after the receiver consumes buffered bytes.
• Flow control is not a request scheduler and does not replace application backpressure. Oversized windows can increase memory; undersized windows can idle a fast path.
• Field-list, frame-size, connection-age, request-count, and idle limits protect the server from one long-lived connection consuming unbounded state.

TCP still owns delivery order

HTTP/2 streams are logically independent, but TCP exposes one ordered byte stream. If a TCP segment is missing, later bytes cannot be delivered to the HTTP/2 parser until that gap is repaired. Frames for unrelated streams can therefore wait behind one transport loss even when their bytes reached the receiver.

The lab's RTT-sized recovery pause is intentionally illustrative. Real completion time also depends on congestion control, packetization, retransmission timing, response sizes, server scheduling, connection reuse, and the shape of the loss.

Roll out from an observable, reversible edge

Start where HTTP terminates. The CDN, reverse proxy, or load balancer must listen on TCP and UDP, route QUIC connection IDs correctly, present the same origin identity, and expose protocol-specific evidence.

The example uses current NGINX http2 on, listen ... quic, and h3 syntax. The current open-source NGINX documentation still labels ngx_http_v3_module experimental, so verify the deployed version, TLS library, module build, support policy, and migration behavior instead of copying a configuration blindly.

Use a controlled migration sequence

1. Establish a protocol baseline for real client networks, regions, devices, routes, and connection reuse before advertising HTTP/3.
2. Prove UDP reachability, certificates, ALPN, QUIC routing, address validation, connection draining, and HTTP/2 fallback at the edge.
3. Advertise h3 to a small cohort with a short Alt-Svc lifetime. Keep application semantics and cache policy unchanged.
4. Compare error rate and user latency distributions by protocol and cohort. Track QUIC handshake failures, fallback, connection migration, retransmission, CPU, packets per second, and memory per connection.
5. Expand only after the canary remains healthy across lossy and UDP-restricted networks.
6. Roll back by stopping new advertisement, sending Alt-Svc: clear where appropriate, preserving TCP service, and allowing or deliberately draining established QUIC connections.