Comparaison de SSE, WebSockets et de l’interrogation périodique

WebSockets établit une connexion TCP persistante entre le client et le serveur. Les deux parties peuvent envoyer des messages à tout moment, ce qui rend WebSockets idéal pour les communications véritablement interactives en temps réel : applications de discussion, édition collaborative de documents, jeux multijoueurs et curseurs en direct. La connexion reste ouverte jusqu’à ce que l’une des parties la ferme explicitement.

SSE (événements envoyés par le serveur) utilise une connexion HTTP ordinaire sur laquelle le serveur diffuse des données vers le client sous forme d’une série d’événements. La connexion est unidirectionnelle : seul le serveur envoie des données. Le client ne peut pas renvoyer de messages par cette connexion SSE ; il doit effectuer pour cela des requêtes HTTP distinctes. SSE est implémenté à l’aide de l’API de navigateur EventSource.

L’interrogation périodique courte signifie que le client envoie une requête HTTP à intervalle fixe, par exemple toutes les 5 secondes : « Y a-t-il des mises à jour ? » Le serveur répond immédiatement avec les données actuelles. C’est l’implémentation la plus simple, mais aussi la plus coûteuse — le client effectue de nombreuses requêtes lorsqu’il n’y a rien de nouveau. Cette méthode ne convient qu’aux données qui évoluent très lentement.

L’interrogation longue améliore l’interrogation périodique courte : le client effectue une requête et le serveur maintient la connexion ouverte jusqu’à ce que de nouvelles données soient disponibles. Lorsque de nouvelles données arrivent, le serveur répond et le client effectue immédiatement une autre requête. Cela réduit le nombre de réponses inutiles, mais entraîne toujours une surcharge supérieure à celle de SSE, car chaque réponse nécessite l’établissement d’une nouvelle connexion TCP.

SSE présente plusieurs avantages pratiques par rapport à WebSockets pour l’envoi de données du serveur vers le client : il fonctionne sur HTTP ordinaire, sans mise à niveau du protocole, et traverse donc les proxys d’entreprise et les équilibreurs de charge sans configuration particulière. EventSource intègre la reconnexion automatique. Le protocole textuel est facile à déboguer dans l’onglet réseau du navigateur.

SSE présente de véritables limites : il ne prend en charge que le texte, les données binaires devant être encodées en base64 ; il est unidirectionnel, le client ne pouvant pas renvoyer de données ; et HTTP/1.1 limite à 6 le nombre de connexions EventSource simultanées par domaine. HTTP/2 les multiplexe sur une seule connexion et supprime cette limite. Pour une communication bidirectionnelle, SSE nécessite des appels REST complémentaires.

SSE convient parfaitement aux tableaux de bord affichant des métriques en temps réel, aux flux de notifications qui transmettent de nouvelles alertes, aux barres de progression de processus serveur longs, aux flux de réseaux sociaux en direct, aux bandeaux de cotations boursières et aux interfaces de discussion où les messages vont uniquement du serveur vers le client, les messages étant envoyés séparément avec POST. Dans tous ces cas, c’est le serveur qui lance les mises à jour.

WebSockets sont nécessaires lorsque vous avez besoin d’une communication bidirectionnelle à faible latence : discussion en temps réel où les messages circulent dans les deux sens sur une seule connexion, édition collaborative à la Google Docs, jeux multijoueurs où les actions du client et les mises à jour du serveur se produisent rapidement, enchères en direct et plateformes de négociation. La bidirectionnalité justifie la complexité supplémentaire.

HTTP/2 améliore considérablement la viabilité de SSE. Le multiplexage des connexions signifie que tous les flux SSE d’un domaine partagent une seule connexion TCP, ce qui supprime la limite de connexions par domaine. Si votre serveur prend en charge HTTP/2, SSE devient encore plus pratique pour les tableaux de bord comportant plusieurs flux de données simultanés.

Cadre de décision : si vous avez besoin d’une communication bidirectionnelle à faible latence → WebSockets. Si le serveur envoie les mises à jour et que le client se contente de les lire → SSE. Si vous avez besoin de mises à jour occasionnelles et que la simplicité est importante → interrogation périodique. Si l’API du serveur existe déjà et que vous ne pouvez pas ajouter SSE → interrogation périodique. Commencez par la solution la plus simple qui répond à vos exigences de latence.

Le formatage WebSocket ajoute 2 à 14 octets par message après l’échange initial. SSE ajoute les en-têtes HTTP une seule fois par connexion, puis du texte délimité par des sauts de ligne. L’interrogation périodique courte inclut les en-têtes complets de la requête et de la réponse HTTP à chaque interrogation. Pour les données à haute fréquence, WebSockets l’emporte en matière de surcharge. Pour les envois peu fréquents du serveur, SSE est plus simple et sa surcharge reste acceptable.

Quelle est la principale différence de sens de communication entre SSE et WebSockets ?

WebSockets : connexion TCP persistante bidirectionnelle pour les discussions, les jeux et l’édition collaborative. SSE : envoi HTTP unidirectionnel du serveur vers le client via l’API EventSource pour les notifications, les tableaux de bord et les flux. Interrogation périodique courte : requêtes à intervalle fixe, solution la plus simple mais la plus coûteuse. Interrogation longue : le serveur conserve la réponse jusqu’à ce que les données soient disponibles, ce qui réduit le nombre de requêtes mais augmente la latence. Avantages de SSE : fonctionne à travers les proxys et offre la reconnexion automatique. Limites de SSE : texte uniquement, communication unidirectionnelle et limites de connexions avec HTTP/1.1.