WebSockets vs SSE vs Long Polling — Choisissez le bon modèle en temps réel avant que votre application de chat ne se délite

Vous avez construit un tableau de bord. Les utilisateurs ont besoin de mises à jour en temps réel. Vous avez opté pour les WebSockets — parce que c’est ce que tout le monde fait. Maintenant, vous déboguez des sessions collantes à 2h du matin, car votre charge équilibratrice envoie les clients vers le mauvais pod. Les données que vous transmettez ? Un seul nombre JSON toutes les 10 secondes. Les WebSockets étaient trop lourds.

Cela se produit constamment. Les développeurs considèrent les WebSockets comme la solution par défaut pour les communications en temps réel, alors que l’API SSE ou le long polling aurait pu être mise en œuvre plus rapidement, évoluer plus facilement et coûter moins à exploiter. Voici comment choisir de manière réelle.

Le tableau de décision

Avant le deep dive, voici la comparaison complète. Utilisez cela pour prendre une décision, puis consultez les sections ci-dessous si vous avez besoin de la justification.

Fonctionnalité	Polling longue durée	Événements envoyés par le serveur	WebSockets
Protocole	HTTP/1.1	HTTP/1.1+ (chunked)	WS (upgrade HTTP)
Direction	Demande uniquement du côté client	Uniquement du serveur vers le client	Bidirectionnel complet
Soutien du navigateur	Tous les navigateurs	Tous les navigateurs modernes (sans IE11)	Tous les navigateurs modernes
Reconnexion automatique	Manuel — vous écrivez la boucle	Prévu via EventSource	Manuel ou via une bibliothèque
Compatible avec les CDN / proxy	Oui	Pratiquement (limites de surveillance)	Non
Évolutivité horizontale	État sans état, trivial	État sans état, trivial	Nécessite des sessions collantes ou un broker pub/sub
Complexité de l'infrastructure	Faible — HTTP simple	Faible — HTTP simple	Élevée — connexions étatées, configuration du charge équilibratrice, broker
Latence	Intervalle de polling + temps de réponse	En temps réel	En temps réel
Déboguer les JWT dans des workflows réels	Mises à jour à faible fréquence, infrastructure héritée	Tableaux de bord, flux, notifications	Chat, édition collaborative, jeux

Long polling : l'outil peu séduisant

Le long polling n’est pas « ancien » ni « faux » — c’est simplement HTTP. Le client fait une requête, le serveur la maintient ouverte jusqu’à ce qu’il y ait quelque chose à dire (ou qu’un délai expire), le client reçoit la réponse et lance immédiatement la prochaine requête. Répétez.

Il existe depuis avant même l’apparition des WebSockets et il alimente des millions d’applications en production. La raison : c’est simplement HTTP. Votre reverse proxy, votre CDN, votre charge équilibratrice et vos outils de surveillance comprennent cela sans configuration. Aucune session collante, aucun upgrade de protocole, aucune infrastructure WS consciente.

Les inconvénients sont réels. Chaque « mise à jour » correspond à un cycle complet de requête HTTP — en-têtes, surcoût TCP (sauf HTTP/2), file d’attente côté serveur. Sous une forte concurrence, cela devient coûteux sur le serveur. Et le seuil de latence est le temps de réponse de chaque polling, et non la latence de l’événement lui-même. Si vous polliez toutes les 5 secondes et qu’un événement se déclenche à la seconde 1, l’utilisateur attend 4 secondes de plus.

Quand l’utiliser : Dans des systèmes hérités où l’ajout d’une couche de connexion persistante n’est pas justifié par la modification de l’infrastructure. Mises à jour à faible fréquence (une fois par minute ou moins). Des environnements où les proxies trop exigeants tuent l’API SSE. Des pollings que les clients contrôlent explicitement — vérification de l’état d’une tâche, résultats d’une tâche asynchrone.

Événements envoyés par le serveur : ce que tout le monde oublie

