ToppyMicroServices

RFC 8441 Quiz

HTTP/2でのWebSocket bootstrapping

🇺🇸 🇯🇵
0 / 0

一次資料

connection単位のnegotiation、request construction、WebSocket handshake mapping、stream lifecycle、intermediary behaviorを分けて扱います。Section番号はRFC 8441を指します。

Q1: HTTP/2でWebSocketをbootstrappingする中心的な仕組みはどれ

Multiple Choice
RFC 8441はCONNECTを拡張し, 1本のHTTP/2 stream上でWebSocketを開始します. requestは`:protocol` pseudo-headerを使い, streamで動かすapplication protocolを明示します. これはconnection全体を切り替えるHTTP/1.1 `Upgrade` exchangeとは異なります. DNS service discoveryはserviceの所在を示せても, HTTP/2 streamやWebSocket semanticsを成立させません.

Q2: HTTP/2でWebSocketを扱うことで, HTTP/1.1 upgradeと比べて避けられることとして近いのはどれ

Multiple Choice

clientは同じoriginへ3本のWebSocketと通常HTTP requestを同時に使う。評価基準はtransport connectionの再利用であり、WebSocket framingやsecurity policyの変更ではない。

RFC 8441の各WebSocketはHTTP/2 streamに対応し, 複数streamが1本のtransport connectionを共有できます. したがってWebSocketごとに専用TCP connectionが必須になるわけではありません. multiplexingはtransport security, HTTP setup semantics, 成功response後のWebSocket framingを不要にはしません. 変わるのはconnectionの共有方法であり, 他layerの保証ではありません.

Q3: WebSocket streamを正しく要求するpseudo-header setはどれか？

Multiple Choice

serverのopt-inを受信後、clientはwss://agent.example/eventsをHTTP/2上で開く。

A: Section 5はRFC 6455のGET bootstrapをCONNECTへ置き換えます。B: `:protocol`はHTTP/2ではなくtunneled application protocolを示します。C: Section 4は`:protocol`があるrequestへ`:scheme`と`:path`も要求します。D: CONNECT、registered `websocket` token、`wss`に対応する`https`、target path、authorityをすべて含みます。

Q4: HTTP/2 bootstrappingでもWebSocketのセマンティクスとして依然重要なものはどれ (複数選択)

Multi-Select

reviewerは、extended CONNECTの成功がRFC 6455とapplication-layer checkをすべて置き換えると主張する。引き続き必要な責務を選ぶ。

RFC 8441が変更するのはHTTP bootstrapであり, WebSocket application protocolそのものではありません. 成功response後はWebSocket framingとopcodeがstreamを規定し, browser Origin validation, application authentication, authorizationも別の責務として残ります. 一方, HTTP/1.1の`Connection` headerはこのHTTP/2 exchangeへ持ち込みません. 新しいbootstrapをsecurityやauthorizationの自動的な保証として扱うと, protocol layerの境界を越えてしまいます.

Q5: proxyがHTTP/2のみ対応でUpgradeをblockする. WebSocketに起きることとして近いのはどれ

Multiple Choice

deploymentはHTTP/2 hop経由でしかoriginへ到達できない。reviewerはpeerが実際にadvertiseしたbootstrapを選ぶ必要がある。

HTTP/1.1 `Upgrade`がblockされている事実だけでは, RFC 8441の利用可否は決まりません. clientはHTTP/2 peerがextended CONNECT対応をadvertiseしたかを別に確認し, 対応済みならそのbootstrapを使います. 未対応なら別のsupport済み経路を選ぶか失敗させる必要があります. 通常のGETはWebSocket framing semanticsを成立させません. またHTTP/1.1の`Connection`と`Upgrade` fieldをHTTP/2 streamへ移植することもできません.

Q6: clientはextended CONNECTを送れるようになったか？

単一選択

1本のHTTP/2 connectionでclientがserverへSETTINGS_ENABLE_CONNECT_PROTOCOL=1を送るが、serverからはそのsettingを受信していない。clientは自分のadvertiseをmutual opt-inと解釈し、extended CONNECT streamを開こうとする。

A: settingの送信はpeerへcapabilityをadvertiseしますが、sender自身へpermissionを与えません。B: Section 3はclientがvalue 1を受信した後に新しいextended-CONNECT streamを作れるとし、serverによる受信には効果がないと明記します。C: registered initial valueは0です。D: RFCはserverのopt-in後にこの利用を定義します。clientはこのconnectionでserverのsettingを待つ必要があります。

