Programmation · Web · Réseau

C’est quoi un WebSocket ?

L’essentiel du web fonctionne par requête et réponse : le navigateur demande, le serveur répond, la connexion se ferme. C’est parfait pour charger une page, mais cela ne tient plus dès qu’on veut des mises à jour en direct — un message de chat, un cours de bourse, un coup en multijoueur — que le serveur doit pousser au moment précis où elles surviennent. Un WebSocket est la réponse standard. Ce guide explique ce qu’est un WebSocket, en quoi il diffère du HTTP ordinaire, et quand vous en avez réellement besoin.

L’idée centrale : une connexion, les deux sens

Un WebSocket est une connexion persistante, bidirectionnelle (full-duplex) entre un client — généralement un navigateur — et un serveur. Une fois ouverte, chaque côté peut envoyer un message à tout moment, sans que l’autre ait à le demander d’abord. C’est la différence essentielle avec une API HTTP classique : HTTP, c’est une requête, une réponse, puis fini ; un WebSocket reste ouvert et transporte des messages dans les deux sens aussi longtemps que vous en avez besoin.

Parce que la connexion est déjà ouverte, les messages arrivent avec très peu de surcharge et presque aucun délai. Pas d’en-têtes répétés, pas de nouveau handshake par message — juste une petite frame de données dans chaque sens. C’est ce qui rend les WebSockets adaptés à tout ce qui doit paraître instantané.

Comment démarre un WebSocket : le handshake HTTP

Un WebSocket n’apparaît pas de nulle part — il commence comme une requête HTTP ordinaire. Le navigateur envoie une requête normale avec un en-tête Upgrade: websocket, demandant en substance au serveur de changer de protocole. Si le serveur accepte, il répond avec le statut 101 Switching Protocols, et à partir de là la même connexion TCP cesse de parler HTTP et se met à parler le protocole WebSocket. C’est pourquoi les WebSockets passent par les mêmes ports que le web (80 et 443) et traversent la plupart des pare-feu qui autorisent déjà le trafic web.

Après le handshake, les données circulent sous forme de frames légères. Chaque message peut être du texte — très souvent du JSON — ou du binaire, et il n’y a pas de forme requête/réponse figée : les messages circulent simplement dès qu’il y a quelque chose à envoyer.

ws vs wss

Les URL WebSocket utilisent leur propre schéma. ws:// est une connexion non chiffrée, et wss:// est la version chiffrée, sécurisée par TLS exactement comme l’est https://. En pratique, vous devriez toujours utiliser wss:// en production — c’est chiffré, et c’est bien moins susceptible d’être bloqué par les proxies et les réseaux d’entreprise qui se méfient du trafic ws:// en clair.

Quand utiliser un WebSocket (et quand non)

Les WebSockets brillent dès que le serveur doit pousser des données vers le client au moment où elles surviennent :

• Chat et messagerie — les messages apparaissent à l’instant où ils sont envoyés.
• Tableaux de bord et cours en direct — tickers boursiers, métriques, scores sportifs.
• Collaboration — documents et tableaux blancs partagés où les modifications se synchronisent en direct.
• Jeux multijoueurs — mises à jour d’état à faible latence dans les deux sens.
• Notifications — tout ce que l’utilisateur doit voir sans rafraîchir.

Ce n’est pas le bon outil pour tout. Si le client se contente toujours de demander et le serveur de répondre — charger une page, soumettre un formulaire, récupérer un enregistrement — une simple API HTTP est plus simple, cachable et plus facile à mettre à l’échelle. Optez pour un WebSocket quand c’est le serveur qui doit lancer la conversation.

WebSockets vs polling vs SSE

Avant les WebSockets, l’astuce habituelle pour des données « en direct » était le polling : le client demande au serveur « du nouveau ? » toutes les quelques secondes. Ça marche, mais c’est du gaspillage — la plupart des requêtes reviennent vides, et les mises à jour traînent toujours d’un intervalle de polling. Un WebSocket remplace tout cela par une seule connexion ouverte et zéro requête gaspillée.

Il existe aussi les Server-Sent Events (SSE), qui vous donnent un flux à sens unique du serveur vers le client en HTTP simple. SSE est plus simple quand vous n’avez besoin que de pousser depuis le serveur (un fil d’actualité, une barre de progression). Choisissez un WebSocket quand vous avez besoin que les messages circulent dans les deux sens, et SSE quand un seul sens suffit.

Une note sur l’infrastructure

Parce qu’un WebSocket maintient une connexion ouverte, il change votre façon de déployer. Les connexions de longue durée ont besoin d’un serveur et d’un reverse proxy configurés pour les maintenir en vie plutôt que de les couper par timeout, et faire monter en charge de nombreuses connexions simultanées est un problème de conception à part entière. C’est le compromis : un WebSocket vous offre une communication instantanée et bidirectionnelle, en échange du maintien d’un état ouvert sur le serveur.

En résumé

Un WebSocket est une connexion unique, persistante et bidirectionnelle qui permet au serveur et au navigateur d’échanger des messages au moment où ils surviennent — sans le rythme demander-et-attendre du HTTP. Il commence sa vie comme une requête HTTP qui est upgradée, puis transporte des frames légères dans les deux sens. Utilisez wss://, optez pour lui quand le serveur doit pousser des données en direct, et restez sur une API HTTP classique quand une simple requête et réponse suffit.