我将提供一个反对使用socket.io的参数。

我认为是使用socket。仅仅因为IO有后援就不是个好主意。让IE8 RIP。

在过去有很多情况下，新版本的NodeJS破坏了socket.io。你可以在这些列表中找到例子。https://github.com/socketio/socket.io/issues?q=install+error

如果你要开发一个Android应用或者其他需要与现有应用配合的东西，你可能会马上使用WS, socket。IO可能会给你带来一些麻烦…

另外，Node.JS的WS模块使用起来非常简单。

使用套接字。IO基本上就像使用jQuery -你想要支持旧的浏览器，你需要写更少的代码，库将提供回退。套接字。IO使用websockets技术，如果可用，则检查可用的最佳通信类型并使用它。

误解

关于WebSocket和Socket有一些常见的误解。IO:

The first misconception is that using Socket.IO is significantly easier than using WebSocket which doesn't seem to be the case. See examples below. The second misconception is that WebSocket is not widely supported in the browsers. See below for more info. The third misconception is that Socket.IO downgrades the connection as a fallback on older browsers. It actually assumes that the browser is old and starts an AJAX connection to the server, that gets later upgraded on browsers supporting WebSocket, after some traffic is exchanged. See below for details.

我的实验

我写了一个npm模块来演示WebSocket和Socket的区别。IO:

https://www.npmjs.com/package/websocket-vs-socket.io https://github.com/rsp/node-websocket-vs-socket.io

这是一个服务器端和客户端代码的简单示例——客户端使用WebSocket或Socket连接到服务器。IO和服务器以1秒为间隔发送三条消息，这些消息由客户端添加到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

套接字。IO服务器

套接字。使用Express.js的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

套接字。输入输出端

套接字。IO客户端示例使用香草JavaScript:

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

网络流量

要查看网络流量的差异，您可以运行我的测试。以下是我得到的结果:

WebSocket结果

2个请求，1.50 KB, 0.05 s

从这两个请求中:

HTML页面本身 连接升级到WebSocket

(连接升级请求在开发人员工具上可见，并带有101交换协议响应。)

套接字。输入输出结果

6个请求，181.56 KB, 0.25 s

从这6个要求中:

HTML页面本身 套接字。IO的JavaScript(180千字节) 第一个长轮询AJAX请求 第二个长轮询AJAX请求 第三个长轮询AJAX请求 连接升级到WebSocket

截图

我在localhost上得到的WebSocket结果:

套接字。我在localhost上得到的IO结果:

测试自己

快速启动:

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

在浏览器中打开http://localhost:3001/，用Shift+Ctrl+I打开开发人员工具，打开Network选项卡，用Ctrl+R重新加载页面，查看WebSocket版本的网络流量。

在浏览器中打开http://localhost:3002/，用Shift+Ctrl+I打开开发人员工具，打开Network选项卡，用Ctrl+R重新加载页面，查看Socket的网络流量。IO版本。

卸载:

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

浏览器兼容性

截至2016年6月，WebSocket可以在除Opera Mini以外的所有设备上运行，包括高于9的IE。

这是截至2016年6月，WebSocket在Can I Use上的浏览器兼容性:

查看http://caniuse.com/websockets获取最新信息。

tl; diana;

比较它们就像比较餐馆的食物(有时可能很贵，可能不是100%你想要)和自制的食物，在那里你必须自己收集和种植每一种食材。

也许如果你只想吃苹果，后者更好。但如果你想要一些复杂的东西，而你又孤身一人，那真的不值得你自己烹饪和制作所有的食材。

---

这两种我都用过。以下是我的经验。

套接字IO

Has autoconnect Has namespaces Has rooms Has subscriptions service Has a pre-designed protocol of communication (talking about the protocol to subscribe, unsubscribe or send a message to a specific room, you must all design them yourself in websockets) Has good logging support Has integration with services such as redis Has fallback in case WS is not supported (well, it's more and more rare circumstance though) It's a library. Which means, it's actually helping your cause in every way. Websockets is a protocol, not a library, which SocketIO uses anyway. The whole architecture is supported and designed by someone who is not you, thus you dont have to spend time designing and implementing anything from the above, but you can go straight to coding business rules. Has a community because it's a library (you can't have a community for HTTP or Websockets :P They're just standards/protocols)

尚

You have the absolute control, depending on who you are, this can be very good or very bad It's as light as it gets (remember, its a protocol, not a library) You design your own architecture & protocol Has no autoconnect, you implement it yourself if yo want it Has no subscription service, you design it Has no logging, you implement it Has no fallback support Has no rooms, or namespaces. If you want such concepts, you implement them yourself Has no support for anything, you will be the one who implements everything You first have to focus on the technical parts and designing everything that comes and goes from and to your Websockets You have to debug your designs first, and this is going to take you a long time

显然，你可以看到我偏向于SocketIO。我很想这么说，但我真的真的不想。

我真的在努力不使用SocketIO。我不想用它。我喜欢自己设计东西，自己解决问题。

But if you want to have a business and not just a 1000 lines project, and you're going to choose Websockets, you're going to have to implement every single thing yourself. You have to debug everything. You have to make your own subscription service. Your own protocol. Your own everything. And you have to make sure everything is quite sophisticated. And you'll make A LOT of mistakes along the way. You'll spend tons of time designing and debugging everything. I did and still do. I'm using websockets and the reason I'm here is because they're unbearable for a one guy trying to deal with solving business rules for his startup and instead dealing with Websocket designing jargon.

如果你是一个人的团队或者一个小团队想要实现复杂的功能，那么为一个大的应用程序选择Websockets并不是一个简单的选择。我用Websockets写的代码比以前用SocketIO写的要多，而且比用SocketIO简单十倍。

我要说的是…如果您想要一个成品和设计，请选择SocketIO。(除非你想要一些功能非常简单的东西)

我将提供一个反对使用socket.io的参数。

我认为是使用socket。仅仅因为IO有后援就不是个好主意。让IE8 RIP。

在过去有很多情况下，新版本的NodeJS破坏了socket.io。你可以在这些列表中找到例子。https://github.com/socketio/socket.io/issues?q=install+error

如果你要开发一个Android应用或者其他需要与现有应用配合的东西，你可能会马上使用WS, socket。IO可能会给你带来一些麻烦…

另外，Node.JS的WS模块使用起来非常简单。

它的优点是简化了您在#2中所描述的WebSockets的使用，更重要的是，当浏览器或服务器不支持WebSockets时，它提供了对其他协议的故障转移。我会避免直接使用WebSockets，除非你非常熟悉它们不能工作的环境，并且你有能力绕过这些限制。

这是一个关于WebSockets和Socket.IO的很好的阅读。

http://davidwalsh.name/websocket