RFC 9204 Quiz

**Explanation:** The most important QPACK idea is not the bit layout. It is the transport mismatch that made HPACK unsafe to reuse as-is for HTTP/3. **HPACK** assumes ordered delivery suitable for HTTP/2 over a single ordered byte stream. **QPACK** adapts header compression for HTTP/3 over QUIC, where out-of-order delivery matters. In practice this helps you explain why HTTP/3 performance tuning is not “HTTP/2 plus UDP,” and why header compression design changed. QPACK keeps HPACK ideas like static and dynamic tables, but redesigns how state is coordinated so implementations can choose their blocking risk. A: HPACK's relevant ordering dependency is its shared compression state, not the presence or ordering of TLS records. B: QPACK separates table updates from field sections and bounds blocking so one delayed update need not stall every HTTP/3 stream. C: HPACK uses connection-wide compression state rather than an isolated table for each stream.

**Explanation:** The best way to reason about QPACK is to separate “cheap and safe” references from “more efficient but potentially blocked” references. RFC 9204 Section 2.1 states that static-table references and literal representations without dynamic-table references need no dynamic state and never risk head-of-line blocking. A literal field line can still use a dynamic-table name reference, so option C expressly excludes that case. This distinction drives encoder decisions when there is packet loss, reordering, or strict latency targets. A practical encoder often mixes literals, static references, and dynamic references depending on latency tolerance and connection state. A: Unacknowledged dynamic references are exactly the kind that can block decoding. B: Static table references do not depend on decoder dynamic state. C: Literals are bigger on the wire but avoid state dependence. D: Post-Base is still a dynamic table reference and can block.

**Explanation:** Engineers often hear “QPACK reduces head-of-line blocking” and mistakenly conclude that blocking is impossible. It is reduced, not eliminated. **Required Insert Count** says how much dynamic table state the decoder must have before it can decode the field section. **Insert Count** is how many entries the decoder currently knows. This directly affects tail latency, debugging of header decode stalls, and why encoder choices matter under packet loss. QPACK moves the trade-off toward encoder choice. Better compression can still create blocking if the required state is not available in time. A: The decoder does not invent a fallback representation on its own. B: Path migration is a QUIC concern, unrelated to QPACK decode readiness. C: The field section is blocked until the needed dynamic state arrives.

**Explanation:** QPACK is as much about operational limits as about compression format. Blocked-stream limits are a key control surface. **SETTINGS_QPACK_BLOCKED_STREAMS** is a decoder-provided bound on how many streams can be blocked due to missing dynamic table state. This setting matters when tuning encoder aggressiveness for mobile loss, prioritization, and latency-sensitive traffic. Lower blocked-stream tolerance pushes encoders toward safer but larger encodings, such as literals or acknowledged references only. A: This is the direct meaning of the setting. B: Packet sizing is unrelated. C: Trailers are not what this setting limits.

**Explanation:** RFC 9204 Section 2.1.2 explicitly gives the encoder a choice between better compression from in-transit dynamic references and avoiding blocking with acknowledged entries or literals. **acknowledged entries** are dynamic table entries known to be available at the decoder. **literals** are bigger but avoid dependency on dynamic state. This shows up in CDN and browser stacks where a few bytes saved are not worth stalling request processing under loss or reordering. QPACK shifts complexity toward encoder policy, where compression gain has to be balanced against blocking risk. A: This maximizes compression potential, but it also maximizes blocking risk. B: This is the safer strategy when latency matters more than squeezing every byte. C: Flow control is not the knob that solves QPACK blocking.

**Explanation:** QPACK uses dedicated coordination streams so dynamic table state can advance independently from request and response field sections. The **encoder stream** is a unidirectional stream that carries encoder instructions from encoder to decoder. Those instructions update the dynamic table state. If this stream is mismanaged, header decoding can fail even when the application logic looks correct. QPACK also has a decoder stream in the opposite direction so the encoder can learn what the decoder has processed. A: HTTP bodies travel on request or response streams, not the QPACK encoder stream. B: QPACK streams are specialized, not replacements for all HTTP/3 control traffic. C: This is the essential job of the encoder stream.

**Explanation:** QPACK is intentionally designed so the encoder can track decoder readiness. The decoder stream is central to that feedback loop. The **decoder stream** carries feedback from decoder to encoder, including acknowledgments and related instructions that inform future encoding decisions. This matters when tuning whether the encoder can safely reference newer dynamic entries without creating blocked streams. QPACK works because the encoder can trade compression ratio against the decoder's confirmed state instead of assuming global ordering. A: This feedback lets the encoder know which dynamic state is safe to depend on. B: Application payloads do not travel on the decoder stream. C: The stream is not limited to trailers.

**Explanation:** RFC 9204 Section 7.1 analyzes probing of dynamic-table state and the resulting information leakage. A **compression side channel** exists when output size or encoding behavior leaks information about hidden values. Shared compression context makes that more plausible. Browsers, intermediaries, and shared upstream connections need to reason about whether different parties can affect or observe the same compression state. High-entropy secrets are harder to recover than low-entropy values, but the safe lesson is still to treat sensitive fields cautiously in shared compression contexts. A: DNS trust is unrelated to the QPACK security model here. B: This is the actual concern described in the RFC. C: HTTP/3 does not forbid all such reuse in this simplistic way.

**Explanation:** QPACK performance is constrained by memory as well as latency. Table-capacity limits are part of that resource contract. **dynamic table capacity** is the amount of space available for entries used in indexed compression on a connection. This matters for memory budgeting, endpoint hardening, and deciding how much dynamic compression state is worth maintaining. A larger table can improve compression ratio, but it also increases state memory and coordination complexity. A: Stream count is a different transport concern. B: Body size is unrelated to this QPACK setting. C: This setting bounds dynamic table capacity.

**Explanation:** RFC 9204 Section 2.1.2 defines `SETTINGS_QPACK_BLOCKED_STREAMS` as the decoder's upper bound on streams that can be blocked by unavailable dynamic-table entries. The encoder must stay within that bound. An encoder can avoid risking another blocked stream by referencing only acknowledged dynamic entries or by using static-table or literal representations. A: The setting is enforced, not merely advisory; accepting two blocked streams would exceed the advertised bound of one. B: RFC 9204 does not recover from this encoder violation by resetting only the excess request stream. C: A decoder that encounters more blocked streams than it promised must treat it as `QPACK_DECOMPRESSION_FAILED`.