Socket.io-client: トランスポートのデフォルトはWebSocketではなくポーリングですか？

作成日 2015年09月11日 · 9コメント · ソース: socketio/socket.io-client

socket.io.jsの1613行目は次のようになっています。
this.transports = opts.transports || ['polling'、 'websocket'];

順序['websocket'、 'polling']がないのはなぜですか？

クライアント側では、次のことを行っています。
var socket = io.connect（url）;

次に、サーバー側で、次のことを行いました。
io.on（ 'connection'、function（socket）{
console.log（ソケット）;
}）;

ハンドシェイク部分は次のようになります。

handshake: 
   { headers: 
      { 'user-agent': 'node-XMLHttpRequest',
        accept: '*/*',
        host: 'localhost:8081',
        connection: 'close' },
     time: 'Fri Sep 11 2015 16:04:39 GMT-0400 (EDT)',
     address: '::ffff:127.0.0.1',
     xdomain: false,
     secure: false,
     issued: 1442001879771,
     url: '/socket.io/?EIO=3&transport=polling&t=1442001879749-0&b64=1',
     query: { EIO: '3', transport: 'polling', t: '1442001879749-0', b64: '1' } }

これは、WebSocketの代わりにポーリングを使用していることを意味しますか？

トランスポートを「websocket」に明示的に設定しようとしましたが、ハンドシェイクの部分が次のように変更されました。これは正しいようです。
var socket = io.connect（url、{transports：['websocket']}）;

handshake: 
   { headers: 
      { connection: 'Upgrade',
        upgrade: 'websocket',
        host: 'localhost:8081',
        origin: 'localhost:8081',
        'sec-websocket-version': '13',
        'sec-websocket-key': 'MTMtMTQ0MjAwMTUxNDcyNA==' },
     time: 'Fri Sep 11 2015 15:58:34 GMT-0400 (EDT)',
     address: '::ffff:127.0.0.1',
     xdomain: true,
     secure: false,
     issued: 1442001514739,
     url: '/socket.io/?EIO=3&transport=websocket',
     query: { EIO: '3', transport: 'websocket' } }

ソース

napalm272

👍4

最も参考になるコメント

+1
私は「アップグレード」ではなく「ダウングレード」のアイデアを好みます。現在、ほとんどのブラウザーはWebSocketを適切にサポートしています。最初にWebSocketに接続すると、パフォーマンスが向上し、リソースが節約されます。

stackOverMind 2015年10月20日

👍14

全てのコメント9件

stackOverMind 2015年10月20日

👍14

upgradeの理由は次のとおりです。

Socket.IOは、実際には機能しない可能性が高いため、WebSocketが機能するとは決して想定していません。代わりに、XHRまたはJSONPとの接続をすぐに確立してから、接続をWebSocketにアップグレードしようとします。タイムアウトに依存するフォールバック方法と比較すると、これは、どのユーザーもエクスペリエンスが低下しないことを意味します。

http://socket.io/blog/introducing-socket-io-1-0/

nkzawa 2015年11月27日

👍5

@nkzawa
アップグレードアプローチが好まれる理由を理解しています。これは非常に優れた機能です。
ただし、必ずしも必要なわけではありません。制御されたエンタープライズ環境では、ダウングレードアプローチの方が理にかなっています。許可される唯一のトランスポートとして、Webソケットを強制することが、パフォーマンスを最適化する最良の方法だと思います。

このオプションを渡すことで、クライアントとサーバーの両方でWebソケットへのトランスポートを強制しようとしました。
{ transports: ["websocket"] }

これは機能しているようで、サーバーへのWebソケット接続は1つしかありませんが、ポーリングも実行されていることに気付きました。これは、すべての試行で明らかに失敗します。
Request URL:http://localhost:4000/socket.io/?EIO=3&transport=polling&t=L8RaD0p
{ code: 0, message: "Transport unknown" }

このアップグレードアプローチをダウングレードに変更するための実行可能な解決策はありますか？