Socket.io: socket.ioがwebsocket接続とxhrポーリングを並列に使用するのはなぜですか？

• 「XHRポーリング」は接続ではなく、複数の接続を使用する可能性があります。
• WebSocketとポーリングトランスポートはまだ同時に初期化されていません。 実際、それがengine.ioが行うことであり、socket.ioが実装されるとすぐに行われます。 詳細はこちらをご覧

socket.io 0.9に2つのオープントランスポートが同時に存在する状況に遭遇した場合、それはバグであり、それを再現する方法についての詳細をいただければ幸いです。

「XHRポーリング」は接続ではなく、複数の接続を使用する可能性があります。

はい。ただし、ポーリングはすべてのリクエストで同じURLで機能するためです。 私はそれが1つをエミュレートする必要があると思います。

socket.io 0.9に2つのオープントランスポートが同時に存在する状況に遭遇した場合、それはバグであり、それを再現する方法についての詳細をいただければ幸いです。

同じ意味かどうかはわかりませんが、Chromiumは開いているWebSocket接続を表示し、さらに、socket.ioにポーリング要求を送信しています。
「ばかげている」とは、使用可能なWebSocket接続とポーリングの利点を理解できないことを意味します。
WebSocket接続自体で十分であり、xhrポーリングはフォールバックとしてのみ使用されるべきではありませんか？

私が何かを逃した場合は私を修正してください

@bodokaiserは、

ハンドシェイクは通常のHTTPであることに注意してください

Chromeは、WebSocket接続が保留中であることを示しています。 エラーメッセージはありません。 wsが機能すると思います。 それでも、socket.ioがフォールバックしているかどうかを確認するにはどうすればよいですか？

うん、それは間違いなく握手ではない。 Chromeとノードコンソールで、2000ミリ秒ごとにgetリクエストがどのように繰り返されているかを確認します。

node.jsのログは役に立ちますか？

よろしく

ws接続で交換されたフレームを調べます（Chromeだけがこれを持っていると思います）。 データが表示されない場合は、機能しませんでした。

うん、後退しているようだ：

  debug - client authorized
   info  - handshake authorized yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/?t=1344799805756 200 3ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866
   debug - setting poll timeout
   debug - client authorized for 
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866 200 1ms
   debug - xhr-polling received data packet 5:::{"name":"hello","args":["world"]}
POST /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815871 200 1ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815872
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client T9eCOR7gCe3pLNtiEZco
   debug - xhr-polling closed due to exceeded duration
GET /socket.io/1/xhr-polling/T9eCOR7gCe3pLNtiEZco?t=1344799800945 200 20002ms
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - xhr-polling closed due to exceeded duration

@guilleなぜフォールバックしているのか教えて

どのブラウザを使用していますか？

MacOSX用のChroms21

Chrome 21 / Windows 21.0.1180.79 mでも同じ問題が発生しています-接続されない同時WebSocket接続を使用したJSONPポーリング接続（成功しているようです）があります-常に「保留中」の状態です。 Mac上の同じバージョンのChromeは問題ないようです。

これはファイアウォールやウイルス対策に関連しているようには見えません。すべてのテストはwebsocketstest.orgとwebsocket.org/echo.htmlに合格しています。

私はsocket.io0.9を使用していますが、最新バージョンにも存在しているようです。

@guilleこの問題も非常に簡単に再現できるようです。 socket.ioのWebSocketトランスポートを使用するサイトにアクセスしました。

http://beta.blaggart.com

少なくともWindows上のChrome21では、WS接続のステータスは常に「保留中」であることに注意してください。

socket.ioマスターで試してみませんか？

マスターを試したところ、同じ問題が発生しました。 この問題も＃998の重複である可能性があると考えてください。

また、その価値については、＃998で説明されている回避策が、接続を確立するために機能しました。つまり、WebSocketを無効にし、xhrとjsonpのポーリングのみを使用します。

これは実際にはクロムのバグですか？

www.websocket.org/echo.htmlでテストを行うとき

面白いことに、同じWebサイトで「SecureWebSocket（TLS）」を使用すると、WebSocketが機能します。

ChromeとFirefoxの両方でまったく同じ動作..非常に奇妙な..

サーバ：

socket.on('loginout',function(){
    socket.emit('loginout',{uname:socket.name});
});

socket.on（ 'login'、function（data）{
socket.emit（ 'l_msg'、{uname：data.uname、score：data.score、type：true}）;
}）;

