60

RFC6455の「258EAFA5-E914-47DA- 95CA -C5AB0DC85B11」の意味がわかりません。サーバーがこのマジックストリングを必要とするのはなぜですか？そして、なぜWebSocketプロトコルにこのメカニズムが必要なのですか？

4

3 に答える 3

31

RFC で説明されています。これは、「WebSocket プロトコルを理解しないネットワーク エンドポイントで使用される可能性が低い」という理由で選択された GUID です。RFC 6455を参照してください。

そのような GUID の形式の詳細に興味がある場合は、RFC 4122を参照してください。

于 2012-11-19T14:40:27.767 に答える
3

WebSocket プロトコルがこのメカニズムを必要とするのはなぜですか?

  1. Websocket 接続は、単純に以下のコードを使用して、ブラウザーによって要求されます。

new WebSocket("wss://echo.websocket.org")

デバッガーからは が表示101 GETされ、リクエスト ヘッダーを調べると、次の特定のエントリが表示されます。

Sec-WebSocket-Key: qcq+klmT4W41IrmG3/fseA==

これは、ブラウザを識別する一意のハッシュです。

ここに画像の説明を入力

  1. サーバー側では、$client_keyハッシュが受信されます。ハッシュ値のみが保持されます。戻り値は、PHP を使用すると次のようになります。

"Sec-WebSocket-Accept: " . base64_encode(sha1( $client_key . "258EAFA5-E914-47DA-95CA-C5AB0DC85B11",true))

  1. ブラウザーは応答を返します (例)。258EAFA5-E914-47DA-95CA-C5AB0DC85B11これは、 websocketの一意のGUIDと連結された、送信されたキーの sha1 です。

    Sec-WebSocket-Accept: r1Km05q03xuNRYy7mxkCRRgbh2M=

ここに画像の説明を入力

ブラウザは、ハッシュが内部で行われた独自の計算と一致するかどうかを確認しています。その場合、ハンドシェイクは完了し、リモート サーバーは実際には実際の WebSocket サーバーであるため、トンネルが作成され、維持されます。

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

于 2020-06-22T17:57:26.660 に答える