Quelles sont les différences entre socket.io et websockets dans node.js?
S'agit-il de technologies de push de serveur? Les seules différences que j'ai ressenties étaient,

1. socket.io m'a permis d'envoyer / émettre des messages en spécifiant un nom d'événement.

2. Dans le cas de socket.io, un message du serveur atteindra tous les clients, mais pour les mêmes dans les websockets, j'ai été obligé de conserver un tableau de toutes les connexions et de le parcourir pour envoyer des messages à tous les clients.

De plus, je me demande pourquoi les inspecteurs Web (comme Chrome / Firebug / Fiddler) ne peuvent pas attraper ces messages (depuis socket.io/websocket) depuis le serveur?

Veuillez clarifier cela.

Ses avantages sont qu'il simplifie l'utilisation des WebSockets comme vous l'avez décrit dans # 2, et plus important encore, il fournit des basculements vers d'autres protocoles dans le cas où les WebSockets ne sont pas pris en charge sur le navigateur ou le serveur. J'éviterais d'utiliser WebSockets directement à moins que vous ne connaissiez très bien les environnements dans lesquels ils ne fonctionnent pas et que vous soyez capable de contourner ces limitations.

C'est une bonne lecture sur WebSockets et Socket.IO.

http://davidwalsh.name/websocket

Idées fausses

Il existe quelques idées fausses courantes concernant WebSocket et Socket.IO:

1. La première idée fausse est que l'utilisation de Socket.IO est beaucoup plus facile que l'utilisation de WebSocket, ce qui ne semble pas être le cas. Voir les exemples ci-dessous.

2. La deuxième idée fausse est que WebSocket n'est pas largement pris en charge dans les navigateurs. Voir ci-dessous pour plus d'informations.

3. La troisième idée fausse est que Socket.IO rétrograde la connexion en tant que solution de rechange sur les anciens navigateurs. Il suppose en fait que le navigateur est ancien et démarre une connexion AJAX au serveur, qui est ensuite mise à niveau sur les navigateurs prenant en charge WebSocket, après un échange de trafic. Voir ci-dessous pour plus de détails.

Mon expérience

J'ai écrit un module npm pour démontrer la différence entre WebSocket et Socket.IO:

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

Il s'agit d'un exemple simple de code côté serveur et côté client - le client se connecte au serveur en utilisant WebSocket ou Socket.IO et le serveur envoie trois messages à des intervalles de 1 s, qui sont ajoutés au DOM par le client.

Du côté serveur

Comparez l'exemple côté serveur de l'utilisation de WebSocket et Socket.IO pour faire de même dans une application Express.js:

Serveur WebSocket

Exemple de serveur WebSocket utilisant Express.js:

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');

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

Serveur Socket.IO

Exemple de serveur Socket.IO utilisant Express.js:

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');

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

Côté client

Comparez l'exemple côté client d'utilisation de WebSocket et Socket.IO pour faire de même dans le navigateur:

Client WebSocket

Exemple de client WebSocket utilisant JavaScript vanilla:

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); });

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

Client Socket.IO

Exemple de client Socket.IO utilisant JavaScript vanilla:

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); });

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

Trafic réseau

Pour voir la différence de trafic réseau, vous pouvez exécuter mon test . Voici les résultats que j'ai obtenus:

Résultats WebSocket

2 requêtes, 1.50 KB, 0.05 s

De ces 2 demandes:

1. Page HTML elle-même
2. mise à niveau de la connexion à WebSocket

(La demande de mise à niveau de connexion est visible sur les outils de développement avec une réponse 101 Switching Protocols.)

Résultats Socket.IO

6 requêtes, 181.56 KB, 0.25 s

De ces 6 demandes:

1. la page HTML elle-même
2. JavaScript de Socket.IO (180 kilo-octets)
3. première requête AJAX longue interrogation
4. deuxième requête AJAX longue interrogation
5. troisième requête AJAX longue interrogation
6. mise à niveau de la connexion à WebSocket