印刷：
情報：ハンドシェイク承認済み11012331592122282453
デバッグ：リクエストの設定GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
デバッグ：ポーリングタイムアウトの設定
デバッグ：クライアントが承認されました
デバッグ：ポーリングタイムアウトのクリア
デバッグ：xhr-ポーリング書き込み1 ：：
デバッグ：クライアント11012331592122282453のクローズタイムアウトを設定します
デバッグ：xhr-受信データパケットのポーリング 20 5::: {"name"： "count"} 22 5::: {"name"： "history"} 23 5::: {"name "：" userList "}
デバッグ：リクエストの設定GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
デバッグ：ポーリングタイムアウトの設定
デバッグ：トランスポートを破棄する
デバッグ：クライアント11012331592122282453のクローズタイムアウトをクリアしました
デバッグ：ポーリングタイムアウトのクリア
デバッグ：xhr-ポーリング書き込み8 ：：
デバッグ：クライアントのクローズタイムアウトを設定します1896586469607627233
デバッグ：期間を超えたため、xhr-pollingが閉じられました
デバッグ：xhr-受信データパケットのポーリング5 ::: {"name"： "login"、 "args"：[{"uname"： "gjjn"、 "pwd"： "3f01728152a0225ff9806c401ffdbe77"}]}
デバッグ：ポーリングタイムアウトのクリア
debug：xhr-pollingwriting 5 ::: {"name"： "l_msg"、 "args"：[{"uname"： "gjjn"、 "type"：true、 "head"： " http：//42.121。 14.234 / undefined "}]}
デバッグ：クライアント11012331592122282453のクローズタイムアウトを設定します
デバッグ：xhr-受信したデータパケットのポーリング5 ::: {"name"： "loginout"}
デバッグ：websocket書き込み5 ::: {"name"： "l_msg"、 "args"：[{"uname"： "gregergre"、 "type"：true、 "head"： " http://42.121.14.234/未定義の"}]}
デバッグ：クライアント5207531891749391108のハートビートを発行します
デバッグ：websocket書き込み2 ：：
デバッグ：クライアント5207531891749391108のハートビートタイムアウトを設定します
デバッグ：ハートビートパケットを取得しました
デバッグ：クライアント5207531891749391108のハートビートタイムアウトをクリアしました
デバッグ：クライアント5207531891749391108のハートビート間隔を設定します
デバッグ：websocket書き込み5 ::: {"name"： "loginout"、 "args"：[{}]}

xhr-pollingはデータパケット5 ::: {"name"： "loginout"}を受信しました。
しかし、結果ではありません。

こっちも一緒。 同じコードを使用しましたが、Chrome MacOSでは機能しますが、ChromeWindowsでは機能しません

複製する方法-https：//gist.github.com/jonnsl/5021596

+1、この問題を修正してください。 @ LearnBoost

私はこれを見ていますが、私の側では、Websocket接続とSOCKET.ioサーバーに送信された繰り返しのXHRリクエストとして表示されます

WebSocket接続が成功したようですが、XHRリクエストが表示されます

Request URL:ws://localhost:5000/socket.io/?EIO=2&transport=websocket&sid=XcMblHoZ0x97QRn_AAAE
Request Method:GET
Status Code:101 Switching Protocols
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:io=XcMblHoZ0x97QRn_AAAE
Host:localhost:5000
Origin:http://localhost:3000
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:EZixwYoUHpFFpgrEOqiS+w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
EIO:2
transport:websocket
sid:XcMblHoZ0x97QRn_AAAE
Response Headers
Connection:Upgrade
Sec-WebSocket-Accept:WHsiBZoW9stmULt+YX8wmNK1wx8=
Upgrade:websocket

WebSocketフレームは次のようになります
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

そして、長いポーリング要求

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Google Chrome35.0.1916.153で実行しています

ソケット発行バージョンは[email protected]

同じ問題があります。 更新はありますか？ SocketIO1.0.6の使用

最初のリクエストは常にXHRであり、次にWebSocketに_アップグレード_します（可能な場合）。 後続のポーリングは中止されます（場合によっては追加のポーリングサイクルが発生する可能性がありますが、1を超えることはありません）

@guille私がチェックしたものについては、Websocket接続が正常に確立された場合でもXHRポーリングが繰り返されるのがわかります

こんにちは、

この問題を解決するための解決策は何ですか？

