WebSocket vs Server-Sent Events vs long polling vs WebRTC vs WebTransport
- Dans les applications web temps réel modernes, la capacité à transmettre des événements du serveur vers le client est indispensable.
- Ce besoin a conduit au développement de plusieurs méthodes, chacune avec ses avantages et ses inconvénients.
- Au départ, le long polling était la seule option disponible, puis WebSocket est apparu comme une solution plus robuste pour la communication bidirectionnelle.
- Après WebSocket, les Server-Sent Events (SSE) ont offert une méthode plus simple pour la communication unidirectionnelle du serveur vers le client.
- Le protocole WebTransport propose une approche plus efficace, plus flexible et plus scalable, et semble prêt à faire évoluer encore davantage ce domaine.
- Pour certains cas d’usage, WebRTC peut aussi être envisagé pour les événements serveur-client.
Qu’est-ce que le long polling ?
- Le long polling est la première technique de type « hack » qui a permis une forme de messagerie serveur-client exploitable dans le navigateur via HTTP.
- Contrairement au polling traditionnel, où le client interroge périodiquement le serveur pour obtenir des données, le long polling établit une connexion vers le serveur qui reste ouverte jusqu’à ce que de nouvelles données soient disponibles.
- Lorsque le serveur dispose de nouvelles informations, il envoie une réponse au client puis ferme la connexion.
- Le client lance une nouvelle requête immédiatement après avoir reçu la réponse du serveur, et ce processus se répète.
- Cette méthode permet des mises à jour de données plus immédiates et réduit le trafic réseau inutile ainsi que la charge serveur.
- Cependant, elle peut toujours introduire de la latence et reste moins efficace que d’autres technologies temps réel comme WebSocket.
Qu’est-ce que WebSocket ?
- WebSocket fournit un canal de communication full-duplex via une connexion unique et persistante entre le client et le serveur.
- Cette technologie permet l’échange de données entre le navigateur et le serveur sans la surcharge du cycle requête-réponse HTTP, ce qui la rend adaptée au transfert de données en temps réel.
- WebSocket représente une avancée majeure par rapport au HTTP traditionnel : une fois la connexion établie, les deux côtés peuvent envoyer des données indépendamment, ce qui le rend idéal pour les scénarios nécessitant une faible latence et des mises à jour fréquentes.
Qu’est-ce que les Server-Sent Events ?
- Les Server-Sent Events (SSE) fournissent une méthode standard pour pousser des mises à jour du serveur vers le client via HTTP.
- Contrairement à WebSocket, les SSE sont conçus uniquement pour une communication unidirectionnelle du serveur vers le client, ce qui les rend idéaux lorsque le client doit recevoir des mises à jour en temps réel sans avoir besoin d’envoyer des données au serveur.
Qu’est-ce que l’API WebTransport ?
- WebTransport est une API moderne conçue pour une communication efficace et à faible latence entre les clients web et les serveurs.
- Elle s’appuie sur le protocole HTTP/3 QUIC pour permettre différentes capacités de transfert de données.
- WebTransport est un outil puissant pour les applications qui nécessitent des performances réseau élevées, comme les jeux en temps réel, le live streaming et les plateformes collaboratives.
- WebTransport est actuellement au stade de working draft et n’est pas encore largement adopté.
Qu’est-ce que WebRTC ?
- WebRTC (Web Real-Time Communication) est un projet open source et un standard d’API qui permet des capacités de communication en temps réel (RTC) dans les navigateurs web et les applications mobiles, sans infrastructure serveur complexe ni installation de plugins supplémentaires.
- WebRTC prend en charge les connexions pair à pair pour l’échange audio, vidéo et de données entre navigateurs.
- WebRTC est conçu pour fonctionner à travers les NAT et les pare-feu, et utilise des protocoles comme ICE, STUN et TURN pour établir la connexion entre pairs.
Limites de ces technologies
- Seuls WebSocket et WebTransport permettent d’envoyer des données dans les deux sens.
- La limite de 6 requêtes par domaine restreint l’utilisabilité de toutes les méthodes persistantes de messagerie serveur-client.
- Dans les applications mobiles, le système d’exploitation place automatiquement l’application en arrière-plan après un certain temps d’inactivité, ce qui ferme les connexions ouvertes.
- En environnement d’entreprise, de nombreux proxys et pare-feu bloquent les connexions non HTTP, ce qui rend l’intégration d’un serveur WebSocket dans l’infrastructure difficile.
Comparaison des performances
- Comparer directement les performances de WebSocket, SSE, long polling et WebTransport suppose d’évaluer des aspects clés comme la latence, le débit, la charge serveur et la scalabilité dans différentes conditions.
Latence
- WebSocket : offre la latence la plus faible grâce à une communication full-duplex sur une connexion unique et persistante.
- Server-Sent Events : offrent une faible latence pour la communication du serveur vers le client, mais ne permettent pas d’envoyer des messages au serveur sans requêtes HTTP supplémentaires.
- Long polling : entraîne une latence plus élevée, car il dépend de l’établissement d’une nouvelle connexion HTTP pour chaque transfert de données.
- WebTransport : devrait offrir une faible latence comparable à WebSocket, tout en profitant du protocole HTTP/3 pour un multiplexage plus efficace et un meilleur contrôle de congestion.
Débit
- WebSocket : peut atteindre un débit élevé grâce à la connexion persistante, mais le débit peut chuter lorsque le client ne peut pas traiter les données aussi vite que le serveur peut les envoyer.
- Server-Sent Events : peuvent atteindre un débit supérieur à celui de WebSocket pour la communication unidirectionnelle serveur-client, car ils permettent de diffuser des messages à de nombreux clients avec moins de surcharge.
- Long polling : offre généralement un débit plus faible en raison de la surcharge liée aux ouvertures et fermetures fréquentes de connexion.
- WebTransport : devrait prendre en charge un débit élevé à la fois pour les flux bidirectionnels et unidirectionnels au sein d’une même connexion, et pourrait surpasser WebSocket dans les scénarios nécessitant plusieurs flux.
Scalabilité et charge serveur
- WebSocket : maintenir un grand nombre de connexions WebSocket peut augmenter significativement la charge serveur, ce qui peut affecter la scalabilité des applications avec beaucoup d’utilisateurs.
- Server-Sent Events : sont plus scalables que WebSocket dans les scénarios où l’on a surtout besoin de mises à jour du serveur vers le client, car la surcharge de connexion est plus faible.
- Long polling : est le moins scalable en raison de la forte charge serveur provoquée par les établissements de connexion fréquents.
- WebTransport : a une forte scalabilité, car il est conçu pour tirer parti de l’efficacité de HTTP/3 dans la gestion des connexions et des flux, réduisant ainsi la charge serveur par rapport à WebSocket et SSE.
Recommandations et adéquation selon les cas d’usage
- Dans le paysage des technologies de communication serveur-client, chacune présente des avantages spécifiques et des cas d’usage qui lui conviennent.
- Server-Sent Events (SSE) sont les plus simples à implémenter et permettent d’éviter des problèmes techniques en contournant les restrictions des pare-feu d’entreprise.
- WebSocket excelle dans les scénarios qui exigent une communication bidirectionnelle persistante.
- WebTransport est difficile à adopter, n’est pas largement pris en charge dans les frameworks serveur, y compris Node.js, et n’est pas compatible avec Safari.
- Long polling est inefficace et, en raison de la forte surcharge liée à l’établissement répété de nouvelles connexions HTTP, son usage n’est pas recommandé dans la plupart des cas.
Problèmes connus
- Toutes les technologies de streaming temps réel présentent des problèmes connus.
- Le client peut manquer des événements survenus côté serveur lorsqu’il se connecte, se reconnecte ou est hors ligne.
- Les pare-feu d’entreprise peuvent poser problème pour l’utilisation des technologies de streaming.
L’avis de GN⁺
- Cet article compare différentes technologies de communication à la disposition des développeurs pour construire des applications web temps réel, et fournit donc des informations utiles pour choisir une technologie.
- WebSocket et SSE sont déjà largement utilisés, et WebSocket est particulièrement populaire dans les applications nécessitant une communication bidirectionnelle, comme le chat en temps réel ou les jeux.
- WebTransport est encore au stade de brouillon et n’est pas largement pris en charge, ce qui peut rendre son adoption difficile dans des projets réels. Néanmoins, il mérite l’attention en raison de son fort potentiel en tant que technologie basée sur HTTP/3.
- Le long polling est une technologie ancienne, mais il peut encore être utile dans certaines situations, en particulier lorsque la compatibilité avec des systèmes legacy est importante.
- Lors du choix d’une technologie de communication temps réel, il faut prendre en compte les besoins de l’application, les navigateurs et infrastructures serveur pris en charge, ainsi que le niveau de maturité de la technologie.
1 commentaires
Avis sur Hacker News
Un commentaire exprime son attachement à Server Sent Events (SSE), tout en mentionnant l’absence de contrôle de flux (backpressure) et de multiplexage dans WebSockets, l’impossibilité pour SSE de transmettre des données binaires, ainsi que les difficultés potentielles d’adoption de WebTransport.
Un autre souligne la difficulté d’implémenter des fonctionnalités temps réel en environnement d’entreprise et les limites imposées par la bureaucratie pour résoudre ces problèmes, en proposant simplement d’ajouter un bouton d’actualisation.
En supposant HTTP/2 ou supérieur, un avis estime que la combinaison d’EventSource et de
fetch()devrait être presque aussi bonne que d’autres protocoles utilisant une seule connexion TCP, avec une mention positive de l’usage d’UDP dans HTTP/3.Un commentaire dit ne pas comprendre pourquoi WebSockets et SSE ne prennent pas en charge l’envoi d’en-têtes dans la requête initiale, et relève que l’authentification des services temps réel est souvent laissée à la charge de l’implémenteur.
Sont également évoqués les problèmes de gestion à grande échelle de WebSockets et SSE, les besoins particuliers d’observabilité côté backend, la difficulté du débogage sur appareils mobiles, le coût des connexions réseau et la complexité du maintien d’état.
Une personne partage son expérience d’un système d’enchères en ligne conçu dans les années 90, où les mises à jour en temps réel étaient gérées via server push / HTTP streaming.
Un commentaire exprime sa nostalgie pour la simplicité du long polling, tout en donnant aussi une appréciation positive de WebRTC.
Une personne travaillant chez Stream recommande, dans la plupart des cas, d’utiliser des websockets avec un ping keep-alive toutes les 30 secondes, tout en mentionnant la faible latence de WebTransport et son intérêt pour les jeux en temps réel ou la transmission de données vocales.
Enfin, un avis critique reproche à l’article de ne pas avoir mentionné les avantages de la communication basée sur UDP de WebRTC.