610

node.jsのsocket.ioとwebsocketsの違いは何ですか?
どちらもサーバープッシュテクノロジーですか? 私が感じた唯一の違いは、

  1. socket.io を使用すると、イベント名を指定してメッセージを送信/送信できました。

  2. socket.io の場合、サーバーからのメッセージはすべてのクライアントに到達しますが、websocket の場合も同様に、すべての接続の配列を保持し、それをループしてすべてのクライアントにメッセージを送信する必要がありました。

また、なぜ Web インスペクター (Chrome/firebug/fiddler など) がサーバーから (socket.io/websocket から) これらのメッセージをキャッチできないのでしょうか?

これを明確にしてください。

4

9 に答える 9

721

誤解

WebSocket と Socket.IO に関してよくある誤解がいくつかあります。

  1. 最初の誤解は、WebSocket を使用するよりも Socket.IO を使用する方がはるかに簡単であるということですが、そうではないようです。以下の例を参照してください。

  2. 2 つ目の誤解は、WebSocket がブラウザで広くサポートされていないということです。詳細については、以下を参照してください。

  3. 3 つ目の誤解は、Socket.IO が古いブラウザーのフォールバックとして接続をダウングレードするというものです。実際には、ブラウザーが古いものであると想定し、サーバーへの AJAX 接続を開始します。トラフィックが交換された後、WebSocket をサポートするブラウザーで後でアップグレードされます。詳細については、以下を参照してください。

私の実験

WebSocket と Socket.IO の違いを示すために npm モジュールを作成しました。

これはサーバー側とクライアント側のコードの簡単な例です。クライアントは WebSocket または Socket.IO を使用してサーバーに接続し、サーバーは 1 秒間隔で 3 つのメッセージを送信し、クライアントによって DOM に追加されます。

サーバ側

WebSocket と Socket.IO を使用して Express.js アプリで同じことを行うサーバー側の例を比較します。

WebSocket サーバー

Express.js を使用した WebSocket サーバーの例:

var path = require('path');
var app = require('express')();
var ws = require('express-ws')(app);
app.get('/', (req, res) => {
  console.error('express connection');
  res.sendFile(path.join(__dirname, 'ws.html'));
});
app.ws('/', (s, req) => {
  console.error('websocket connection');
  for (var t = 0; t < 3; t++)
    setTimeout(() => s.send('message from server', ()=>{}), 1000*t);
});
app.listen(3001, () => console.error('listening on http://localhost:3001/'));
console.error('websocket example');

ソース: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/ws.js

Socket.IO サーバー

Express.js を使用した Socket.IO サーバーの例:

var path = require('path');
var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);
app.get('/', (req, res) => {
  console.error('express connection');
  res.sendFile(path.join(__dirname, 'si.html'));
});
io.on('connection', s => {
  console.error('socket.io connection');
  for (var t = 0; t < 3; t++)
    setTimeout(() => s.emit('message', 'message from server'), 1000*t);
});
http.listen(3002, () => console.error('listening on http://localhost:3002/'));
console.error('socket.io example');

ソース: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/si.js

クライアント側

WebSocket と Socket.IO を使用してブラウザーで同じことを行うクライアント側の例を比較します。

WebSocket クライアント

バニラ JavaScript を使用した WebSocket クライアントの例:

var l = document.getElementById('l');
var log = function (m) {
    var i = document.createElement('li');
    i.innerText = new Date().toISOString()+' '+m;
    l.appendChild(i);
}
log('opening websocket connection');
var s = new WebSocket('ws://'+window.location.host+'/');
s.addEventListener('error', function (m) { log("error"); });
s.addEventListener('open', function (m) { log("websocket connection open"); });
s.addEventListener('message', function (m) { log(m.data); });

ソース: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/ws.html

Socket.IO クライアント

バニラ JavaScript を使用した Socket.IO クライアントの例:

