HTTP versions and connection reuse: diagnose each hop
Compare HTTP/1.1, HTTP/2 and HTTP/3 through connection reuse, multiplexing and blocking. Trace a proxy path before tuning pools or interpreting latency.
TL;DR: HTTP connection reuse avoids repeated setup, while multiplexing lets several exchanges share a connection. Diagnose the protocol and limits on each proxy hop; an HTTP/3 client connection does not imply that the origin also receives HTTP/3.
Reuse and multiplexing solve different problems
With HTTP/1.1, a client can reuse a connection for successive exchanges when message framing and connection state permit it. Pipelining exists, but ordered responses can make a slow response hold up later ones, and many clients instead use several connections. RFC 9112 defines HTTP/1.1 connection and message handling.
HTTP/2 represents exchanges as streams on a shared TCP connection. Streams can make progress concurrently, subject to flow control and concurrency limits. TCP still delivers an ordered byte stream: packet loss can delay delivery of later bytes belonging to several HTTP streams. RFC 9113 describes that transport relationship.
HTTP/3 maps exchanges onto QUIC streams. Independent stream delivery reduces transport blocking across streams when packets are lost. Shared congestion control and other dependencies still affect performance; “HTTP/3 has no head-of-line blocking anywhere” is too broad. See RFC 9114.
| Behavior | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Common transport | TCP | TCP | QUIC over UDP |
| Connection reuse | Successive exchanges | Multiple streams | Multiple streams |
| Response organization | Ordered responses on a connection | Stream identifiers | QUIC request streams |
| Loss implication | Delays that connection's byte stream | Can delay several multiplexed streams | Primarily affects data on impacted streams, with shared congestion effects |
Protocol support does not remove the application's work queue. A database bottleneck can dominate all three.
Draw what the proxy actually negotiates
This is an illustrative path, not a mandatory architecture. Each hop has its own connection lifecycle, queue and timeout. The browser's protocol indicator describes its edge connection. It says nothing about the gateway's origin pool or the database connection count.
In a latency investigation, measure queue time before acquiring an upstream connection separately from time spent waiting for the application. If the gateway has exhausted its origin pool, increasing the application's request timeout does not create another connection slot.
Work through a pool bottleneck
Suppose a gateway has 20 HTTP/1.1 origin connections and sends one outstanding request per connection. The origin takes 200 ms per request in this simplified steady-state example. Ignoring overhead and variability, those connections support about 20 / 0.2 = 100 requests per second. An offered rate of 150 requests per second must queue, fail or use additional capacity.
Moving the edge from HTTP/2 to HTTP/3 does not change that particular origin limit. Increasing the origin pool may help only if the application and database can absorb more concurrency. Otherwise the queue moves deeper and becomes harder to observe.
For HTTP/2, also inspect the peer's allowed concurrent streams and local client limits. One connection with a stream limit is not infinite parallelism. A connection pool may open additional connections or queue locally depending on the client library.
Read and close response bodies deliberately
A reusable connection requires the client to know where the response ends and manage the body correctly. An application that abandons response bodies without the library's required cleanup can lose reuse or exhaust its pool. Follow the library's close or cancellation contract, especially when processing streaming responses.
Instrument connection creation, reuse and acquisition wait. A rise in new connections can explain extra TCP and TLS setup even when server execution time is unchanged. Correlate it with idle timeouts, server close behavior and deployment events. TLS handshakes explain the authentication work added by a fresh secure connection.
Persistent connections also outlive DNS answers. Updating an address does not necessarily redirect traffic already flowing through an established pool. Decide how clients age connections and how backends drain during a change. Aggressively closing every connection at once can create a synchronized setup burst.
Separate application cancellation from connection shutdown
With multiplexing, several requests can share a connection. Cancelling one stream need not close every other stream, but library or proxy behavior may still cause wider effects. Check reset and connection-close evidence rather than inferring it from one failed request.
During deployment, a proxy should stop assigning new work to a draining backend while giving eligible work a bounded opportunity to finish. Long-lived streams need a stated policy. See load balancer health and draining for that transition.
An intermediary also needs correct response identity: CDN cache keys and invalidation explains which requests may safely share stored content.
Self-check: a dashboard reports HTTP/2 at the edge, and origin requests wait 800 ms for a connection. Should the first change be enabling HTTP/3?
No. Identify the origin protocol, pool capacity and active-request distribution. The measured wait is before origin execution and may belong to a different hop entirely. Change the constrained resource only after checking the downstream concurrency it would admit.