Le protocole WebSocket permet d'ouvrir un canal de communication bidirectionnel (ou "full-duplex") sur un socket TCP pour les navigateurs et les serveurs web. Plus spécifiquement, il permet donc :
la notification au client d'un changement d'état du serveur,
l'envoi de données en mode « pousser » (méthode Push) du serveur vers le client, sans que ce dernier ait à effectuer une requête.
Le besoin d'une communication web bidirectionnelle, client / serveur
L'interactivité croissante des applications web, consécutive à l'amélioration des performances des navigateurs, a rapidement rendu nécessaire le développement de techniques de communications bidirectionnelles entre l'application web client et les processus serveur. Des techniques basées sur l'appel de requête par le client via l'objet XMLHttpRequest et utilisant des requêtes HTTP avec un type long TTL stockées par le serveur pour une réponse ultérieure au client ont permis de pallier ce manque et ont été popularisées par le succès des architectures Ajax.
Selon l'informaticien Stéphane Bortzmeyer, « WebSocket offre donc pratiquement le même service aux applications que TCP », mais présente l'intérêt de contourner les nombreux obstacles intermédiaires aux flux réseau (pare-feux etc.) dans la « jungle » qu'est devenue le Web contemporain[4]. En utilisant l'architecture d'HTTP (relais, authentification, ports 80 et 443), très peu filtrante, pour créer un nouveau protocole de transport, les créateurs de Websocket visent à assurer une communication réseau bidirectionnelle qui n'était plus garantie à travers TCP. La principale limite de Websocket est qu'il ne s'agit pas d'un protocole généraliste : la communication doit forcément se faire via le navigateur web du client, ou à travers certaines bibliothèques dédiées (voir section « Implémentations »).
L'API WebSocket
L'interface de programmation WebSocket a été élaborée au sein du WHATWG[5].
Polémiques
Architecture réseau
Le principe même de WebSocket a été contesté au sein des organismes de spécification lors de son élaboration, au nom du fait qu'il valait sans doute mieux résoudre les problèmes de filtrage constatés dans la couche réseau plutôt que de créer un nouveau protocole au-dessus de la couche application
Sécurité
Une faille de sécurité a été découverte au sein de l'API des premières versions de websocket. La sécurité était compromise lors de la navigation en remplaçant pendant la phase de « handshake » un fichier JavaScript par un malware. Cette faille se situant au niveau de l'API elle-même [6], elle ne pouvait pas être corrigée par un quelconque correctif au sein du navigateur. Dans certaines versions des navigateurs comme Firefox 4 et 5, Opera 11 et Internet Explorer 9, WebSocket a été désactivé à cause de cette faille.
La faille de sécurité dans Firefox a été corrigée à partir de Firefox 6 (moteur Gecko 6.0) [7].
Internet Explorer a implémenté le websocket avec IE10 [8].
Sur Opéra, il était toujours possible de réactiver le websocket. À partir d'Opéra 12, le websocket est activé [9].
ScaleDrone, implémentation javascript du protocole pour REST, Node.js, PHP, Ruby ;
Socket.io, implémentation javascript du protocole pour Node.js ;
Autres
APE Project, support du protocole WebSocket (-hixie-75, -hixie-76, -hybi-ietf-06, -hybi-ietf-07)[16] ;
PubNub, implémentation proposant une API, compatible avec tous les langages utilisés par les technologies mobiles, du web, et IoT, service gratuit ou payant ;
Pusher, implémentation sous forme d'API compatible avec la plupart des langages ;