RFC 9204 Quiz

**Explanation:** QPACKは, QUIC streamの独立したdeliveryと共有compression stateのordering requirementを両立させるために必要です. **HPACK** は HTTP/2 向けの header compression です. **QPACK** は HTTP/3 の配送特性に合わせて, block の扱いを変えた方式です. HTTP/2 と HTTP/3 の差を説明するときに, 単に transport が違うではなく, compression 戦略まで変わる理由を語れるようになります. QPACK は HPACK の考え方を捨てたのではなく, ordered delivery 前提の危うさを避ける方向へ作り直しています. A: HPACKで問題になるordering依存は共有compression stateであり, TLS recordの有無や順序ではありません. B: QPACKはtable updateとfield sectionを分離し, blockingを制限することで, 1つの遅延が全HTTP/3 streamへ広がるのを避けます. C: HPACKはstreamごとの独立tableではなく, connection-wideなcompression stateを使います.

**Explanation:** QPACK の設計判断は, 「何が安全で, 何が block を呼ぶか」を分けて考えられるかでかなり変わります. RFC 9204 Section 2.1は,static-table参照とdynamic-table参照を含まないliteral representationはdynamic stateを必要とせず,head-of-line blocking riskがないとします.literal field lineでもdynamic-tableのnameを参照できるため,option Cはそのcaseを明示的に除外しています. loss や reordering がある回線で, encoder をどこまで攻めるかを決めるときにこの区別が効きます. QPACK は, bytes を節約するか, 待ちを減らすかを encoder が都度選べるようにした設計です. A: decoder がまだ知らない dynamic entry は block の原因になります. B: static table は共有前提が固定なので安全です. C: literal は wire size は増えても state 依存を避けられます. D: これも dynamic table 参照なので block し得ます.

**Explanation:** QPACKはcross-stream blockingを制限しますが, 未到着dynamic entryへ依存するfield section自体はblockし得ます. **Required Insert Count** は, decode に必要な dynamic table の到達点です. **Insert Count** は decoder が今どこまで知っているかを表します. header decode が詰まる理由を調べるときや, encoder の aggressiveness を調整するときに重要です. QPACK は block を消したのではなく, encoder がそのリスクを制御しやすい形へ移したと理解すると分かりやすいです. A: decoder が勝手に表現を変えるわけではありません. B: path migration は QUIC の別機能です. C: 必要 state が来るまで stream は block されます.

**Explanation:** QPACK では圧縮方式だけでなく, どれくらい待ちを許すかという運用上の上限設定が重要です. **SETTINGS_QPACK_BLOCKED_STREAMS** は, dynamic table state 不足で block してよい stream 数を decoder 側が制約する setting です. mobile network や loss が多い経路で, どこまで dynamic 参照を積極的に使うかの tuning に関わります. blocked stream を強く絞ると, encoder は literal や安全な参照を多めに選ぶ必要が出てきます. A: これが setting の本旨です. B: packet size の話ではありません. C: trailer 数の制御ではありません.

**Explanation:** RFC 9204 Section 2.1.2は,transit中のdynamic参照による圧縮改善と,acknowledged entryまたはliteralによるblocking回避のtrade-offを明記します. **acknowledged entry** は decoder が利用可能だと encoder が見なせる dynamic entry です. **literal** は大きくなっても待ちを作りません. browser, CDN, reverse proxy の encoder policy で, どこまで aggressive に dynamic table を使うかの判断に直結します. QPACK の本質は, bytes と latency の交換条件を encoder が持てるようにした点です. A: 圧縮率は上がっても block リスクも上がります. B: 低遅延重視ならこちらが現実的です. C: flow control は QPACK の block 解決策ではありません.

**Explanation:** encoder streamはrequest bodyではなくdecoder側のdynamic table stateを進めます. **encoder stream** は encoder から decoder へ向かう一方向 stream で, dynamic table 更新 instruction を運びます. ここが壊れると application logic ではなく compression state の同期で失敗しているのに, 原因を見誤りやすくなります. QPACK では「header block」と「state 更新」が別 stream に分かれていることが設計の要です. A: bodyはQPACK encoder streamではなくrequest/response streamで運ばれます. B: HTTP/3 settingはHTTP/3 control streamで運ばれ, QPACK encoder streamはそれを置き換えません. C: encoder instructionによってdecoder側のdynamic table entryを追加・複製し, capacityを変更します.

**Explanation:** QPACK の理解では, encoder が decoder の状態をどう知るかを押さえておく必要があります. **decoder stream** は decoder から encoder へ返す feedback 用の stream で, acknowledgment などを通じて encoder の次の選択に影響します. 「なぜその entry を参照してよいと判断したのか」を説明するための前提になります. encoder が decoder の進み具合を知らなければ, block リスクをまともに制御できません. A: これが decoder stream の役目です. B: application payload を運ぶ stream ではありません. C: trailer 専用ではありません.

**Explanation:** RFC 9204 Section 7.1はdynamic-table stateのprobingと情報漏洩を分析します. **compression side channel** は, size や圧縮のされ方から hidden value の手掛かりが漏れる状況です. shared compression state はその土台になり得ます. browser, intermediary, shared upstream connection で, 別主体の traffic がどこまで state を共有してよいかを考えるときに重要です. 高 entropy の secret は当てにくいですが, だから安全と言い切るのではなく, sensitive field をどう扱うかを別途考えるべきです. A: DNS trust が主題ではありません. B: ここが RFC の caution point です. C: そこまで単純な禁止の話ではありません.

**Explanation:** QPACK は latency だけでなく memory も trade-off に入っており, table capacity を軽視できません. **dynamic table capacity** は, index 化のために保持できる state の大きさです. endpoint の memory budget, library の default tuning, resource 制約の厳しい client 実装で効いてきます. table を大きくすると圧縮には有利でも, memory 消費と state 管理は重くなります. A: stream 数の制御ではありません. B: body size を決める setting ではありません. C: dynamic table の上限を決めます.

**Explanation:** RFC 9204 Section 2.1.2では, `SETTINGS_QPACK_BLOCKED_STREAMS`を未到着のdynamic-table entryによってblockedになり得るstream数の上限と定めています. encoderはこのdecoder提示値の範囲内に収めなければなりません. encoderはacknowledge済みdynamic entryだけを参照するか, static-tableまたはliteral表現を使うことで, 追加のblocked streamを避けられます. A: settingは単なるadvisoryではなく強制され, 2本をblockedにすると提示上限1を超えます. B: RFC 9204は, このencoder違反を超過分のrequest streamだけのresetでは回復させません. C: decoderが提示数を超えるblocked streamに遭遇した場合, `QPACK_DECOMPRESSION_FAILED`として扱わなければなりません.