WebSocket : qu'est-ce que c'est, protocole de communication full-duplex et fonctionnement

Qu'est-ce que WebSocket ?

WebSocket est un protocole de communication qui fonctionne sur TCP et fournit un canal full-duplex entre un client et un serveur. Il a été normalisé par l'IETF sous le nom RFC 6455 en 2011 et est pris en charge par tous les navigateurs modernes, plateformes mobiles et frameworks serveur.

Contrairement à HTTP, où le client initie une requête et reçoit une réponse, WebSocket permet aux deux parties d'envoyer des messages à tout moment après l'établissement de la connexion. Cela le rend idéal pour les scénarios nécessitant une livraison instantanée des données : chats, notifications, édition collaborative de documents.

Le protocole WebSocket utilise le port HTTP 80 ou le port HTTPS 443 pour le handshake initial, après quoi il bascule vers son propre protocole avec un en-tête minimal — seulement 2 octets au lieu de 800+ octets dans HTTP. Cette caractéristique offre un avantage de performance significatif avec un grand nombre de messages.

Caractéristiques clés du protocole

Une connexion WebSocket commence par une requête HTTP de mise à niveau (Upgrade), après quoi le protocole passe à un format de trame binaire. La taille de la trame varie de 2 octets à 2^63 octets, permettant la transmission de messages texte courts et de grandes données binaires. Le protocole prend en charge la fragmentation des messages, le masquage des données du client vers le serveur et le ping/pong pour maintenir la connexion active.

Comment fonctionne WebSocket ?

Le processus d'établissement d'une connexion WebSocket comporte deux étapes : le handshake et le transfert de données. Pendant le handshake, le client envoie une requête HTTP avec l'en-tête Upgrade: websocket, et le serveur confirme le changement de protocole avec le statut 101 Switching Protocols. Après cela, la connexion entre en mode de transmission full-duplex.

Chaque message dans WebSocket est divisé en trames. Une trame contient un opcode (texte, données binaires, fermeture, ping/pong), la longueur de la charge utile et une clé de masquage pour les données du client. Les trames peuvent être fragmentées — les trames de contrôle (ping/pong) peuvent être transmises entre les fragments de message, évitant ainsi le timeout de connexion lors de transferts longs.

const ws = new WebSocket('wss://example.com/chat')

ws.addEventListener('open', () => {
    console.log('Connexion établie')
    ws.send('Bonjour, serveur !')
})

ws.addEventListener('message', (event) => {
    console.log('Reçu :', event.data)
})

ws.addEventListener('close', () => {
    console.log('Connexion fermée')
})

Dans l'exemple ci-dessus, le client crée un objet WebSocket en spécifiant l'URL sécurisée wss://. Après l'ouverture de la connexion, un message de bienvenue est envoyé, et le gestionnaire de messages reçoit les réponses du serveur. À la fermeture, le gestionnaire de fermeture se déclenche — ceci est important pour la reconnexion en cas d'interruptions réseau.

WebSocket vs HTTP : comparaison

La principale différence entre WebSocket et HTTP réside dans le modèle d'interaction. HTTP fonctionne selon un schéma de requête-réponse : le client initie une requête, le serveur renvoie une réponse et la connexion est fermée. WebSocket, quant à lui, établit un canal persistant par lequel les deux parties peuvent initier une transmission à tout moment.

Pour les applications nécessitant une faible latence et un flux constant de données, WebSocket est nettement plus efficace. Le HTTP Long Polling — une alternative où le serveur maintient la requête ouverte jusqu'à ce que les données soient disponibles — crée une charge excessive sur le serveur et augmente la consommation mémoire en raison de multiples connexions simultanées.

