RFC 9204 Quiz

**Explanation:** **問題を出した背景:** QPACK を理解する入口は命令形式よりも, 「なぜ別方式が必要だったか」を掴むことです. **用語:** **HPACK** は HTTP/2 向けの header compression です. **QPACK** は HTTP/3 の配送特性に合わせて, block の扱いを変えた方式です. **実務での機会:** HTTP/2 と HTTP/3 の差を説明するときに, 単に transport が違うではなく, compression 戦略まで変わる理由を語れるようになります. **選択肢:** - A (incorrect): TLS renegotiation は本題ではありません. - B (correct): ここが QPACK の出発点です. - C (incorrect): HPACK は trailer 専用ではありません. **関連:** QPACK は HPACK の考え方を捨てたのではなく, ordered delivery 前提の危うさを避ける方向へ作り直しています.

**Explanation:** **問題を出した背景:** QPACK の設計判断は, 「何が安全で, 何が block を呼ぶか」を分けて考えられるかでかなり変わります. **用語:** **static table** は仕様で固定済みです. **literal** はその場で値を運ぶので, dynamic state に頼りません. **dynamic table** 参照は state 依存です. **実務での機会:** loss や reordering がある回線で, encoder をどこまで攻めるかを決めるときにこの区別が効きます. **選択肢:** - A (incorrect): decoder がまだ知らない dynamic entry は block の原因になります. - B (correct): static table は共有前提が固定なので安全です. - C (correct): literal は wire size は増えても state 依存を避けられます. - D (incorrect): これも dynamic table 参照なので block し得ます. **関連:** QPACK は, bytes を節約するか, 待ちを減らすかを encoder が都度選べるようにした設計です.

**Explanation:** **問題を出した背景:** 「QPACK なら block しない」と短く覚えると, 実装や debug の場面で誤解します. **用語:** **Required Insert Count** は, decode に必要な dynamic table の到達点です. **Insert Count** は decoder が今どこまで知っているかを表します. **実務での機会:** header decode が詰まる理由を調べるときや, encoder の aggressiveness を調整するときに重要です. **選択肢:** - A (incorrect): decoder が勝手に表現を変えるわけではありません. - B (incorrect): path migration は QUIC の別機能です. - C (correct): 必要 state が来るまで stream は block されます. **関連:** QPACK は block を消したのではなく, encoder がそのリスクを制御しやすい形へ移したと理解すると分かりやすいです.

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

**Explanation:** **問題を出した背景:** QPACK は「常に一番圧縮する」のが正解ではなく, block してまで bytes を削る価値があるかを問う設計です. **用語:** **acknowledged entry** は decoder が利用可能だと encoder が見なせる dynamic entry です. **literal** は大きくなっても待ちを作りません. **実務での機会:** browser, CDN, reverse proxy の encoder policy で, どこまで aggressive に dynamic table を使うかの判断に直結します. **選択肢:** - A (incorrect): 圧縮率は上がっても block リスクも上がります. - B (correct): 低遅延重視ならこちらが現実的です. - C (incorrect): flow control は QPACK の block 解決策ではありません. **関連:** QPACK の本質は, bytes と latency の交換条件を encoder が持てるようにした点です.

**Explanation:** **問題を出した背景:** stream type の番号を覚えるより, その stream が「何の state を進めるか」を理解する方が重要です. **用語:** **encoder stream** は encoder から decoder へ向かう一方向 stream で, dynamic table 更新 instruction を運びます. **実務での機会:** ここが壊れると application logic ではなく compression state の同期で失敗しているのに, 原因を見誤りやすくなります. **選択肢:** - A (incorrect): body は request/response stream で運ばれます. - B (incorrect): すべての control traffic を置き換えるわけではありません. - C (correct): これが encoder stream の中核です. **関連:** QPACK では「header block」と「state 更新」が別 stream に分かれていることが設計の要です.

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

**Explanation:** **問題を出した背景:** QPACK の security は暗号を破る話ではなく, compression が情報をにじませる話だと掴む必要があります. **用語:** **compression side channel** は, size や圧縮のされ方から hidden value の手掛かりが漏れる状況です. shared compression state はその土台になり得ます. **実務での機会:** browser, intermediary, shared upstream connection で, 別主体の traffic がどこまで state を共有してよいかを考えるときに重要です. **選択肢:** - A (incorrect): DNS trust が主題ではありません. - B (correct): ここが RFC の caution point です. - C (incorrect): そこまで単純な禁止の話ではありません. **関連:** 高 entropy の secret は当てにくいですが, だから安全と言い切るのではなく, sensitive field をどう扱うかを別途考えるべきです.

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

**Explanation:** **問題を出した背景:** RFC 9204 の学習ゴールは, instruction 名の暗記ではなく, encoder policy を trade-off として語れるようになることです. **用語:** **blocked streams**, **loss**, **dynamic table 利用**, **compression gain** が, QPACK の現場で本当に効く論点です. **実務での機会:** browser, CDN, reverse proxy, HTTP library の review で, encoder をどこまで攻めるかの議論に直結します. **選択肢:** - A (correct): QPACK の核心を operational な判断に落としています. - B (incorrect): 圧縮率だけ見て待ち時間を無視するのは危険です. - C (incorrect): literal は安全側へ倒すための重要な逃げ道です. **関連:** QPACK を分かったと言えるのは, bytes を削る判断と latency を守る判断の両方を説明できるときです.