Aller au contenu principal

1. Introduction

Le protocole WebSocket (WebSocket Protocol) permet une communication bidirectionnelle simultanée (Full-Duplex Communication) entre un client et un serveur sur une seule connexion TCP. Le protocole se compose d'une poignée de main d'ouverture (Opening Handshake) suivie d'un tramage de messages de base (Message Framing), superposé sur TCP.

L'objectif de cette spécification est de fournir un mécanisme pour les applications basées sur navigateur qui nécessitent une communication bidirectionnelle avec les serveurs sans s'appuyer sur l'ouverture de plusieurs connexions HTTP (par exemple, en utilisant XMLHttpRequest ou des <iframe> et l'interrogation longue (Long Polling)).

1.1 Background (Contexte)​

Historiquement, la création d'applications web nécessitant une communication bidirectionnelle entre un client et un serveur (par exemple, les applications de messagerie instantanée et de jeux) a nécessité un abus d'HTTP pour interroger le serveur pour les mises à jour tout en envoyant des notifications en amont sous forme d'appels HTTP distincts.

Cela entraîne divers problèmes :

  • Le serveur est obligé d'utiliser un certain nombre de connexions TCP sous-jacentes différentes pour chaque client : une pour envoyer des informations au client et une nouvelle pour chaque message entrant
  • Le protocole filaire (Wire Protocol) a une surcharge élevée, chaque message client-serveur ayant un en-tête HTTP
  • Le script côté client est obligé de maintenir une correspondance entre les connexions sortantes et la connexion entrante pour suivre les réponses

Une solution plus simple serait d'utiliser une seule connexion TCP pour le trafic dans les deux directions. C'est ce que fournit le protocole WebSocket. Combiné avec l'API WebSocket, il offre une alternative à l'interrogation HTTP pour la communication bidirectionnelle d'une page web vers un serveur distant.

1.2 Protocol Overview (Vue d'ensemble du protocole)​

Le protocole comporte deux parties : une poignée de main (Handshake) et le transfert de données (Data Transfer).

La poignée de main du client ressemble à ceci :

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

La poignée de main du serveur ressemble à ceci :

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Points clés de la poignée de main :

  • La requête du client est une requête HTTP Upgrade valide
  • Plusieurs en-têtes spécifiques à WebSocket sont ajoutés
  • Le serveur répond avec le code d'état 101

Une fois la connexion établie, le client et le serveur peuvent envoyer des données dans les deux sens à tout moment.

1.3 Design Philosophy (Philosophie de conception)​

Le protocole WebSocket est conçu selon les principes suivants :

  1. Protocole basé sur les trames plutôt que sur les flux : Un protocole basé sur les trames (Frame-based Protocol) permet d'associer des métadonnées à chaque trame et permet au protocole de préserver les limites de message (Message Boundaries) jusqu'à la couche application
  2. Modèle d'origine : Utilise le modèle d'origine du navigateur (Origin Model) pour garantir la sécurité
  3. Connexion TCP unique : Pour fonctionner sur les ports HTTP 80 et 443
  4. Indépendant de HTTP : Bien que la poignée de main soit interprétée par les serveurs HTTP comme une requête d'upgrade, le protocole lui-même est indépendant
  5. Extensibilité : Supporte les extensions futures via des mécanismes d'extension et de sous-protocole

1.4 Security Model (Modèle de sécurité)​

Le protocole WebSocket utilise le modèle d'origine (Origin Model) couramment utilisé par les navigateurs web. Le protocole inclut un champ d'en-tête d'origine (Origin Header Field) que le serveur peut utiliser pour décider s'il accepte une connexion WebSocket d'une origine donnée.

De plus :

  • Les connexions chiffrées TLS (wss://) sont recommandées
  • Les trames du client vers le serveur doivent être masquées (Masking)
  • Le protocole inclut des types de trames, des opcodes (Opcode), etc., pour empêcher l'empoisonnement du cache (Cache Poisoning)

Liens de référence​

Dernière mise à jour le