HTTP/3 does not reuse HPACK; it defines QPACK instead. What property of QUIC made HPACK unusable, and what does QPACK do differently to avoid the problem?

## The assumption HPACK bakes in HPACK compression is *stateful and incremental*. Encoding of header block N depends on every insertion performed while encoding blocks 1 through N-1, and the decoder rebuilds that state by processing blocks in the identical order. If block 5 arrives before block 4, its indices refer to a table the decoder has not built yet, and the result is not a delay but a decode error - HPACK treats desynchronisation as a fatal connection error. Over TCP this costs nothing to guarantee: the transport delivers one byte stream in order, so HTTP/2 header blocks are inherently ordered. ## Why QUIC breaks it QUIC's central improvement is that streams are independent. A lost packet carrying stream 3's data does not hold back stream 7's data; the receiver delivers stream 7 immediately. There is **no total order across streams** - only per-stream order. Drop HPACK into that and you get the worst outcome: to keep the table consistent, the receiver must process header blocks in the order the sender produced them, so a lost packet on one request's headers stalls decoding of every later request's headers. You would have paid QUIC's complexity and re-imported head-of-line blocking at the HTTP layer, in the one place it hurts most - request headers, which gate everything downstream. ## QPACK's structure QPACK keeps HPACK's ideas - a static table (99 entries, indices 0-98, retuned to observed traffic), a size-bounded FIFO dynamic table, Huffman coding with the same code - and changes *where state updates travel*. **Two dedicated unidirectional QUIC streams per direction:** - The **encoder stream** carries table mutations only: insert-with-name-reference, insert-with-literal-name, duplicate, set-capacity. Being a single QUIC stream, it is internally ordered, so the dynamic table is still built deterministically. - The **decoder stream** carries feedback: Section Acknowledgment (this header section was decoded, so the entries it used are known-received), Stream Cancellation, and Insert Count Increment (I have processed this many insertions). **Header sections on request streams reference the table** by a *Required Insert Count* - the number of insertions the decoder must have processed before this section can be decoded - and a *Base*, which makes references relative so a section is not perturbed by insertions made after it was encoded. Post-Base indexing lets a section reference entries inserted as part of encoding it. ## Blocking, made explicit and bounded If a header section arrives with Required Insert Count 12 but the decoder has only processed 9 insertions (encoder-stream packets still in flight or lost), **that single stream** waits. Other streams proceed. The blocking is scoped, not connection-wide. Two controls govern it: - `SETTINGS_QPACK_BLOCKED_STREAMS` - the decoder tells the encoder how many simultaneously blocked streams it will tolerate (commonly zero to a small number, since a blocked stream costs buffered state). The encoder must not exceed it. - **Encoder policy** - the encoder can always avoid blocking by referencing only acknowledged entries, or by emitting literals. This is a pure ratio-versus-latency dial, chosen by the implementation, not by the format. Many deployed encoders are conservative: they insert aggressively but reference only acknowledged entries, so steady-state connections still index almost everything while never blocking. On a fresh connection the first few requests compress slightly worse than HTTP/2 would. ## The trade you should be able to state HPACK maximises ratio and assumes a total order. QPACK accepts a small, tunable ratio loss to preserve stream independence. That is the whole design: the compression context is inherently shared connection state, and the only ways to keep it consistent are to force an order (HPACK) or to make the dependency explicit and bounded (QPACK). ## Operational notes - QPACK settings are a real tuning surface at edge proxies: dynamic table capacity and blocked-stream allowance trade memory and latency against bytes. - A capacity of zero is legal and turns QPACK into static-table-plus-Huffman only - simple, stateless, and a defensible choice for a server with enormous connection counts and short-lived connections. - Symptoms of a bad encoder policy show up as HTTP/3 being no faster than HTTP/2 on lossy links, because header sections wait on the encoder stream.