@rohittailor ：私はこれをクライアントでテストしています：

    <script src="/socket.io/socket.io.js"></script>
    <script>
        var socket = io.connect({transports: ['websocket']});
    </script>

そしてこれまでのところとても良い。 XHR接続を完全に回避しています。

これで私の問題も解決しました。websocketは正常に機能していましたが、ダーティなXHRポーリングもありました。 ありがとう@gonzalodiaz

WSに正常にアップグレードされるシナリオを本当に見たいのですが、XHRポーリングサイクルはWebInspectorで無期限に続行されます。

（デモ、ビデオ、アニメーションGIF、何でも機能します）

明日、MSAzureクラウドでホストされる私のWebサイトへのデモアクセスを提供できます。 テストURLとsocket.ioのホスト方法の詳細を教えてください。

@guilleこれはどうですか

WebSocketフレームは次のようになります
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

そして、長いポーリング要求

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

それらは無期限に進み続けますか？ に重複するフレームがありますか
反応？ 対応するサーバーログをDEBUG = *と
この状況が発生したときにlocalStorage.debug='*'ブラウザログ？

—
ギレルモ・ローチ– https://twitter.com/rauchg

22:59で火、2014年10月14日には、Virenネギ[email protected]
書きました：

@guillehttps ：//github.com/guilleこれはどうですか

WebSocketフレームは次のようになります

https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

そして、長いポーリング要求

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
。

@guille xhr応答が無期限に繰り返されるのを確認します。重複するフレームについてはよくわかりません。必要なものをすべて提供できるかどうか、確認させてください。

私がどれほど役立つかはわかりませんが、安全な場合にのみWebソケットに接続できることに気づいています。 安全でないWebSocket接続を許可するためにヘッダー（CORSのような）を必要とする最近のセキュリティ変更がいくつかありますか？

WebSocketは1か月前に機能していましたが、現在はwss：//接続でのみ機能します。
Chrome 38.0.2125.104-Windows 8.1.1

編集：これらの結果は、実際にはhttp://www.websocket.org/echo.htmlの問題である可能性があり
私は他の場所でテストすることができませんでした

WS接続の成功は、実際にはネットワーク/サーバーの機能に依存します。 SSLは、データが復号化される前に何も破壊できないことを保証します（ただし、後続のプロキシ/ロードバランサーはそれを破壊できます）。

それが実際にはコードのバグであることに気づきました。WS接続をポーリングすることすらなかったので、変更を加えてから機能しました。 私が覚えているなら、私は今夜修正されたソースを見るでしょう。

しかし、それが他のすべての人のために機能している場合、それは私の設定に問題がある可能性がありますが、&&を||に変更せずにWSが利用できないと考えたため、接続しようとしませんでした修正しました。

もっと聞きたい！

それでも（小さな）問題ですが、クライアントは別のトランスポートを試す代わりに、常にポーリング要求を行います。 指定する必要があります

{transports: ['websocket']}

それを機能させるには、クライアントはすべてのトランスポートを試して、適切なトランスポートを見つける必要がありますよね？

この問題が、2012/13年に独自の「純粋な」Webソケットパッケージの開発を始めた理由です。

この問題は解決されましたか？ 私は似たようなものを見ていますが、深く掘り下げる前に、簡単な検索をしたかったのです...コメント？

この問題について最後にコメントしてから、コードがかなり変更されました。 同じバグである可能性は低いです。 前回問題を引き起こしたと思われる行が見つからないようです。 それが修正されたと言っているわけではありません。

私のsocket.ioコードは現在バグengine.io-clientによってブロックされているため、s.ioを数か月使用していないため、これがまだ問題であるかどうかはわかりません。

@wssが機能していることについてコメントを投稿することはありませんが、私の場合、wssは完全に正しくありませんでした。 それを指摘してくれてありがとう私は一週間以上この問題を探していました。 どういうわけか私のネットワーク上のws接続がブロックされていましたが、wssは正常に機能していました。

このWebサイトは素晴らしいです： http ：

ソケットioに問題がありますが、どこが間違っているのかわかりません。

上の画像はローカルで正常に動作することを示していますが、下の画像はAWS環境で試行中にキャプチャされたものです。

ソケットioに問題がありますが、どこが間違っているのかわかりません。

上の画像はローカルで正常に動作することを示していますが、下の画像はAWS環境で試行中にキャプチャされたものです。

同じ問題に直面している