Captures d'écran

Résultats WebSocket que j'ai obtenus sur localhost:

Résultats Socket.IO que j'ai obtenus sur localhost:

Testez-vous

Démarrage rapide:

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

Ouvrez http: // localhost: 3001 / dans votre navigateur, ouvrez les outils de développement avec Shift + Ctrl + I, ouvrez l'onglet Réseau et rechargez la page avec Ctrl + R pour voir le trafic réseau pour la version WebSocket.

Ouvrez http: // localhost: 3002 / dans votre navigateur, ouvrez les outils de développement avec Shift + Ctrl + I, ouvrez l'onglet Réseau et rechargez la page avec Ctrl + R pour voir le trafic réseau pour la version Socket.IO.

Pour désinstaller:

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

Compatibilité du navigateur

Depuis juin 2016, WebSocket fonctionne sur tout sauf Opera Mini, y compris IE supérieur à 9.

Il s'agit de la compatibilité du navigateur WebSocket sur Can I Use à partir de juin 2016:

Voir http://caniuse.com/websockets pour des informations à jour.

Je vais fournir un argument contre l'utilisation de socket.io.

Je pense que l'utilisation de socket.io uniquement parce qu'il a des solutions de repli n'est pas une bonne idée. Laissez IE8 RIP.

Dans le passé, il y a eu de nombreux cas où de nouvelles versions de NodeJS ont cassé socket.io. Vous pouvez consulter ces listes pour des exemples ... https://github.com/socketio/socket.io/issues?q=install+error

Si vous allez développer une application Android ou quelque chose qui doit fonctionner avec votre application existante, vous seriez probablement d'accord avec WS tout de suite, socket.io pourrait vous poser quelques problèmes là-bas ...

De plus, le module WS pour Node.JS est incroyablement simple à utiliser.

Utiliser Socket.IO est fondamentalement comme utiliser jQuery - vous voulez prendre en charge les navigateurs plus anciens, vous devez écrire moins de code et la bibliothèque fournira des solutions de secours. Socket.io utilise la technologie websockets si elle est disponible, et sinon, vérifie le meilleur type de communication disponible et l'utilise.

Même si les navigateurs modernes prennent en charge WebSockets maintenant, je pense qu'il n'est pas nécessaire de jeter SocketIO et il a toujours sa place dans n'importe quel projet de nos jours. C'est facile à comprendre et personnellement, j'ai appris comment fonctionnent les WebSockets grâce à SocketIO.

Comme indiqué dans cette rubrique, il existe de nombreuses bibliothèques d'intégration pour Angular, React, etc. et des types de définition pour TypeScript et d'autres langages de programmation.

L'autre point que j'ajouterais aux différences entre Socket.io et WebSockets est que le clustering avec Socket.io n'est pas un gros problème. Socket.io propose des adaptateurs qui peuvent être utilisés pour le relier à Redis afin d'améliorer l'évolutivité. Vous avez par exemple ioredis et socket.io-redis .

Oui, je sais, SocketCluster existe, mais c'est hors sujet.

Socket.IO utilise WebSocket et lorsque WebSocket n'est pas disponible utilise algo de secours pour établir des connexions en temps réel.

https://socket.io/docs/#What-Socket-IO-is-not (avec mon accent )

Ce que Socket.IO n'est pas

Socket.IO n'est PAS une implémentation WebSocket. Bien que Socket.IO utilise en effet WebSocket comme transport lorsque cela est possible, il ajoute des métadonnées à chaque paquet: le type de paquet, l'espace de noms et l'ID de paquet lorsqu'un accusé de réception de message est nécessaire. C'est pourquoi un client WebSocket ne pourra pas se connecter avec succès à un serveur Socket.IO et un client Socket.IO ne pourra pas non plus se connecter à un serveur WebSocket . Veuillez consulter la spécification du protocole ici .

// WARNING: the client will NOT be able to connect!
const client = io('ws://echo.websocket.org');