Q7: RFC 8441が支持するrelayの判断はどれか

Multiple Choice

A2A relayはclientにextended CONNECT対応をadvertiseしています. 一方, relayからoriginへの別のHTTP/2 connectionでは対応がadvertiseされていません. relayはclientのWebSocket requestをどう扱うか判断する必要があります.

設計レビューとして妥当なのはCです. `SETTINGS_ENABLE_CONNECT_PROTOCOL`は, 特定のHTTP/2 connection上でpeerが示すopt-inです. RFC 8441 Section 3により, relayはupstream peerから対応のadvertiseを受けるまで, そのupstream connectionで`:protocol`を送れません. Sections 4と5がextended CONNECT requestとWebSocketへのmappingを定義しており, 通常のGETと一般的な成功responseでは同じsemanticsになりません. originが実際に対応する別のupstream方式をrelayが使うことはできますが, client側のsettingは別hopを許可も記述もしません. Section 7もintermediaryの利用を扱いますが, 1本のconnectionのsettingを経路全体のcapabilityにはしていません.

Q8: 要求したWebSocket URIに対して、このtarget schemeは正しいか？

単一選択

clientはws://agent.example/eventsをbootstrapするが、既存HTTP/2 connectionがTLSを使うためextended CONNECTへ:scheme=httpsを送る。

A: Section 5はimplementation preferenceだけでなくWebSocket URIからtarget schemeを導きます。B: `ws`は`http`、`wss`は`https`へmapします。C: Section 4は`:protocol`がある場合に`:scheme`を要求します。D: このmappingで使うHTTP target-scheme valueは`ws`ではありません。HTTP/2 connection自体のsecurity requirementは別に適用されます。

Q9: RFC 8441に従うhandshake修正はどれか？

単一選択

HTTP/1.1 adapterがConnection、Upgrade、Sec-WebSocket-Key、Origin、Sec-WebSocket-Version、Sec-WebSocket-Protocolをextended CONNECT requestへ複製する。

A: RFC 8441はopening handshakeの特定fieldを変更します。B: ConnectionとUpgradeはこのHTTP/2 requestへ含めてはならず、Originと複数のSec-WebSocket fieldは引き続き使います。C: Section 5はKey/Accept processingが`:protocol`で置き換えられたとします。D: RFC 8441が引き継ぐfieldを保持し、HTTP/1.1専用のswitchとnonce exchangeを除きます。HTTP/2 field nameはwire上lowercaseです。

Q10: orderly WebSocket shutdown後、HTTP/2 streamをどう閉じるか？

単一選択

peerはWebSocket closing exchangeを完了した。implementationはexceptionではなくorderly TCP-level closeに相当するHTTP/2処理を行う。

A: Section 5はorderly TCP-level closureをHTTP/2 `END_STREAM`へmapします。B: `RST_STREAM`と`CANCEL`はreset exceptionを表します。C: connection-wide GOAWAYは1本のstreamより広いscopeです。D: HTTP/2はHTTP/1.1の101 bootstrapを使わず、protocol open後のstream-close mechanismでもありません。

Q11: clientはこのHTTP forward proxyへ最初に何を送るべきか？

単一選択

clientはHTTP/2でforward proxyへ接続し、そのproxy経由でoriginへWebSocket connectionを作りたい。originへのtunnelはまだない。

A: Section 7はforward proxyをWebSocket serviceへ置き換えません。B: HTTP/1.1 connection fieldはHTTP/2 hopへ送れません。C: RFC 8441はHTTP forward proxyを通るtunnelへ`:protocol`なしのtraditional CONNECTを使い、tunnel内で成立したHTTP versionに応じてWebSocketをbootstrapするとします。D: intermediary useもnegotiation ruleを免除しません。

Q12: 非対応peerはどのfailureを生成するか？

単一選択

SETTINGS_ENABLE_CONNECT_PROTOCOL=1を受信する前に、clientが:protocol=websocket付きCONNECTを送る。peerはRFC 8441非対応である。

A: unknown pseudo-headerを無視するとCONNECT semanticsを黙って変えます。B: Section 3はopt-in前の使用を非対応peerがmalformed requestとして検出し、stream errorを生成すると説明します。C: 引用箇所のfailure scopeはstreamであり、無条件のconnection-wide failureではありません。D: 自動downgradeやtranslation ruleは定義されていません。