SSE vs WebSocket : quelle option temps réel choisir | We.Inc
Server-sent events vs WebSockets : EventSource et WebSocket côte à côte, reconnexion, données binaires, limites de connexions, une aide au choix et des serveurs Node minimaux pour les deux.
Les server-sent events diffusent du texte du serveur vers le navigateur via une réponse HTTP ordinaire, et l'API EventSource se reconnecte toute seule. Un WebSocket transforme la connexion en canal bidirectionnel qui transporte du texte ou du binaire dans les deux sens. Utilisez SSE pour les flux d'actualité, notifications et barres de progression ; utilisez les WebSockets quand le navigateur doit renvoyer des messages fréquents.
Côte à côte
Fonctionnalité
Server-sent events
WebSocket
Sens
Du serveur vers le client uniquement
Dans les deux sens simultanément
API navigateur
EventSource
WebSocket
Protocole
HTTP simple, text/event-stream
HTTP Upgrade, puis ws:// ou wss://
Données
Texte UTF-8 uniquement
Texte ou binaire
Reconnexion
Automatique, reprend avec Last-Event-ID
À écrire vous-même
Connexions ouvertes en HTTP/1
6 par navigateur et par domaine
Limites distinctes, fixées par chaque navigateur
Vous ne savez pas lequel il faut à votre fonctionnalité ? Cochez dans l'outil ci-dessous les affirmations qui s'y appliquent. Il suit les mêmes règles que le tableau ci-dessus et indique quelle API convient, et pourquoi.
Cochez chaque affirmation qui décrit votre fonctionnalité.
Lisez la recommandation et la raison donnée.
Copiez le code client et serveur correspondant dans les sections plus bas.
Remplacez l'URL et les noms d'événements par les vôtres et lancez le serveur avec Node.
Envoyez une ligne de commentaire, deux-points suivi de texte, toutes les 15 à 30 secondes sur un flux SSE pour que les proxys ne le coupent pas pour inactivité.
Donnez un id à chaque événement SSE. Quand le navigateur se reconnecte, il renvoie cette valeur dans l'en-tête Last-Event-ID, et votre serveur peut rejouer ce qui a été manqué.
Servez SSE en HTTP/2 quand c'est possible, car la limite de six connexions de HTTP/1 est partagée entre tous les onglets ouverts sur votre site.
Avec les WebSockets, surveillez bufferedAmount avant d'envoyer de grosses rafales ; l'API elle-même ne gère pas la contre-pression.
Questions fréquentes
Le navigateur peut-il envoyer des données au serveur avec SSE ?
Pas sur le flux lui-même. Le flux d'événements ne circule que du serveur vers le client : le navigateur envoie donc ses messages avec des requêtes fetch ordinaires. Pour un trafic de type messagerie dans les deux sens, un WebSocket convient mieux.
Comment empêcher EventSource de se reconnecter ?
Appelez close() côté client. Côté serveur, le standard HTML indique qu'une réponse 204 No Content demande au client d'arrêter de se reconnecter.
Peut-on envoyer un en-tête Authorization avec EventSource ?
Non. Le constructeur ne prend qu'une URL et un objet d'options dont le seul réglage est withCredentials. Utilisez un cookie, un jeton de courte durée dans l'URL, ou un lecteur basé sur fetch si vous avez besoin d'en-têtes personnalisés.
SSE est-il dépassé maintenant que les WebSockets existent ?
Non. Le format text/event-stream reste un bon choix pour les flux à sens unique, car il passe par les serveurs HTTP, proxys et systèmes d'authentification habituels sans changement de protocole.
Lequel consomme le moins de ressources serveur ?
Les deux maintiennent une connexion de longue durée par client : la différence est donc faible. Ce qui compte davantage, c'est de savoir si votre hébergeur autorise les réponses de longue durée ou les upgrades de protocole : vérifiez d'abord ses limites de durée de requête.
Comment fonctionnent les server-sent events
Le serveur répond à un GET normal avec un Content-Type text/event-stream et garde la réponse ouverte. Chaque message tient en quelques lignes comme event:, data: et id:, terminées par une ligne vide. Plusieurs lignes data: dans un même message sont jointes par des retours à la ligne.
L'EventSource du navigateur analyse ce flux, déclenche un événement message pour les messages sans nom et un événement nommé pour les autres, et se reconnecte tout seul après une coupure. Une ligne retry: fixe le délai d'attente en millisecondes avant une nouvelle tentative.
Comment fonctionnent les WebSockets
Le client commence par une requête HTTP portant un en-tête Upgrade, et le serveur répond 101 Switching Protocols. Dès lors, la connexion transporte des trames WebSocket, et non du HTTP, et chaque côté peut envoyer à tout moment.
Cette liberté a un prix. Vous écrivez votre propre logique de reconnexion, votre propre format de message, souvent du JSON avec un champ type, et votre propre heartbeat. Un proxy qui ne transmet pas l'en-tête Upgrade bloquera aussi la connexion avant même qu'elle commence.
Une règle simple
Si le navigateur écoute surtout, choisissez SSE. Scores en direct, logs de build, statut de commande, notifications et texte diffusé en continu s'y prêtent tous.
Si le navigateur parle autant qu'il écoute, ou si les données sont binaires, choisissez un WebSocket. Jeux multijoueurs, éditeurs collaboratifs et salons de discussion relèvent de ce cas.
Server-sent events : code minimal
Serveur SSE en Node pur
Aucune bibliothèque nécessaire. La réponse reste ouverte ; chaque écriture est un événement, et la ligne de commentaire empêche les proxys inactifs de la fermer.
EventSource dans le navigateur
addEventListener utilise le nom d'événement du flux. La reconnexion se fait sans aucun code de votre part.
WebSocket : code minimal
Serveur WebSocket avec le package ws
Installez-le avec npm install ws. Il renvoie chaque message en majuscules au client qui l'a envoyé.
WebSocket dans le navigateur, avec une reconnexion simple
Contrairement à EventSource, rien ne se reconnecte pour vous : ce code attend un instant après close et ouvre un nouveau socket.
Le navigateur renvoie beaucoup de messages, plusieurs par seconde ou plus
Les données sont binaires, comme des morceaux audio ou des buffers d'état de jeu
Les clients doivent rattraper les événements manqués après une coupure de connexion
Le trafic passe par des proxys ou un hébergement qui ne gèrent que le HTTP simple
Les server-sent events conviennent. Rien de ce que vous avez coché n'exige un canal bidirectionnel, et EventSource vous offre la reconnexion et la reprise gratuitement.
Un WebSocket convient. Vous avez besoin de messages fréquents depuis le navigateur ou de données binaires, qu'un flux d'événements ne peut pas transporter.