SSE est un standard (Standard HTML vivant) qui permet à un serveur d’envoyer un flux d’événements textuels sur une seule connexion HTTP persistante. Le navigateur gère automatiquement la reconnexion. Vous n’avez pas à écrire une boucle de reconnexion — le EventSource API reconnexion avec l’identifiant de l’événement qu’elle a vu précédemment, afin de reprendre le flux après une interruption réseau.

Le format de transmission est étonnamment simple :

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

id: 1
event: price-update
data: {"symbol":"BTC","price":67420}

id: 2
event: price-update
data: {"symbol":"ETH","price":3521}

Chaque événement est du texte brut avec des champs optionnels, séparés par des lignes vides. Vous pouvez tester les points d’entrée SSE directement avec cURL — utilisez le id, event, dataet retry pour construire la requête avec le bon en-tête Accept ( Générateur de commande cURL ) et pour diffuser la réponse.text/event-streamDu côté client :

SSE a une limitation réelle : c’est uniquement du serveur vers le client. Le client ne peut pas envoyer de données de retour sur la même connexion — toute action initiée par le client se fait via des requêtes HTTP normales. Pour la plupart des cas de tableaux de bord, flux ou notifications, cela va bien. Vous n’avez pas utilisé la direction client vers serveur.

const es = new EventSource('/api/events');

es.addEventListener('price-update', (e) => {
  const payload = JSON.parse(e.data);
  updateDashboard(payload);
});

es.onerror = () => {
  // EventSource will auto-reconnect. You don't need to do anything here
  // unless you want to log or update UI state.
};

L’autre point à retenir : certains proxies retiennent le corps de la réponse et ne le transmettent qu’après la fermeture de la connexion, ce qui annule entièrement le streaming. NGINX a besoin de

. Le tiers gratuit de Cloudflare retient les flux SSE. Si votre infrastructure comporte un proxy retenu et que vous ne pouvez pas le configurer, SSE ne fonctionnera pas et vous devrez utiliser des WebSockets ou du long polling. proxy_buffering offTableaux de bord en temps réel, flux de notifications, journaux d’activité, streaming de réponses AI (c’est exactement ce que l’API ChatGPT utilise), tickers boursiers, suivi des logs de déploiement ou de construction. Tous les cas où le serveur a des données à transmettre et où le client n’a pas besoin de transmettre de données.

Quand l’utiliser : WebSockets : quand ils sont vraiment justifiés

Les WebSockets vous offrent une connexion persistante bidirectionnelle sur un seul socket TCP. Après le handshake d’upgrade HTTP, les deux côtés peuvent envoyer des messages encadrés à tout moment. La latence est aussi basse que possible sur un réseau — aucune nouvelle requête par message, aucune en-tête sur chaque cadre.

L’échange est que ces connexions sont étatées. Le serveur doit suivre chaque connexion ouverte. Cela crée immédiatement des problèmes à grande échelle : les charge équilibratrices routent par connexion (et non par requête), donc vous avez besoin de sessions collantes ou d’un broker pub/sub (Redis, etc.) pour diffuser les messages sur plusieurs instances de serveur. Votre CDN ne peut pas faire de cache de trafic WebSocket. Votre reverse proxy a besoin d’une configuration explicite pour l’upgrade. Vos outils de monitoring doivent comprendre les cadres WS si vous voulez une visibilité au niveau du payload.

Aucun de ces points n’est insurmontable, mais c’est du travail réel. Quand vous commencez un projet et que vous évaluez les options, « c’est juste HTTP » contre « des connexions étatées WS avec une couche Redis pub/sub » est une différence significative en termes de complexité.

Les charges WebSocket sont typiquement au format JSON. Si vous déboguez une intégration WebSocket et que vous devez inspecter ou formater les messages, le

