ToppyMicroServices

RFC 6455 Quiz

WebSocket protocol

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 6455はopening handshake, framing, masking, control frame, connection closeを定義します. Originはbrowser-originのsignalであり, maskingは暗号化ではありません. handshake成功やsubprotocol選択もapplicationのauthenticationまたはauthorizationではありません.

Q1: clientはOPEN stateへ移ってよいか

単一選択

clientはextensionを一つもofferしていません. serverは正しいUpgrade, Connection, Sec-WebSocket-Acceptを伴う101 responseを返しましたが, Sec-WebSocket-Extensionsでextensionも選択しました.

**解説:** A: Sec-WebSocket-Acceptはclient keyから導出したhandshake responseを検証しますが, unsolicited extensionを許可しません. B: Sec-WebSocket-Extensionsはこのcontextで意味を持つ定義済みnegotiation fieldです. C: RFC 6455 Section 4.1 step 5は, clientがofferしていないextensionをresponseが選んだ場合にconnectionをfailするよう要求します. D: 無効なnegotiationのためdata-framing phaseへ移れません.

Q2: serverはOriginから何を判断できるか

単一選択

privileged endpointが`Origin: https://trusted.example`だけをclient credentialとして受理します. browser scriptとautonomous A2A clientの両方が接続できます.

**解説:** A: Section 4.1はbrowser clientにOriginを要求しますが, 適合するuse caseのnon-browser clientにも送信を許します. universal credentialではありません. B: Sections 4.2.2と10.2はOriginをscript originのacceptance判断に使います. non-browser clientは偽のOriginを送れるため, authenticationとauthorizationは別に必要です. C: non-browser clientもOriginを含められるので, 有無からclient typeやidentityを認証できません. D: TLSは設定に応じてtransportとTLS peerを認証しますが, 任意のrequest metadataをapplication identityにはしません.

Q3: serverはこのframeをどう処理しなければならないか

単一選択

有効なwss handshake後, clientがMASK=0のwell-formed text frameを送ります. implementationはTLSがconfidentialityを守るため受理しました.

**解説:** A: RFC 6455 Section 5.1はWebSocketがTLS上かどうかにかかわらずmaskingを要求します. B: requirementはpayloadのsensitivityではなくframe directionで決まります. C: client maskの欠如はprotocol errorであり, serverがmasking keyを作って修復できません. D: Section 5.1はunmasked client frameを受けたserverにcloseを要求し, status code 1002を許します. maskingはTLS encryptionの代替ではありません.

Q4: receiverはPingをどう処理すべきか

単一選択

大きなtext messageをfragmentで受信中です. continuation frameの間に有効なPing frameが届きました. receiverはtext messageが完成するまでPingをbufferします.

**解説:** A: Sections 5.4と5.5はfragmented messageの途中にcontrol frameを許し, endpointに処理能力を要求します. Pingには通常Section 5.5.2に従ってPongを返します. B: continuationとPingはopcodeが異なり, Pingはdata messageを終了しません. C: 別data messageのinterleaveは通常できませんが, control frameは明示的な例外です. D: control payloadはfragmented application messageのpayloadではありません.

Q5: intermediaryはmessageをre-fragmentしてよいか

単一選択

proxyはhandshakeを観測しましたが, negotiated WebSocket extensionを実装していません. buffer削減のため, このconnectionのdata-message fragmentをcoalesce・splitしようとしています.

**解説:** A: Section 5.4はextensionがfragmentにまたがるExtension dataへ意味を与え得ると説明します. B: 125-byte limitはcontrol frameに適用され, data messageのre-fragmentを許可も規律もしません. C: Section 5.4はextensionがnegotiatedされ, intermediaryがそのsemanticsを理解しない場合のfragmentation変更を禁止します. D: extensionがない場合, またはintermediaryがhandshakeを観測して関連extensionをすべて理解する場合にはre-fragmentが許され得ます.

Q6: 成功したhandshakeは何を証明するか

単一選択

A2A serverが有効なwss handshakeを完了し, `Sec-WebSocket-Protocol: agent-admin`を選択しました. credentialやgrantを確認せずdestructiveなadmin commandを認可します.

**解説:** A: Sec-WebSocket-Protocolはapplication protocolの利用をnegotiateします. client identity proofではありません. B: RFC 6455 Sections 4と11.3.4はconnectionとsubprotocol選択を確立します. client authenticationはhandshakeへ追加できますが, grant verificationとcommand authorizationは構成するapplication設計の責務です. C: Sec-WebSocket-Acceptは偶然のnon-WebSocket responseがclient validationを通ることを防ぎます. authorization credentialではありません. D: 通常のserver-authenticated TLSはchannelを保護しserverを識別しますが, clientのadmin entitlementは証明しません.