ToppyMicroServices

RFC 9113 Quiz

HTTP/2のmultiplexingを理解する

🇺🇸 🇯🇵
0 / 0

References (URLs)

Q1: HTTP/2がHTTP/1.1に対して追加した大きな能力はどれ

Multiple Choice
HTTP/2 を理解するときは, まず「1 本の connection の中に複数 stream が並んでいる」図を頭に持つと読みやすくなります. RFC 9113 は, その multiplexing を frame と state machine で定義する文書です.
1 TCP connection client と server の間 stream 1 HEADERS, DATA stream 3 HEADERS, DATA stream 5 HEADERS, DATA binary frame で交互に流れる
**Explanation:** multiplexing, stream, connection. HTTP/2はbinary framing layerで, 独立streamを同一connection上に流せる. HTTP/2は複数のrequest/responseを1 connection上の独立したstreamへ割り当て, frame, flow control, stream stateでそれぞれを管理します. multiplexingにより, HTTP/1.1のpipeliningに比べてHTTPレイヤのhead-of-lineを減らします. 1 connection しかなくても, stream ごとに独立したやり取りを進められるのが大きな変化です. - A (incorrect): HTTPのセマンティクス(=methodやstatus codeの意味づけ)はRFC 9110で定義され, HTTP/2で変わらない. - B (correct): これがtransport面での主要な変化. - C (incorrect): HTTP/2は通常TLS上で動くが, TLSを置き換えない. ただし TCP 上なので, transport レイヤの head-of-line は残ります. そこが HTTP/3 / QUIC へ話がつながるポイントです.

Q2: HTTP/2のwire上の基本単位はどれ

Multiple Choice
**Explanation:** frame, binary framing layer. HTTP/2はframeの列として通信し, frame headerで種別や長さを表す. frameがheaders, data, settingsなどを運ぶ. - A (incorrect): それはHTTP/1.1. - B (incorrect): chunkedはHTTP/1.1の転送方式. - C (correct): HTTP/2はbinary frame. HTTPのセマンティクスは同じでも, framing layerが違うと実装の落とし穴が変わる.

Q3: HTTP/2のstream IDの奇偶ルールとして正しいのはどれ

Multiple Choice
**Explanation:** stream ID, initiator. stream IDは順序と開始者を示し, protocol error検出に役立つ. clientは奇数, serverは偶数を使う. - A (correct): clientが開始するstreamには奇数ID, serverが開始するstreamには偶数IDを割り当てます. - B (incorrect): initiatorと奇偶の対応が逆です. client側のstream ID namespaceは奇数から始まります. - C (incorrect): 最下位bitがinitiatorを表すため, 奇偶を無視するとpeerが開始したstreamを正しく判定できません. stream IDの単調増加も重要で, 再利用や不正frameを検出する.

Q4: stream 5のDATA送信を再開させるupdateはどれ?

Multiple Choice

HTTP/2 senderはstream 5のflow-control windowとconnection windowの両方を使い切りました. receiverは十分なDATAを消費し, stream 5の送信を継続させたいとします.

**Explanation:** A: connection windowが0の間はstream creditを利用できません. B: connection creditだけではstream 5自身のzero windowを解除できません. C: RFC 9113 Sections 5.2と6.9はDATAについてstreamとconnectionの独立windowを定義し, 枯渇した両方を増やす必要があります. D: SETTINGS_MAX_CONCURRENT_STREAMSはstream作成数を制限し, DATA creditを補充しません. 判定基準: 枯渇したflow-control scopeをすべて特定します. senderはstreamとconnectionの両windowが許すときだけDATAを送れます.

Q5: gatewayはこのHTTP fieldをどう転送する?

Multiple Choice

gatewayは1本のHTTP/2 connectionを終端し, backendへ別のHTTP/2 connectionを開きます. 効率化のためclientのraw HPACK field blockをbackend connectionのHEADERS frameへコピーする予定です.

**Explanation:** A: originが同じでもHPACK dynamic-table stateはconnection間で共有されません. B: RFC 9113 Section 4.3.1はendpointごと, connectionごとのencoder/decoder contextを定義します. gateway越しではsemantic fieldをdecodeし, 次のcontextでre-encodeします. C: stream-ID置換ではfirst connectionで作られたdynamic-table referenceを修復できません. D: 後続SETTINGS valueは既にencodeしたfield blockを遡ってdecodableにはしません. 判定基準: compression byteはconnection-bound protocol stateです. reconstructed HTTP fieldだけがgateway boundaryを安全に越えられます.

Q6: このGOAWAYから導けるretry判断はどれ?

Multiple Choice

clientはnon-idempotentなPOSTをstreams 5と9で送りました. どちらのresponseも届く前にserverがLast-Stream-ID 7のGOAWAYを送ります. application-level deduplication contractはありません.

**Explanation:** A: RFC 9113 Section 6.8はLast-Stream-ID以下のstreamが処理済みかもしれないとします. B: valueより大きいstreamは処理されず今後も処理されないため, stream 9にはdefiniteなtransport outcomeがあります. C: Section 6.8によりstream 9は未作成同様に扱えます. stream 5はeffect済みかもしれず, RFC 9110 Section 9.2.2はnon-idempotent POSTのautomatic repeat前にapplication knowledgeを要求します. D: 解釈が逆です. value以下は処理済みの可能性があり, それより大きいIDが除外されます. 判定基準: GOAWAYはprocessing boundaryを確立しますがuniversal retry safetyではありません. method effectとapplication deduplication保証を組み合わせます.