Selon High Performance Browser Networking (Grigorik, O'Reilly), WebSocket réduit la latence réseau dans les scénarios en temps réel de 40 à 60% par rapport au HTTP Long Polling, tandis que la charge du serveur est réduite de 3 à 5 fois grâce à l'élimination des handshakes répétés.

Où WebSocket est-il utilisé ?

Grâce à sa faible latence et à sa communication bidirectionnelle, WebSocket est utilisé dans un large éventail d'applications. Les principaux scénarios incluent la messagerie instantanée, la synchronisation d'état dans les jeux et la transmission de données de marché dans les systèmes financiers.

Chats et messageries

WebSocket est devenu le standard de facto pour les applications de chat. Des plateformes comme Slack, Telegram Web et WhatsApp Web utilisent WebSocket pour la livraison instantanée des messages. Le protocole permet d'envoyer à la fois des messages texte et des fichiers via un seul canal, tandis que le mécanisme ping/pong maintient la connexion active même pendant les périodes d'inactivité.

Jeux en ligne

Les jeux multijoueurs sur navigateur et mobiles nécessitent une latence minimale pour synchroniser les états des joueurs. WebSocket transmet les coordonnées, actions et événements en temps réel sans les délais des requêtes HTTP. Des frameworks comme Socket.IO et Colyseus abstraient les opérations de bas niveau du protocole, ajoutant la reconnexion automatique et les salles.

Applications financières

Les terminaux de trading et les plateformes de négociation utilisent WebSocket pour recevoir des cotations en temps réel. Un retard de quelques millisecondes peut coûter des millions de dollars, c'est pourquoi les API financières — comme Binance WebSocket Streams, Coinbase Pro — fournissent des interfaces WebSocket pour les données de marché.

Applications mobiles et IoT

Dans le développement mobile, WebSocket est utilisé via des API natives : URLSessionWebSocketTask sur iOS et OkHttp WebSocket sur Android. Pour Flutter, il existe la bibliothèque web_socket_channel, et pour React Native — react-native-websocket. Les appareils IoT utilisent WebSocket pour transmettre la télémétrie et recevoir des commandes de contrôle, car le protocole consomme moins d'énergie que le HTTP polling constant.

Exemples de code WebSocket

Examinons un exemple côté serveur utilisant Node.js avec la bibliothèque ws — l'implémentation WebSocket la plus populaire pour JavaScript. Le serveur accepte les connexions, traite les messages et les diffuse à tous les clients connectés.

const WebSocket = require('ws')
const wss = new WebSocket.Server({ port: 8080 })

wss.on('connection', (ws) => {
    console.log('Nouveau client connecté')

    ws.on('message', (data) => {
        console.log('Reçu :', data.toString())
        ws.send('Le serveur a reçu votre message')
    })

    ws.on('close', () => {
        console.log('Client déconnecté')
    })
})

console.log('Serveur WebSocket démarré sur le port 8080')

Le serveur crée une instance de WebSocket.Server sur le port 8080 et attend les connexions. Chaque nouveau client reçoit un objet ws séparé via lequel le serveur peut envoyer des messages individuels. La diffusion des messages à tous les clients est implémentée en itérant sur le tableau des connexions. Avec un grand nombre de clients (plus de 1000), il est recommandé d'utiliser des bibliothèques prenant en charge le clustering, comme Socket.IO, qui ajoutent une mise à l'échelle basée sur Redis et une reconnexion automatique.

Envoyer des messages à tous les clients

wss.clients.forEach((client) => {
    if (client.readyState === WebSocket.OPEN) {
        client.send('Message pour tous les participants')
    }
})

Vérifier le readyState avant d'envoyer est obligatoire : si le client s'est déjà déconnecté, l'appel de send générera une erreur. Le flag WebSocket.OPEN garantit que la connexion est active et que le message sera livré.

Pour les applications mobiles iOS, WebSocket est implémenté via URLSessionWebSocketTask, disponible depuis iOS 13. La session crée une tâche avec une URL de protocole wss://, après quoi les méthodes send et receive sont appelées. La réception des messages peut être organisée par récursion continue de receive, qui attend le message suivant après avoir traité le précédent, assurant une réception constante des données sans reconnexion. Pour Android, OkHttp WebSocket est utilisé, fournissant une interface similaire avec des callbacks onOpen, onMessage, onClosing et onClosed, ainsi qu'une reconnexion automatique en cas de perte de connexion.

Lorsque vous travaillez avec WebSocket dans des applications mobiles, il est important de prendre en compte la gestion du cycle de vie : lorsque l'application passe en arrière-plan, le système peut fermer la connexion. Sur iOS, la connexion doit être rétablie lors du retour au premier plan via le délégué sceneDidBecomeActive. Sur Android, des composants Lifecycle-aware ou un Service doivent être utilisés pour maintenir la connexion. De plus, il est recommandé d'implémenter un backoff exponentiel pour la reconnexion — augmenter l'intervalle entre les tentatives de 1 à 30 secondes — pour éviter de créer une charge excessive sur le serveur lors de problèmes réseau temporaires.