HPACK vs QPACK: HTTP Header Compression Compared

Header Compression: HPACK vs QPACK

HTTP headers are sent with every request and response. Without compression, headers can be 500-800 bytes each, with much of the content repeated across requests (cookies, user-agent, accept headers).

HPACK (HTTP/2)

HPACK (RFC 7541) compresses headers using two mechanisms:

1. Static table: 61 pre-defined common headers (e.g., :method: GET, content-type: text/html)
2. Dynamic table: Headers encountered during the connection are added and referenced by index

The encoder and decoder maintain synchronized dynamic tables. When the encoder adds a header, the decoder adds it in the same position. This works perfectly with TCP because TCP guarantees in-order delivery.

The Problem with HPACK on QUIC

QUIC delivers streams independently and out of order. If Stream 1 adds a header to the dynamic table and Stream 2 references it, but Stream 2's packet arrives before Stream 1's, the decoder cannot resolve the reference. This would cause an error.

QPACK (HTTP/3)

QPACK (RFC 9204) solves this with a different architecture:

1. Encoder stream: A dedicated unidirectional QUIC stream for table updates
2. Decoder stream: A dedicated stream for acknowledgments
3. Known received count: The decoder tracks which table entries are available

When encoding a header that references a dynamic table entry, QPACK can either:

• Block the stream until the referenced entry is confirmed received
• Use a literal representation to avoid blocking

HPACK (HTTP/2):             QPACK (HTTP/3):
All on one TCP stream       Separate encoder/decoder streams
In-order guaranteed         Out-of-order safe
Simpler implementation      More complex, but QUIC-compatible

Compression Efficiency

In practice, HPACK and QPACK achieve similar compression ratios (typically 85-95% reduction in header size). QPACK's overhead from the separate streams is minimal, and the ability to work with out-of-order delivery makes it essential for HTTP/3.