ToppyMicroServices

RFC 9114 Quiz

HTTP/3 on QUIC

🇺🇸 🇯🇵
0 / 0

References (URLs)

Q1: HTTP/3が動作するtransport protocolはどれ

Multiple Choice
**Explanation:** HTTP/3, QUIC. HTTP/3はHTTPのセマンティクス(意味/ルール)をQUIC streamへmappingしたもの. HTTP/3はQUIC上で動く. - A (correct): QUICはstreamと暗号統合, migrationを提供. - B (incorrect): TCPはHTTP/1.1や一般的なHTTP/2で使われる. - C (incorrect): SCTPはHTTP/3の基盤ではない. QUICは多くの環境でUDP上に実装される.

Q2: HTTP/2 over TCPと比べてHTTP/3が減らすことを狙う問題はどれ

Multiple Choice
HTTP/2 は多くの request を 1 本の TCP byte stream に載せるため, 1つの loss が全streamの待ちに繋がります. QUIC はその巻き込みを減らします.
TCP で packet loss 1本の ordered byte stream 全streamが待つ HTTP/2 stream 停滞 cross-streamの足止め QUIC で stream A loss stream state は分離 stream B は進める HTTP/3 on QUIC 巻き込み待ちを減らす
**Explanation:** head-of-line blocking, TCP, QUIC stream. TCPの損失回復は1本のbyte streamに依存し, 1つの損失が全streamの進行に影響し得る. HTTP/3はQUICにより, stream間の足止めを減らすことを狙う. - A (incorrect): DNSはHTTP versionとは別. - B (incorrect): HTTP/3もTLS 1.3相当の保護を使う. - C (correct): これが移行の主要動機の1つ. アプリ側のスケジューリング次第で待ちが出ることはあるが, transportの性質は改善する.

Q3: HTTP/3でのheader圧縮の仕組みはどれ

Multiple Choice
**Explanation:** header compression, QPACK, QUIC. headerは多いので圧縮が有効だが, decode待ちがhead-of-lineを作ると逆効果になる. HTTP/3はQPACKを使い, QUIC stream特性に合わせてheader圧縮を行う. - A (incorrect): 認証は別の層の話. - B (correct): header圧縮が目的. - C (incorrect): congestion controlは主にQUICの機能. HTTP/2はHPACK. HTTP/3はQPACKで, ordered delivery依存を減らす.

Q4: peerは閉じたcontrol streamをどう扱う?

Multiple Choice

HTTP/3 endpointはSETTINGS frameを送った後, control streamをclean closeし, connection-level frameを続けるため2本目のcontrol streamを開きました.

**Explanation:** A: RFC 9114 Section 6.2.1はpeerごとにcontrol streamを1本だけ許し, closeを禁止します. SETTINGS repeatでは失ったconnection stateを復元できません. B: SETTINGSやGOAWAYなどconnection-level frameには定義済みのstream位置があり, request streamへ移すとinvalidです. C: Section 6.2.1はcontrol stream closureにH3_CLOSED_CRITICAL_STREAMを要求します. 2本目も独立にH3_STREAM_CREATION_ERRORとなります. D: control streamはHTTP/3 connectionを管理するため, lossは1本のrequestに限定されません. 判定基準: critical-stream continuityはconnection invariantです. replacement streamをapplication-level failoverとして設計しません.

Q5: clientはこのHTTP/3 connectionを再利用できる?

Multiple Choice

clientはhttps://a.exampleへのHTTP/3 connectionを持ちます. DNS上のb.exampleは同じIPとUDP portですが, server certificateはa.exampleについてだけacceptableです. 既存connectionでhttps://b.exampleをrequestしようとしています.

**Explanation:** A: network locationはそのendpointがhostする全nameへのHTTP authorityを確立しません. B: RFC 9114 Section 3.3はconnectionをnew originへ再利用する前にoriginごとのcertificate validationを要求します. このcertificateはb.exampleにacceptableでないため再利用できません. C: QPACKはcompression stateを検証するもので, origin authorityやcertificate identityではありません. D: Section 3.3はserver certificateがadditional originにもacceptableならcross-origin reuseを許します. 判定基準: coalescingは各originへのauthorityを条件とし, endpoint一致や別originへの既存authenticationだけでは決めません.

Q6: gatewayはauthority conflictをどう扱う?

Multiple Choice

HTTP/3 gatewayは:authority = agent-a.exampleとHost: agent-b.exampleを持つHTTPS requestを受けました. routingとauthorization policyは両valueで異なるtenantを選びます. requestをHTTP/1.1へ変換する予定です.

**Explanation:** A: Hostを選ぶと:authorityで主張されたtargetを黙って変更し, tenant boundaryを越え得ます. B: RFC 9114はこのconflictのoverride ruleを定義せず, Section 4.3.1は両方ある場合の同一valueを要求します. C: requestはSection 4.3.1違反でmalformedです. Section 4.1.2は別targetへrepairせずmalformed requestをrejectするよう要求します. D: routingとauthorizationでauthorityを分けると, canonical input validationが防ぐべきinterpretation splitを作ります. 判定基準: protocol translation前にHTTP/3 control dataを検証します. canonicalizationはequivalent syntaxをnormalizeできますが, contradictory authorityへprecedenceを作ってはいけません.