Comprendre le protocole WebSocket de zéro et construire un système de chat complet : connexion, utilisateurs en mémoire, messages privés et groupes — sans base de données.
HTTP est un protocole de requête-réponse : le client demande, le serveur répond, la connexion se ferme. Pour afficher un nouveau message dans un chat, il faudrait interroger le serveur toutes les secondes — c'est du polling, c'est inefficace, et ça ne passe pas à l'échelle.
WebSocket résout ce problème en maintenant une connexion ouverte entre le client et le serveur. Une fois établie, les deux parties peuvent s'envoyer des données à tout moment, sans nouvelle requête.
WebSocket ne remplace pas HTTP — il démarre dedans. La connexion s'établit via un mécanisme appelé "upgrade" : le client envoie une requête HTTP ordinaire avec un en-tête spécial qui demande à basculer sur le protocole WebSocket.
GET /chat HTTP/1.1
Host: exemple.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13Le serveur accepte et répond avec un 101 Switching Protocols :
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=À partir de là, HTTP disparaît. La même connexion TCP est réutilisée, mais elle parle désormais le protocole WebSocket. Zéro overhead de connexion supplémentaire.
La différence fondamentale avec HTTP : WebSocket est full-duplex. Client et serveur peuvent envoyer des messages simultanément, dans n'importe quel ordre, sans attendre l'autre.
Client → Serveur : "Bonjour"
Serveur → Client : "Bienvenue"
Serveur → Client : "Un autre utilisateur vient de se connecter"
Client → Serveur : "Merci"Pas de tour de parole. Pas de requête pour déclencher une réponse. La connexion est un canal bidirectionnel permanent.
Les données WebSocket transitent sous forme de frames — des unités binaires avec un en-tête compact. Chaque frame contient :
En pratique, on ne manipule jamais les frames directement. Les bibliothèques s'en occupent. Ce qui compte : WebSocket supporte les messages texte (UTF-8) et les messages binaires. Pour un chat, on utilise du texte — généralement du JSON.
Avant WebSocket, plusieurs techniques tentaient de simuler du temps réel :
Polling court — le client interroge le serveur toutes les N secondes. Simple, mais inefficace : 99% des requêtes ne retournent rien de nouveau.
Long polling — le client envoie une requête, le serveur ne répond que quand il a quelque chose à dire. Mieux, mais chaque réponse nécessite une nouvelle requête. La latence dépend du réseau.
Server-Sent Events (SSE) — le serveur pousse des données vers le client sur une connexion HTTP persistante. Unidirectionnel seulement (serveur → client). Pas de canal retour sans une requête séparée.
WebSocket — bidirectionnel, faible latence, faible overhead. Idéal pour le chat, les jeux, les tableaux de bord en temps réel, les éditeurs collaboratifs.
Un serveur Node.js avec la bibliothèque ws. Pas de framework, pas de base de données — juste le protocole à l'état pur.
Le serveur maintiendra en mémoire :
Les clients seront en HTML + JavaScript vanilla, en utilisant l'API WebSocket native du navigateur — disponible partout, sans aucune dépendance.
Le chapitre suivant installe l'environnement et crée le premier serveur WebSocket.