One lost packet, several logical streams
Imagine response A is sending a photograph while response B sends a small stock quote. Frames for A and B are interleaved into the TCP byte sequence. A network segment containing bytes from A is lost, while later segments containing B arrive. The operating system may buffer later bytes, but it cannot hand them to the HTTP/2 parser as a contiguous stream before recovery fills the gap. Stream B is independent in the HTTP/2 model, yet it waits behind missing bytes in the shared TCP model.
Loss recovery timing depends on RTT, acknowledgment behavior and the deployed TCP stack. It may be quick, and it need not imply a retransmission timeout every time. But the important coupling is real. The network impairment delays multiple streams because TCP orders the entire byte sequence, not each HTTP/2 stream separately.
HTTP/3 places HTTP streams onto separate QUIC streams. QUIC runs over UDP and implements its own reliable stream delivery, congestion control, loss detection and encryption integration. A missing packet carrying stream A data does not impose a transport-level ordered-byte gap on stream B. QUIC can deliver the complete data it has for stream B without waiting for stream A's lost bytes, assuming B's own required data has arrived.
That is a specific improvement, not a promise of zero interference. Streams still share a connection's congestion controller, path capacity, connection-level flow control and often the same server resources. If one lost packet causes the congestion controller to slow the whole connection, B's future delivery rate may also be affected. If a dynamic header block depends on unavailable QPACK state, header processing can still wait. QUIC removes TCP's cross-stream ordered-delivery blocking rather than every kind of shared bottleneck.
The upgrade is not an unconditional win
A mobile application might benefit from HTTP/3 over a lossy path, but actual results depend on implementation, packet loss pattern, radio behavior, CPU, middleboxes and cache design. Modern HTTP/2 stacks can perform very well on stable paths. Some enterprise networks restrict UDP, and a fallback to HTTP/2 over TCP remains operationally important. A team that enables HTTP/3 without observing negotiation and fallback may misread a rollout as successful because requests still work through the older protocol.
Clients can learn that an origin supports HTTP/3 through mechanisms such as an Alt-Svc advertisement or DNS HTTPS records, and negotiate h3 when making the appropriate secure transport connection. The site does not force every client to speak HTTP/3 the instant a server enables it. Cache state, client support, route reachability and policy influence what actually gets used. An origin advertising h3 must still have a functioning endpoint and valid origin authentication.
HTTP/2 is not the same thing as opening one TCP connection per object. It normally uses a shared connection per appropriate origin, reducing socket and handshake overhead. HTTP/1.1 browsers historically used multiple parallel connections to work around response serialization. HTTP/3 also multiplexes, but over QUIC streams. The relevant tradeoff is not simply counting TCP sockets, because connection establishment, flow control and concurrency limits differ.
An interview diagnosis
I would first compare client timings by negotiated protocol (http/1.1, h2, h3), network type, packet loss, RTT and whether requests share one connection. The key question is whether unrelated stream completion times become correlated with loss on a common transport. I would capture frame and packet evidence where permitted, without pretending an encrypted packet trace always exposes HTTP stream mapping. Server-side spans alone cannot reveal all the time clients spend waiting for ordered bytes.
A controlled experiment could route a small traffic slice through HTTP/2 and HTTP/3 while keeping endpoint placement and workload comparable. Track p50 and p99, request failures, radio bytes, CPU, handshake cost, protocol negotiation rates and fallback. If the gain appears only on lossy paths, that is useful evidence, not a failed rollout. If the bottleneck is a saturated database or shared origin queue, changing HTTP transports will not fix it.
The durable mental model is layered. HTTP/2 removes much of HTTP/1.1's request-level blocking, but its frames are carried by TCP's single ordered byte stream. HTTP/3 uses QUIC to give streams independent ordered delivery. Understanding exactly which boundary moved helps avoid both mistakes: dismissing network loss because HTTP/2 multiplexes, and assuming QUIC makes a congested connection magically independent for every request.
