ToppyMicroServices

RFC 9000 Quiz

QUIC transportの基本

🇺🇸 🇯🇵
0 / 0

References (URLs)

Q1: QUICを高レベルに説明したものとして最も近いのはどれ

Multiple Choice
**Explanation:** transport, multiplexed, secure, UDP. QUICはstreamと信頼性, 暗号統合を提供する. UDPを基盤にしつつ, 複数streamの多重化と暗号化を組み込んだtransport. - A (incorrect): QUICはUDP上の独立したtransportであり, TCP connection内で交渉するextensionではありません. - B (correct): QUICはUDP datagramを使い, secureなconnectionと複数のstreamを提供します. - C (incorrect): QUICはUDP datagramを使いますが, secure connection state, reliable stream, loss recovery, congestion controlを追加します. HTTP/3はQUIC上にHTTPを載せる.

Q2: QUIC connection IDの主な目的として正しいのはどれ

Multiple Choice
QUIC connection ID があると, 古い path の IP:port に縛られず, path が変わっても同じ connection を継続しやすくなります.
旧 path IP:port A 新 path IP:port B 同じ QUIC connection ID 1つの path 固定ではない connection 継続 server側では 同じ connection
**Explanation:** connection ID, migration. connection IDはIPとportの組から独立にconnectionを識別する手段. path変更でも同一connectionとして継続でき, LBでのルーティングにも使われる. - A (correct): connectionを1つのIP:port tupleだけで識別しないため, migrationやNAT rebinding後もpacketを同じconnectionへ対応付けられます. - B (incorrect): certificateによるpeer authenticationはTLSの役割であり, connection IDはその代わりになりません. - C (incorrect): URIはHTTPなどのapplication protocolが扱い, QUICのtransport identifierには格納しません. 一部環境ではconnection IDでpacketをLBへルーティングする.

Q3: stream 4 のdataを含むpacketが失われた. その後, streams 8と12のdataを含むpacketが到着した. QUICのstream orderingに合うreceiverの挙動はどれ

Multiple Choice
**Explanation:** RFC 9000 Section 2はQUIC streamをordered byte sequenceと定義しますが, 異なるstreamのbyte間には順序を定義しません. stream 4はgapより後のdataをまだ渡せませんが, 独立して受信できたstreams 8と12のdataは渡せます. - A (incorrect): QUICにはstreams 8と12をstream 4に従わせるconnection-wideなbyte順序はありません. - B (incorrect): stream 4内では順序を守るためgapを飛び越えて渡せませんが, 他のstreamまで待たせる必要はありません. - C (correct): stream 4内の順序を保ちながら, その順序をstreams 8と12へ広げない挙動です. stream 4のbyte gapはstreams 8と12にin-order deliveryの待ちを強制しません. ただし, congestion controlはconnection全体へ影響し得ます.

Q4: 報告されたblockを解消するcredit更新はどれ?

Multiple Choice

senderはstream 8で通知済みのoffset limitに達し, STREAM_DATA_BLOCKEDを送信しました. connection全体のMAX_DATAには十分なcreditが残り, 受信applicationはstream 8のdataをさらに消費済みです.

**Explanation:** A: connection creditは枯渇していないため, それだけを増やしてもstream 8のblockは残ります. B: RFC 9000 Section 4.1はstreamとconnectionのlimitを別々に定義します. MAX_STREAM_DATAは指定streamで許容する絶対offsetを増やします. C: 小さいlimitの再通知は効果がなく, senderはlimitを増やさないupdateを無視します. D: WINDOW_UPDATEはHTTP/2のframeです. QUICはMAX_STREAM_DATAとMAX_DATAを使います. 判定基準: creditを追加する前に枯渇したlimitを特定します. stream creditとconnection creditは別のreceiver capacity制約を解消します.

Q5: serverは新しいclient addressをどう扱うべき?

Multiple Choice

handshake確認後, serverは既存connectionについて保護を正しく検証できるnon-probing packetを, NAT rebindingと整合する新しいclient IP:portから受信しました. このaddressは未検証です.

**Explanation:** A: authenticなpacketはconnectionとの関連を示しますが, RFC 9000 Section 8.2は新pathのreachabilityに対応するPATH_RESPONSEを要求します. B: Section 9はmigrationを明示的に扱います. 既に検証済みでないpeer addressの変更後はpath validationが必要です. C: Sections 8.2と9.3に沿う処理です. migrationとanti-amplificationの規則を守って新pathへ応答し, 未開始なら検証を開始します. D: Section 8.2.3はACKではpath validationにならないと定めます. unpredictableなPATH_CHALLENGE値の返送が必要です. 判定基準: 有効なconnection packetはmigration処理を開始できますが, 新しいaddress pairのreachabilityを確立するのはpath-validation exchangeです.

Q6: RFC 9000の保証範囲に沿うsecurity reviewはどれ?

Multiple Choice

A2A gatewayはQUIC connection開始時にagentを認証しますが, source IP addressをauthorization principalとして保存します. 後にconnectionが移動し, 新addressのpath validationに成功しました. gatewayはconnection IDが同じなのでprivileged requestを許可する予定です.

**Explanation:** A: RFC 9000 Section 8.2が検証するのはaddress pairのreachabilityであり, address背後のapplication principalではありません. B: Section 9はconnection migrationを許します. RFC 9000は最初のsource addressをapplication authorizationに使うよう要求しません. C: transport保証とapplication判断を分離します. connectionを継続しつつ, principal識別用に設計した証拠でauthorizationできます. D: connection IDはroutingとcontinuityを支え, linkability低減にも使われますが, application re-authenticationではありません. 判定基準: RFC 9000 Sections 8.2と9が確立するのはpathとconnectionの性質です. IP-based authorizationを要求せず, 採用すべきapplication identity modelも決定しません.