Mapping exchanges to QUIC streams
HTTP/3 preserves HTTP methods, statuses and resource semantics while using QUIC. Client-initiated bidirectional streams carry request-response pairs through HTTP frames such as HEADERS and DATA, with reliable in-order delivery within each stream.
A separate unidirectional control stream carries connection-wide information, and other stream types support QPACK. HTTP/3 is not unmodified HTTP/2 framing placed inside UDP; transport and application responsibilities have explicit boundaries.
References: [1]
Reducing cross-stream ordering dependencies
QUIC does not impose one byte order across streams. Missing bytes on one stream need not hold back available bytes on another, unlike the shared TCP ordering beneath HTTP/2.
Not all waiting disappears. Requests can depend on other results, congestion and resources are shared, and QPACK field decoding can await table entries. Page latency still depends on application dependencies, server processing and the actual network path.
Compression state must tolerate reordered delivery
HPACK assumes connection-ordered field-block processing, so directly reusing it over QUIC would reintroduce dependencies. QPACK instead updates and acknowledges dynamic-table state on dedicated streams while request fields reference that state.
Encoders trade compression efficiency against blocking risk, and receivers bound table capacity and potentially blocked streams. New transport capabilities still require peer support and appropriate resource budgets.