WebSocket

Qu'est-ce qu'un WebSocket ?

WebSocket est un protocole de communication qui ouvre un canal persistant et bidirectionnel entre un client, généralement un navigateur web, et un serveur. Une fois la connexion établie, chacun peut envoyer des données à tout moment sans attendre que l'autre les demande. C'est ce qui rend possibles sur le web le chat en direct, les jeux multijoueurs, l'édition collaborative, les tableaux de bord de trading et les notifications instantanées.

Il est normalisé par l'IETF (RFC 6455) et pris en charge par tous les navigateurs modernes via une API JavaScript simple. Une URL WebSocket commence par ws://, ou wss:// quand la connexion est chiffrée en TLS, forme à utiliser systématiquement en production.

Comment fonctionne une connexion WebSocket

Un WebSocket démarre comme une requête HTTP classique. Le client demande au serveur de faire évoluer la connexion, le serveur accepte, et dès lors la même connexion TCP cesse de parler HTTP et transporte à la place de légers messages WebSocket. Les étapes sont :

• La poignée de main (handshake) : le client envoie une requête HTTP avec l'en-tête Upgrade: websocket.
• La montée de protocole : le serveur répond avec le statut 101 (Switching Protocols) et la connexion reste ouverte.
• Les échanges : les deux côtés échangent des trames texte ou binaires dans les deux sens, avec très peu de surcharge par message.
• La fermeture : l'un des deux envoie une trame de fermeture et la connexion se termine proprement.

Un client minimal ressemble à ceci :

const socket = new WebSocket('wss://example.com/live');
socket.addEventListener('open', () => socket.send('hello'));
socket.addEventListener('message', (event) => console.log(event.data));

WebSocket face à HTTP et aux autres techniques

HTTP classique fonctionne en requête et réponse : le client demande, le serveur répond, et l'échange se termine. Pour simuler le temps réel, les développeurs ont longtemps utilisé le polling, où le navigateur demande sans cesse s'il y a du nouveau. Cela gaspille des requêtes et ajoute du délai. D'autres options existent, et le bon choix dépend du sens et de la fréquence des données.

• Le polling et le long polling : simples à mettre en place, mais lourds pour le serveur et pas vraiment instantanés.
• Les Server-Sent Events (SSE) : un flux unidirectionnel du serveur vers le navigateur via HTTP. Idéal pour les notifications et les flux en direct où le client a peu à renvoyer.
• WebSocket : bidirectionnel simultané, faible latence, adapté quand les deux côtés échangent souvent, comme dans un chat ou un outil collaboratif.
• Les webhooks : des rappels de serveur à serveur déclenchés par un événement. Ce n'est pas une connexion en direct avec un navigateur, ils résolvent donc un autre problème.

Cas d'usage typiques

• Le chat en direct et les widgets de support client.
• Les outils collaboratifs où plusieurs personnes modifient le même document.
• Les tableaux de bord en direct, les cours de bourse et les écrans de supervision.
• Les jeux multijoueurs et les tableaux blancs partagés.
• Les notifications en temps réel et les indicateurs de présence.

Si les données changent rarement, ou si l'utilisateur n'a besoin d'un contenu à jour qu'au chargement de la page, une API REST classique est plus simple et moins coûteuse à exploiter. WebSocket mérite sa place quand la latence et l'échange dans les deux sens comptent.

Défis et bonnes pratiques

Une connexion persistante impose des contraintes que les requêtes sans état ne connaissent pas.

• Le passage à l'échelle : chaque connexion ouverte consomme de la mémoire serveur. Répartir les clients sur plusieurs serveurs demande un répartiteur de charge avec sessions persistantes ou un courtier de messages partagé.
• La sécurité : utilisez toujours wss://, authentifiez pendant la poignée de main, validez chaque message reçu et vérifiez l'origine pour éviter le détournement inter-sites.
• Le contrôle des abus : appliquez une limitation de débit par connexion pour qu'un client ne puisse pas saturer le serveur.
• La fiabilité : les connexions tombent sur les réseaux mobiles. Prévoyez une reconnexion automatique avec délai croissant et des messages de pulsation pour détecter les liens morts.
• Les solutions de repli : des bibliothèques comme Socket.IO ajoutent reconnexion et solutions de repli, et des services gérés comme Supabase Realtime ou Firebase prennent en charge une grande partie de l'infrastructure.

WebSocket chez BeBranded

Chez BeBranded, nous utilisons WebSocket, ou une couche temps réel gérée, uniquement quand une application web a vraiment besoin de données en direct et bidirectionnelles, comme des interfaces collaboratives ou des tableaux de bord en direct. Pour le reste, nous préférons des approches plus simples, moins coûteuses à exploiter et plus faciles à maintenir. Nous concevons ensemble le back-end et le front-end pour que les fonctions temps réel restent fiables et sûres. Cela fait partie de notre service d'applications web.