Introduction aux WebSockets et socket.io

Bonjour !
Je démarre ici un blog sur le développement, j'espère que les quelques articles et tutoriaux que j'y proposerai vous serons utiles !
J'aborderai divers sujets, du backend (NodeJS, Java EE...) mais aussi du front (CSS, SASS, Angular...) et peut-être quelques articles un peu plus portés "essais" si l'inspiration me vient.

Je commence donc ici avec un article sur le protocole WebSocket et la bibliothèque socket.io.

De quoi ça parle ?

Je vais commencer par expliquer ce qu'est le protocole WebSocket avant de présenter socket.io. Dans un deuxième article nous verrons comment construire de façon simple une application basée sur socket.io.

Dis tonton, c'est quoi WebSocket ?

Et bien avant tout, regardons ce que Wikipédia en dit :

Le protocole WebSocket vise à développer un canal de communication full-duplex sur un socket TCP pour les navigateurs et les serveurs web.

Outch. Dur.
Voyons ça plus simplement.
En une phrase simple : les WebSockets permettent de créer des applications temps-réel sur le web.

Le web classique

Classiquement, un client envoie une requête à un serveur qui lui répond en lui envoyant les données demandées (ou une erreur). Ce fonctionnement a évolué avec l'apparition d'Ajax, qui a permis de rendre ce processus de communication asynchrone (le client envoie une requête au serveur, qui répond en renvoyant uniquement les données nécessaires et sans avoir besoin de recharger sa page).
On voit bien qu'avec ce fonctionnement le serveur a besoin de recevoir une requête du client afin de lui envoyer des données.
Ça limite pas mal les choses si l'on souhaite faire des applications en temps réel ! Imaginez cela pour une application de chat : afin de savoir si de nouveaux messages sont arrivés, le client est obligé d'envoyer une requête de façon périodique au serveur pour savoir si de nouveaux messages sont arrivés. Ou alors il faut que le client actualise la page ou clique sur un bouton pour récupérer les éventuels nouveaux messages.

Client-Serveur classique

Ce n'est pas du vrai push. Ce n'est pas du vrai temps réel. Pas génial du tout donc.

WebSocket

C'est là qu'arrive le protocole WebSocket. Ce protocole autorise une communication bidirectionnelle entre le client et le serveur. En clair, le serveur peut envoyer directement des données au client sans que celui-ci n'ait effectuer de requête (et vice-versa, ça marche toujours dans l'autre sens). Les limites d'Ajax ne sont donc plus d'actualité.
Plutot cool, non ? Oui, plutôt cool.

Comment ça marche ?

Je ne vais pas rentrer dans les détails techniques, mais en bref, le client envoie un "Handshake" au serveur pour notifier son désir d'ouvrir une connection WebSocket avec lui. Ce "Handshake" est en fait une requête HTTP de type UPGRADE. Si le serveur l'accepte une connection est alors ouverte entre eux. Cette connection est persistante et basée sur le protocole TCP. Elle autorise la transmission de messages bi-directionnels (client vers serveur et vice-versa) et reste ouverte jusqu'à ce qu'un des protagoniste décide de la clore. En schéma ça donne ça (source de l'image).

WebSockets representation

Ca marche partout ?

Non, malheureusement pas encore. Ce protocole est supporté par les navigateurs suivants :

  • Chrome 16+
  • Firefox 11+
  • Internet Explorer 10+
  • Opera 12.10+
  • Safari 6+

Socket.io

Socket.io est une librairie Javascript qui permet d'effectuer non seulement des communications asynchrones bidirectionnelles entre client et serveur (comme prévu par le protocol WebSocket) mais également bien plus !

Socket.io n'est pas une librairie uniquement basée sur WebSocket, ce qui a des avantages et des inconvénients.
Pour être clair : si votre navigateur supporte WebSocket, socket.io utilisera WebSocket pour communiquer. Sinon, il cherchera d'autres moyens de le faire (sans rentrer dans les détails : Flash, Ajax Long Polling...). Cela permet d'augmenter considérablement les navigateurs compatibles avec socket.io.
Mais comme je le disais juste avant, socket.io ajoute également plsueurs fonctionnalités non prévues par le protocole (broadcast de message par exemple — on verra ce que c'est dans le prochain article), ce qui a comme inconvénient de perdre la conformité avec le protocole de base et donc l'interopérabilité avec les autres librairies qui peuvent exister. Ainsi, si on développe une application avec socket.io le client et le serveur doivent utiliser socket.io. Côté client, la librairie consiste à un simple fichier Javascript à inclure, côté serveur c'est une librairie pour Node.js.

What's next ?

Après cette petite introduction, dans le prochain article on va mettre les mains dans le cambouis et développer une jolie petite application qui utilise socket.io :)

EDIT : la suite est là !


javascript | nodejs | websocket | socket.io


Strasbourg, France

Ingénieur en informatique chez Sully Group.