var l = document.getElementById('l');
var log = function (m) {
    var i = document.createElement('li');
    i.innerText = new Date().toISOString()+' '+m;
    l.appendChild(i);
}
log('opening socket.io connection');
var s = io();
s.on('connect_error', function (m) { log("error"); });
s.on('connect', function (m) { log("socket.io connection open"); });
s.on('message', function (m) { log(m); });

ソース: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/si.html

ネットワーク トラフィック

ネットワーク トラフィックの違いを確認するには、my test を実行します。私が得た結果は次のとおりです。

WebSocket の結果

2 リクエスト、1.50 KB、0.05 秒

これらの 2 つの要求から:

  1. HTML ページ自体
  2. WebSocket への接続のアップグレード

(接続アップグレード要求は、101 Switching Protocols 応答で開発者ツールに表示されます。)

Socket.IO の結果

6 リクエスト、181.56 KB、0.25 秒

これらの 6 つの要求から:

  1. HTML ページ自体
  2. Socket.IO の JavaScript (180キロバイト)
  3. 最初のロング ポーリング AJAX リクエスト
  4. 2 番目の長いポーリング AJAX 要求
  5. 3 番目のロング ポーリング AJAX リクエスト
  6. WebSocket への接続のアップグレード

スクリーンショット

localhost で取得した WebSocket の結果:

WebSocket の結果 - websocket-vs-socket.io モジュール

ローカルホストで取得した Socket.IO の結果:

Socket.IO の結果 - websocket-vs-socket.io モジュール

自分を試す

クイックスタート:

# Install:
npm i -g websocket-vs-socket.io
# Run the server:
websocket-vs-socket.io

ブラウザーでhttp://localhost:3001/を開き、Shift+Ctrl+I で開発者ツールを開き、[ネットワーク] タブを開き、Ctrl+R でページをリロードして、WebSocket バージョンのネットワーク トラフィックを確認します。

ブラウザーでhttp://localhost:3002/を開き、Shift+Ctrl+I で開発者ツールを開き、[ネットワーク] タブを開き、Ctrl+R でページをリロードして、Socket.IO バージョンのネットワーク トラフィックを確認します。

アンインストールするには:

# Uninstall:
npm rm -g websocket-vs-socket.io

ブラウザの互換性

2016 年 6 月の時点で、WebSocket は Opera Mini 以外のすべてで動作し、IE 9 以降も含まれます。

これは、 2016 年 6 月現在のCan I Useでの WebSocket のブラウザー互換性です。

ここに画像の説明を入力

最新情報については、 http://caniuse.com/websocketsを参照してください。

于 2016-07-25T01:28:02.877 に答える
384

その利点は、#2 で説明したように WebSocket の使用が簡素化されることです。おそらくもっと重要なのは、WebSocket がブラウザーまたはサーバーでサポートされていない場合に、他のプロトコルへのフェールオーバーを提供することです。WebSocket が機能しない環境に精通しており、それらの制限を回避できる場合を除き、WebSocket を直接使用することは避けます。

これは、WebSockets と Socket.IO の両方について読むのに適しています。

http://davidwalsh.name/websocket

于 2012-04-11T19:24:41.000 に答える
57

tl;dr;

それらを比較することは、レストランの食べ物(時には高価で、100%あなたがそれを望んでいないかもしれません)と自家製の食べ物を比較するようなものです。

りんごを食べたいだけなら、後者の方がいいかもしれません。しかし、何か複雑なものが必要で、一人でいる場合は、すべての材料を自分で調理して作る価値はありません.


私はこれらの両方で働いてきました。これが私の経験です。

SocketIO

  • 自動接続あり

  • 名前空間があります

  • 部屋あり

  • サブスクリプションサービスあり

  • 事前に設計された通信プロトコルを持っています

    (サブスクライブ、サブスクライブ解除、または特定の部屋にメッセージを送信するためのプロトコルについて言えば、すべて Websocket で自分で設計する必要があります)

  • 優れたロギング サポートがある

  • redis などのサービスと統合されている

  • WS がサポートされていない場合のフォールバックがあります (まあ、ますますまれな状況ですが)

  • 図書館です。つまり、実際にはあらゆる面であなたの大義を助けているということです。Websockets はプロトコルであり、ライブラリではなく、とにかく SocketIO が使用します。

  • アーキテクチャ全体は、あなた以外の誰かによってサポートおよび設計されているため、上記の設計と実装に時間を費やす必要はありませんが、ビジネス ルールのコーディングに直接進むことができます。

  • ライブラリなのでコミュニティがあります(HTTP または Websockets のコミュニティを持つことはできません:P それらは単なる標準/プロトコルです)