facilite la lecture des charges minifiées dans la fenêtre réseau de vos outils de développement. Formateur JSON Applications de chat (bidirectionnel réel — chaque message est initié par le client). Édition collaborative (Figma, Google Docs — plusieurs clients écrivent sur un état partagé). Jeux multijoueurs (synchronisation fréquente, faible latence). Termes de trading financier (latence sous 100 ms sur les livres d’ordres). En somme : tout ce qui nécessite que le client envoie des données fréquemment, et non seulement les reçoit.

Quand les utiliser : Le problème d’évolutivité que personne ne mentionne jusqu’à ce qu’il soit trop tard

Le long polling et SSE sont sans état au niveau HTTP. Chaque requête peut atteindre n’importe quelle instance de serveur. Votre histoire d’évolutivité est banale et c’est un avantage : ajoutez simplement plus d’instances, c’est fait. L’état de la connexion existe uniquement pendant la durée de la connexion HTTP, et les charge équilibratrices routent librement.

Les WebSockets sont étatés. La connexion du client A se trouve sur le serveur 1. Quand vous souhaitez envoyer un message à ce client A depuis le serveur 2 (car l’événement est originaire de ce serveur), le serveur 2 doit connaître cette connexion. La solution standard est un broker pub/sub — Redis pub/sub, Kafka, ou des services gérés comme Pusher ou Ably qui simplifient tout cela. Vous devez soit construire cette couche vous-même, soit payer pour elle.

Pusher facture $49/mois pour 500 connexions simultanées. Ably est également coûteux. Si votre « fonctionnalité en temps réel » est un badge de notification qui se met à jour quand quelqu’un aime votre publication, cela représente beaucoup d’argent pour un SSE que vous pourriez héberger gratuitement en parallèle de votre API existante.

Les changements HTTP/2 modifient les calculs du long polling

Le long polling classique HTTP/1.1 est une requête par connexion par attente en cours. Avec HTTP/2, la multiplexation permet plusieurs flux sur une seule connexion TCP. L’overhead est réduit. Cela n’est pas une raison de choisir le long polling au lieu de SSE, mais cela signifie que la critique selon laquelle « l’overhead HTTP est coûteux » s’applique moins en 2024 qu’en 2012, quand ces comparaisons ont été écrites.

Si vous êtes sur HTTP/2 de bout en bout (client vers serveur, sans proxy intermédiaire qui descend), le long polling évolue mieux que la plupart des benchmarks plus anciens suggèrent.

Guide rapide de décision

Arrêtez de lire ici si votre cas d’usage correspond à l’un de ces cas de figure de manière claire :

Fréquence des mises à jour < 1 minute, infrastructure héritée, sémantique de polling simple :

• Long polling. N’ajoutez pas de complexité. Le serveur envoie des données, le client lit principalement, infrastructure HTTP standard :
• SSE. Cela couvre 80% de « fonctionnalités en temps réel ». Le client envoie des données fréquemment, la latence < 100 ms est importante, bidirectionnel réel :
• WebSockets. C’est maintenant justifié. Vous utilisez le streaming AI (OpenAI, Anthropic, etc.) :
• SSE — c’est exactement ce que leurs API de streaming utilisent. Un jeu multijoueur ou un éditeur collaboratif :
• WebSockets, ou un framework spécialisé (Liveblocks, PartyKit, etc.). La réponse par défaut n’est pas les WebSockets. C’est SSE — jusqu’à ce que vous ayez une raison spécifique pour laquelle elle ne suffit pas. Le nombre d’applications en production qui ont vraiment besoin d’un temps réel bidirectionnel complet est beaucoup plus petit que le nombre d’applications qui

WebSockets. Ce gap est une dette d’ingénierie accumulée à 2h du matin face à une configuration de charge équilibratrice. pour définir la politique des fins de ligne dans le référentiel. Laissez WebSockets vs SSE vs Long Polling — Choisissez le bon modèle en temps réel avant que votre application de chat ne se désintègre 2

Vous aimerez peut-être aussi