2

WebSocketプロトコル00（ハンドシェイクヘッダーにkey1、key2があるサーバー）で正常に動作するWebSocketサーバーをC++で作成しました。

今、新しいアップデートで、私は新しい方法のハンドシェイク作業のために同じことをしようとしています。ハンドシェイク要求に対するサーバーの応答は次のとおりです。

"HTTP /1.1101スイッチングプロトコル\r\ nアップグレード：websocket \ r \ n接続：アップグレード\ r \ nSec-WebSocket-承認：" + serverKey + "\ r \ n \ r \ n";

serverkeyが正しく計算されます。例として：

ハンドシェイクリクエスト：
GET / test HTTP / 1.1
アップグレード：websocket
接続：アップグレード
ホスト：192.168.123.102
Sec-WebSocket-Origin： http
：//192.168.123.5 Sec-WebSocket-Key：YB0mPvJ5t8ggCeGUWY39uQ ==
Sec-WebSocket-Version： 8

ハンドシェイク応答ヘッダー：
HTTP / 1.1 101スイッチングプロトコル
アップグレード：websocket
接続：アップグレード
Sec-WebSocket-Accept：xt9iyCNryQTseELUkHPWjzxA2ts =

また、 https： //datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-08の例を使用してアルゴリズムを確認すると、まったく同じ応答が生成されました。

ただし、それでも次のエラーが発生します：
「WebSocketハンドシェイク中のエラー：Sec-WebSocket-不一致を受け入れる」

ブラウザとしてChrome15を使用しています。

何がうまくいかないか考えていますか？

（Chrome Inspector Networkでも、ハンドシェイクを受け入れない場合のような応答は表示されません（古いバージョンでも））

4

2 に答える 2

2

私は実際に何が主な問題であるかを知りました。

base64エンコーディングに使用したキーは

YB0mPvJ5t8ggCeGUWY39uQ==
258EAFA5-E914-47DA-95CA-C5AB0DC85B11

それ以外の

YB0mPvJ5t8ggCeGUWY39uQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11

余分な\nが全体の問題でした。

ただし、Connectedメッセージを受信したため（wsクライアントはws severに正常に接続されています）、何も送受信できません。問題はサーバー側です。

古いWebSocketプロトコル以降のサーバー側の変更点を知っていますか？ハンドシェイクの応答を変更するだけで、十分ではないようです。

于 2011-12-06T18:15:03.020 に答える
2

クライアントがデータを送信するときのフレーミングプロトコルは異なります。以前は非常に単純でした。今でははるかに複雑です。websocketsrfc6455の仕様を参照してください。

https://www.rfc-editor.org/rfc/rfc6455#section-5.2

于 2012-01-16T07:20:24.860 に答える