ウェブソケット

  • あなたは完全なコントロールを持っています。あなたが誰であるかに応じて、これは非常に良い場合もあれば非常に悪い場合もあります
  • それは可能な限り軽量です(覚えておいてください、これはプロトコルであり、ライブラリではありません)
  • 独自のアーキテクチャとプロトコルを設計します
  • 自動接続はありません。必要に応じて自分で実装します
  • サブスクリプションサービスはありません。あなたがデザインします
  • ロギングはありません。実装します
  • フォールバック サポートなし
  • ルームや名前空間はありません。そのような概念が必要な場合は、自分で実装します
  • 何もサポートしていません。すべてを実装するのはあなたです
  • まず、技術的な部分に集中し、Websocket とやり取りするすべてのものを設計する必要があります。
  • 最初にデザインをデバッグする必要があり、これには長い時間がかかります

明らかに、私が SocketIO に偏っていることがわかります。私はそう言いたいのですが、私は本当にそうではありません。

私は本当にSocketIO を使用しないように戦っています。使いたくありません。私は自分のものをデザインし、自分の問題を自分で解決するのが好きです。

しかし、 1000 行のプロジェクトだけでなく、ビジネスを持ちたい場合、Websocketsを選択する場合は、すべてを自分で実装する必要があります。すべてをデバッグする必要があります。独自のサブスクリプション サービスを作成する必要があります。独自のプロトコル。あなた自身のすべて。そして、すべてが非常に洗練されていることを確認する必要があります。そして、途中でたくさんの間違いを犯します。すべての設計とデバッグに膨大な時間を費やすことになります。私はそうしましたし、今もそうしています。私は Websocket を使用していますが、私がここにいる理由は、自分のスタートアップのビジネス ルールの解決に取り組み、代わりに Websocket 設計の専門用語に対処しようとしている 1 人の男にとって、Websocket が耐えられないからです。

複雑な機能を実装しようとしている 1 人の軍隊または小さなチームの場合、大規模なアプリケーションに Websocket を選択するのは簡単なオプションではありません。過去に SocketIO で書いたよりも多くのコードを Websockets で書きました。これは、SocketIO で行ったよりも 10 倍単純なものです。

私が言わなければならないのは...完成品とデザインが必要な場合は、SocketIOを選択してください。(機能が非常に単純なものが必要な場合を除く)

于 2020-07-11T10:38:53.173 に答える
43

私はsocket.ioの使用に反対する議論を提供するつもりです.

フォールバックがあるという理由だけで socket.io を使用するのは良い考えではないと思います。IE8をリッピングさせてください。

これまで、NodeJS の新しいバージョンで socket.io が壊れているケースが数多くありました。これらのリストの例を確認できます... https://github.com/socketio/socket.io/issues?q=install+error

Android アプリなど、既存のアプリと連携する必要があるものを開発する場合は、すぐに WS を使用しても問題ないでしょうが、socket.io で問題が発生する可能性があります...

さらに、Node.JS の WS モジュールは驚くほど簡単に使用できます。

于 2015-12-19T19:33:31.967 に答える
32

Socket.IO の使用は、基本的に jQuery の使用に似ています。古いブラウザーをサポートしたい場合、記述するコードを減らす必要があり、ライブラリーがフォールバックを提供します。Socket.io は、利用可能な場合は websockets テクノロジを使用し、利用できない場合は、利用可能な最適な通信タイプをチェックして使用します。

于 2016-12-21T06:32:46.240 に答える