Comparaison entre WebSockets, événements envoyés par le serveur, long polling, WebRTC et WebTransport

 (rxdb.info)
4 points par GN⁺ 2024-03-19 | 1 commentaires | Partager sur WhatsApp
  • Dans les applications web en temps réel, le choix entre Long Polling, WebSockets, SSE, WebRTC et WebTransport pour transmettre des événements du serveur au client change fortement la latence, la bidirectionnalité, la difficulté d’implémentation et les contraintes d’exploitation
  • WebSockets fournit une communication bidirectionnelle via une connexion unique de longue durée, mais en production on utilise souvent aussi des bibliothèques comme Socket.IO à cause de la détection des pertes de connexion, de la reconnexion et des heartbeats ping-pong
  • Server-Sent Events est un flux unidirectionnel HTTP du serveur vers le client, donc l’implémentation et la gestion de la reconnexion sont simples, mais l’API EventSource de base est limitée pour l’envoi d’un corps POST ou d’en-têtes personnalisés
  • WebTransport prend en charge les flux multiples sur HTTP/3 QUIC ainsi que les transferts fiables et non fiables, mais au mois de mars 2024 il est encore au stade de Working Draft et ne bénéficie pas de support natif dans Safari ni Node.js, ce qui en fait difficilement un choix universel pour l’instant
  • À cause des arrêts d’apps en arrière-plan sur mobile, des limites de connexions par domaine, des proxys et pare-feu d’entreprise, et de la perte possible d’événements pendant la reconnexion, les vraies applications ont aussi besoin d’une logique de récupération de synchronisation et de tests d’infrastructure

L’évolution des technologies de communication temps réel serveur-client

  • Dans les applications web en temps réel, la possibilité pour le serveur d’envoyer des événements au client est devenue une exigence centrale
  • Au départ, Long Polling, fonctionnant au-dessus de HTTP, était utilisé dans les navigateurs comme méthode de messagerie serveur-client
  • Ensuite, WebSockets est apparu comme une méthode plus robuste pour la communication bidirectionnelle
  • Server-Sent Events (SSE) propose de manière plus simple une communication unidirectionnelle allant uniquement du serveur vers le client
  • WebTransport pourrait devenir une approche plus efficace, plus flexible et plus scalable, mais sa prise en charge reste aujourd’hui limitée
  • WebRTC peut être envisagé pour certains cas de niche d’événements serveur-client, mais son objectif est différent, donc il ne constitue pas un choix principal

Long Polling

  • Long Polling est une méthode qui imite la communication push du serveur avec de simples requêtes XHR
  • Le client laisse une requête ouverte vers le serveur, et le serveur retarde sa réponse jusqu’à ce que de nouvelles données soient disponibles
  • Après l’envoi de nouvelles informations, la connexion se ferme et le client lance immédiatement la requête suivante
  • Par rapport au polling périodique traditionnel, les mises à jour arrivent plus vite et cela peut réduire le trafic réseau inutile ainsi que la charge serveur
  • Cela reste toutefois moins efficace que des technologies temps réel comme WebSockets, et une latence peut apparaître selon le moment où les données sont transmises
  • L’implémentation côté client est simple, mais côté back-end il est difficile de garantir qu’un client en cours de reconnexion ne manque pas des événements

WebSockets

  • WebSockets crée une connexion unique de longue durée entre le client et le serveur et fournit une communication full-duplex
  • Une fois la connexion établie, les deux côtés peuvent envoyer des données indépendamment, sans le surcoût du cycle requête-réponse HTTP
  • Il convient aux applications qui ont besoin d’une faible latence et de mises à jour fréquentes, comme le chat en temps réel, les jeux ou les plateformes de trading financier
  • L’API WebSocket de base est facile à utiliser, mais en production la gestion des pertes de connexion et de leur recréation devient complexe
  • Comme il est difficile de détecter si la connexion est encore réellement utilisable, on ajoute généralement des heartbeats ping-and-pong
  • À cause de cette complexité, on utilise souvent des bibliothèques comme Socket.IO, qui peut aussi fournir un fallback en Long Polling si nécessaire

Server-Sent Events

  • Server-Sent Events (SSE) est une méthode standard pour pousser des mises à jour du serveur vers le client au-dessus de HTTP
  • Contrairement à WebSockets, elle est conçue uniquement pour une communication unidirectionnelle serveur → client
  • Elle convient aux situations où le client n’a pas besoin d’envoyer de messages au serveur, comme les flux d’actualités en direct, les scores sportifs ou les mises à jour en temps réel
  • On peut voir SSE comme une connexion HTTP maintenue ouverte, dans laquelle le back-end diffuse la réponse ligne par ligne à mesure que des événements se produisent
  • Côté navigateur, le client initialise une instance EventSource pour recevoir le flux d’événements
  • EventSource se reconnecte automatiquement si la connexion est interrompue, contrairement à WebSockets
  • Le serveur doit définir l’en-tête Content-Type sur text/event-stream et formater des champs comme le type d’événement, la payload de données, l’ID d’événement et le délai de retry conformément à la spécification SSE

WebTransport

  • WebTransport est une API pour une communication efficace et à faible latence entre clients web et serveurs
  • Elle s’appuie sur le protocole HTTP/3 QUIC pour envoyer des données sur plusieurs flux
  • Elle prend en charge à la fois les transferts fiables, non fiables et les données non ordonnées
  • Elle peut devenir un outil puissant pour les applications qui ont besoin de réseau haute performance, comme les jeux temps réel, le live streaming ou les plateformes collaboratives
  • En mars 2024, WebTransport est encore au stade de Working Draft et n’est pas largement pris en charge
  • Il n’est pas encore utilisable dans Safari et n’a pas de support natif dans Node.js
  • Même si son support s’élargit, l’API est très complexe et il est probable qu’on construise plutôt des bibliothèques au-dessus de WebTransport que de l’utiliser directement dans le code applicatif

WebRTC

  • WebRTC est un projet open source et un standard d’API qui apporte des capacités de communication en temps réel dans les navigateurs et les apps mobiles sans plugin
  • Il prend en charge des connexions peer-to-peer pour l’échange audio, vidéo et données entre navigateurs
  • Il utilise des protocoles comme ICE, STUN et TURN pour traverser le NAT et les pare-feu
  • WebRTC a été conçu pour les interactions client-client, mais on peut aussi l’utiliser pour de la communication serveur-client en faisant agir le serveur comme un client
  • Cette approche ne correspond qu’à des cas d’usage de niche, c’est pourquoi elle est exclue des comparaisons principales
  • De toute façon, WebRTC a besoin d’un serveur de signalisation, qui fonctionnera lui-même au-dessus de WebSockets, SSE ou WebTransport
  • Pour cette raison, son intérêt comme substitut direct à ces technologies reste limité

Principales contraintes selon la technologie

  • Transmission de données bidirectionnelle

    • Seuls WebSockets et WebTransport permettent de recevoir des données du serveur et d’envoyer des données du client sur la même connexion
    • Long Polling est théoriquement possible aussi, mais il n’est pas recommandé car l’envoi de nouvelles données sur une connexion long-polling existante exige une requête HTTP supplémentaire
    • Avec Long Polling, il vaut mieux envoyer les données client → serveur via une requête HTTP séparée sans perturber la connexion existante
    • SSE ne prend pas en charge l’envoi de données supplémentaires vers le serveur
    • L’API EventSource native ne permet pas non plus d’envoyer des données comme un POST dans le corps HTTP de la requête initiale
    • Il faut alors placer les données dans les paramètres d’URL, ce qui n’est pas idéal en sécurité car des identifiants peuvent fuiter dans les logs serveur, les proxys ou les caches
    • Pour éviter ce problème, RxDB utilise le polyfill eventsource au lieu de l’EventSource API native, ce qui ajoute des fonctionnalités comme les en-têtes HTTP personnalisés
    • Le fetch-event-source de Microsoft permet d’envoyer des données dans le body et d’utiliser des requêtes POST au lieu de GET

  • Limites du nombre de connexions par domaine

    • La plupart des navigateurs modernes autorisent 6 connexions par domaine, ce qui limite l’utilisabilité générale des méthodes stables de messagerie serveur → client
    • Cette limite de 6 connexions est partagée entre les onglets du navigateur, donc si la même page est ouverte dans plusieurs onglets, ils doivent se partager le même pool de connexions
    • La RFC HTTP/1.1 recommande une limite encore plus basse, de 2 connexions par serveur ou proxy
    • Cette politique est pertinente pour éviter les DDoS via les visiteurs, mais elle peut poser problème lorsqu’une communication serveur-client légitime nécessite plusieurs connexions
    • Pour contourner cela, il faut utiliser HTTP/2 ou HTTP/3 afin que le navigateur n’ouvre qu’une seule connexion par domaine et gère les données via le multiplexage
    • Même avec HTTP/2 et HTTP/3, le paramètre SETTINGS_MAX_CONCURRENT_STREAMS limite le nombre réel de flux simultanés, avec une valeur par défaut souvent fixée à 100 flux concurrents
    • Les navigateurs pourraient augmenter la limite de connexions pour certaines API comme EventSource, mais les tickets associés dans Chromium et Firefox sont marqués “won’t fix”

  • Réduire le nombre de connexions dans une app navigateur

    • Dans une application navigateur, il faut partir du principe que l’utilisateur peut ouvrir l’app dans plusieurs onglets à la fois
    • Par défaut, chaque onglet peut ouvrir une connexion de flux serveur, mais cela est généralement inutile
    • Il est possible de n’ouvrir qu’une seule connexion, même avec plusieurs onglets, et de la partager entre eux
    • RxDB utilise LeaderElection du package npm broadcast-channel pour ne maintenir qu’un seul flux de réplication entre le serveur et le client
    • Ce package peut aussi être utilisé seul dans d’autres applications, sans RxDB

Contraintes d’exploitation sur mobile, avec proxys et pare-feu

  • Sur les systèmes mobiles comme Android et iOS, il est difficile de garder durablement des connexions ouvertes, y compris avec WebSockets
  • Les OS mobiles peuvent placer une application en arrière-plan après une certaine période d’inactivité et fermer les connexions ouvertes
  • Ce comportement fait partie des stratégies de gestion des ressources visant à économiser la batterie et à optimiser les performances
  • Les développeurs utilisent donc souvent des notifications push mobiles plutôt qu’une connexion persistante lorsque le serveur doit envoyer des données au client
  • Les notifications push permettent au serveur d’informer l’application de nouvelles données et de déclencher son activité ou ses mises à jour sans connexion ouverte en permanence
  • En environnement d’entreprise, les proxys et pare-feu peuvent bloquer les connexions non HTTP, ce qui peut compliquer l’intégration d’un serveur WebSocket dans l’infrastructure
  • Dans ce type d’environnement, SSE, basé sur HTTP, peut être plus facile à intégrer en entreprise
  • Long Polling reste aussi une option puisqu’il n’utilise que des requêtes HTTP ordinaires

Comparaison des performances

  • Pour comparer WebSockets, SSE, Long Polling et WebTransport, il faut examiner ensemble la latence, le débit, la charge serveur et la scalabilité
  • Les démos du repo realtime-web, qui testent les temps de message avec une implémentation serveur en Go, montrent des performances similaires entre WebSockets, WebRTC et WebTransport
  • Comme WebTransport est une technologie récente basée sur HTTP/3, d’autres optimisations de performance peuvent encore apparaître après mars 2024
  • WebTransport est optimisé pour réduire la consommation d’énergie, mais cet indicateur n’a pas été testé

  • Latence

    • WebSockets offre la plus faible latence grâce à la communication full-duplex sur une connexion persistante unique
    • SSE offre aussi une faible latence pour la communication serveur → client, mais le client doit faire une requête HTTP supplémentaire pour envoyer un message au serveur
    • Long Polling présente une latence plus élevée car il crée une nouvelle connexion HTTP pour chaque transmission de données
    • En Long Polling, la latence peut fortement augmenter si le client est justement en train d’ouvrir une nouvelle connexion au moment où le serveur veut envoyer un événement
    • WebTransport devrait offrir une faible latence comparable à WebSockets, en s’appuyant sur un multiplexage plus efficace et un meilleur contrôle de congestion dans HTTP/3

  • Débit

    • WebSockets peut fournir un débit élevé grâce à sa connexion persistante, mais les problèmes de backpressure, lorsque le client ne traite pas les données aussi vite que le serveur les envoie, peuvent l’affecter
    • SSE a moins d’overhead que WebSockets et peut potentiellement offrir un meilleur débit pour des diffusions unidirectionnelles serveur → client
    • Long Polling offre généralement un débit plus faible et consomme davantage de ressources serveur à cause de l’overhead lié aux ouvertures et fermetures fréquentes de connexion
    • WebTransport devrait prendre en charge un débit élevé aussi bien pour les flux unidirectionnels que bidirectionnels au sein d’une même connexion, et pourrait dépasser WebSockets dans les scénarios nécessitant plusieurs flux

  • Scalabilité et charge serveur

    • WebSockets peut fortement augmenter la charge serveur à mesure que le nombre de connexions maintenues grandit, ce qui peut affecter la scalabilité des applications à fort volume d’utilisateurs
    • SSE est plus scalable dans les scénarios principalement centrés sur les mises à jour serveur → client
    • SSE utilise des requêtes HTTP ordinaires sans procédure WebSocket comme le protocol upgrade, ce qui réduit l’overhead de connexion
    • Long Polling est le moins scalable à cause de l’établissement fréquent de connexions et ne convient guère qu’en mécanisme de fallback
    • WebTransport a été conçu pour une forte scalabilité grâce à l’efficacité de HTTP/3 dans la gestion des connexions et des flux, et pourrait réduire la charge serveur par rapport à WebSockets et SSE

Recommandations selon les cas d’usage

  • SSE est l’option la plus simple à implémenter et utilise le protocole HTTP/S existant, ce qui facilite l’évitement des restrictions des pare-feu d’entreprise et d’autres problèmes techniques liés à d’autres protocoles
  • Il s’intègre facilement à Node.js et à d’autres frameworks serveur
  • Il convient bien aux applications qui nécessitent des mises à jour fréquentes du serveur vers le client, comme les flux d’actualités, les cours de Bourse ou le streaming d’événements en direct
  • WebSockets est particulièrement adapté aux scénarios nécessitant une communication bidirectionnelle continue
  • C’est le choix principal pour les jeux dans le navigateur, les applications de chat ou les mises à jour sportives en direct impliquant des interactions constantes
  • WebTransport a du potentiel, mais son support dans les frameworks serveur reste limité et sa compatibilité avec Node.js et Safari est insuffisante
  • WebTransport dépend de HTTP/3, et la prise en charge de HTTP/3 par de nombreux serveurs web comme nginx reste encore expérimentale
  • C’est une technologie d’avenir qui prend en charge les transferts fiables et non fiables, mais elle n’est pas encore une option réellement viable pour la plupart des usages actuels
  • Long Polling est globalement une approche vieillissante à cause de l’inefficacité et du coût élevé liés à l’établissement répété de nouvelles connexions HTTP
  • Il peut servir de fallback dans les environnements qui ne prennent pas en charge WebSockets ou SSE, mais son utilisation générale n’est pas recommandée en raison de ses limites de performance

Le problème des événements manqués pendant la reconnexion

  • Lorsqu’on construit des fonctionnalités sur des technologies de streaming temps réel, il faut toujours prendre en compte les interruptions de connexion et les reconnexions
  • Si le client est en cours de connexion, de reconnexion ou hors ligne, il peut ne pas recevoir les événements produits côté serveur
  • Si le serveur diffuse à chaque fois l’état complet, comme pour des cours de Bourse, manquer quelques événements peut ne pas être grave
  • Si le back-end ne diffuse que des résultats partiels, les événements manqués doivent impérativement être traités
  • Demander au back-end de mémoriser quels événements ont été correctement transmis à chaque client ne scale pas bien
  • Il vaut mieux traiter ce problème dans la logique côté client
  • Le RxDB Sync Engine utilise deux modes de fonctionnement
    • checkpoint iteration mode : interroge de façon répétée les données du back-end via des requêtes HTTP normales jusqu’à ce que le client soit de nouveau synchronisé
    • event observation mode : maintient le client synchronisé grâce aux mises à jour du flux temps réel
  • Si la connexion du client est interrompue ou qu’une erreur se produit, la réplication repasse temporairement en checkpoint iteration mode pour resynchroniser le client jusqu’à retrouver exactement l’état du serveur
  • Cette approche permet de compenser les événements manqués et de garantir que le client reste toujours synchronisé avec le serveur de manière exacte

Points à vérifier dans une infrastructure d’entreprise

  • Dans une infrastructure d’entreprise, des problèmes peuvent survenir avec l’ensemble des technologies de streaming
  • Les proxys et pare-feu peuvent bloquer le trafic ou casser involontairement des requêtes et réponses
  • Lorsqu’on implémente une application temps réel dans ce type d’environnement, il faut d’abord tester si la technologie choisie fonctionne réellement sur cette infrastructure

À lire aussi

1 commentaires

 
GN⁺ 2024-03-19
Avis sur Hacker News

  • J’ai toujours eu un faible pour les Server-Sent Events. C’est simple, facile à utiliser et à implémenter

    • Avec IPv6, c’est désormais facilement extensible à grande échelle et, si c’est bien conçu, il suffit presque de fournir au client une liste de services SSE pour que cela fonctionne de manière quasi sans état, ce qui rend la montée en charge bien plus simple
      WebSocket devient assez complexe à faire évoluer au-delà d’un certain niveau d’utilisation
    • Grâce à sa simplicité, on peut le faire monter en charge avec un CDN beaucoup plus facilement que WebSocket : https://www.fastly.com/blog/server-sent-events-fastly
    • D’accord. Cela dit, les navigateurs limitent à 6 flux SSE par origine et par instance de navigateur, donc sans ajouter de complexité côté client, on peut être limité à 6 onglets
      https://crbug.com/275955
    • L’inconvénient, c’est qu’il faut encoder la charge utile en base64 ou supprimer les sauts de ligne
      Je me demande pourquoi ils n’en ont pas simplement fait une réponse en streaming multipart. Cela prend aussi en charge les métadonnées, et c’est un format très couramment implémenté
    • Ça fonctionne même avec un Apache prefork classique et PHP

  • Il y a d’autres inconvénients à connaître
    WebSocket n’a ni contrôle de flux (backpressure) ni multiplexage ; si vous en avez besoin, il faut le construire vous-même ou utiliser quelque chose comme RSocket. SSE ne permet pas non plus d’envoyer directement des données binaires, il faut un encodage comme base64
    WebTransport traite ces problèmes et résout aussi le blocage HOL, mais je crains qu’il ne se passe la même chose que lors des transitions Python 2→3 ou IPv6 : les gens continuent d’utiliser l’ancienne version et les bénéfices de la mise à niveau paraissent faibles
    Tant que les navigateurs continuent de fonctionner en TCP, certains réseaux peuvent bloquer complètement UDP, et donc HTTP/3/WebTransport

    • Le blocage HOL est un problème, mais TCP fournit un contrôle de flux. Si vous ne l’utilisez pas, vous passez au-dessus de HTTP/3
      L’inquiétude sur une adoption lente de WebTransport aurait pu être formulée de la même manière autrefois pour le transport TLS, HTTP/3 ou XHR. Comme quelques grands moteurs de navigateur dominent le marché, le déploiement de nouvelles fonctionnalités de navigateur et de nouveaux protocoles est relativement simple
      Dire que certains réseaux bloqueront UDP parce que TCP reste possible revient un peu à dire qu’ils continueront aussi à bloquer HTTP/2 et TLS parce que HTTP 1.1 sans TLS reste possible. Ce n’est pas totalement faux, mais au vu de l’adoption massive de HTTP/2 et surtout de TLS, cela ne semble pas être un si gros problème
    • J’entends souvent parler de réseaux qui bloquent UDP, mais je n’en ai jamais vu en pratique. Beaucoup de choses tournent aussi au-dessus d’UDP
      Un petit bureau ou un environnement d’entreprise dystopique digne d’un film pourrait le fermer, mais je ne vois pas bien pourquoi le fait que certains réseaux puissent interdire UDP serait si pertinent. Certains réseaux bloquent aussi google.com ou wikipedia.com, sans que ces services soient pour autant des échecs
    • WebSocketStream arrive bientôt dans Chrome et ajoute la backpressure : https://chromestatus.com/feature/5189728691290112
    • Une meilleure approche que base64 est binary-sse : https://github.com/luciopaiva/binary-sse
    • Dans ce genre de situation, HTTP/2 continuerait de fonctionner, donc les inquiétudes sur le multiplexage diminuent

  • La description de WebRTC dans l’article n’est pas exacte. WebRTC client/serveur est possible sans « serveur de signalisation » séparé : le serveur peut faire la signalisation
    Il faut seulement quelques allers-retours supplémentaires, pas un serveur séparé. Les canaux de données WebRTC fonctionnent assez bien comme alternative à WebSocket ou SSE, surtout quand on veut éviter le blocage HOL. Il existe aussi beaucoup de bibliothèques, comme Pion ou str0m, qui font presque tout le travail
    Dire que l’API WebTransport est complexe me semble aussi exagéré. Si vous n’avez pas besoin des fonctionnalités avancées, vous pouvez les ignorer ; si vous voulez l’utiliser comme WebSocket, il suffit pratiquement d’ouvrir un seul flux bidirectionnel. Pour éviter le blocage HOL, ouvrez un flux par message. C’est un peu plus complexe, mais pas au point de nécessiter absolument une bibliothèque, et GitHub Copilot pourra probablement même écrire le code. Cela dit, WebTransport est encore en phase de maturation, les bibliothèques serveur ne sont pas nombreuses et la prise en charge par Safari est encore attendue

    • Dire que WebRTC client/serveur peut se faire sans « serveur de signalisation » me paraît curieux
      En général, le serveur de signalisation est implémenté avec WebSocket. À moins de proposer un bootstrap décentralisé des clients existants, on ne peut pas l’implémenter avec WebRTC lui-même

  • Si vous développez pour des clients ayant une infrastructure IT traditionnelle « entreprise » et « sécurité », mieux vaut ajouter un bouton d’actualisation et s’arrêter là
    Dans ce type d’environnement, d’après mon expérience, les tentatives de construire des fonctionnalités temps réel pour ces clients échouent régulièrement et deviennent impossibles à corriger à cause de procédures sans fin

    • Jetty/CometD bascule en long polling si les autres modes de transport ne fonctionnent pas
    • Honnêtement, toutes les technologies de cette famille ont leurs propres problèmes, et le bouton d’actualisation ne fait pas exception
    • Le navigateur a bien un bouton d’actualisation, mais il y a de fortes chances que l’application casse si on appuie dessus

  • WebSocket et SSE deviennent un vrai casse-tête à gérer quand on passe à l’échelle. Côté backend en particulier, il faut une observabilité dédiée, et côté frontend le débogage devient un cauchemar si ce n’est pas implémenté avec beaucoup de prudence sur mobile
    Les appareils coupent ou ralentissent le réseau pour économiser la batterie, d’autant plus si l’on ne fait pas explicitement d’I/O via des API dédiées
    Créer une nouvelle connexion est une opération coûteuse, et le serveur doit stocker l’état quelque part. Si cette couche de stockage d’état a un problème, les clients réessaient en boucle, expirent en timeout et restent indéfiniment bloqués sur une opération coûteuse. Ce n’est pas non plus une bonne façon de contrôler facilement le débit tout en chargeant progressivement la base de données
    Côté fiabilité, d’après mon expérience, le long polling a été le plus robuste. Même si un flux événementiel est vraiment important, il vaut mieux une architecture à deux niveaux où le frontend fait du long polling vers un backend de niveau 1, et où ce niveau 1 s’abonne en WebSocket au backend de niveau 2 ; le contrôle de la fiabilité est bien meilleur

    • Tout à fait d’accord. J’ai vu des gens se tirer une balle dans le pied avec WebSocket et SSE. Le long polling a un coût, mais c’est à mon avis l’approche la plus explicable et la plus scalable
    • SSE prend en charge le long polling. On peut faire en sorte que le serveur ferme la connexion quand il le souhaite
      SSE prend en charge la reconnexion automatique et inclut aussi le dernier ID vu, ce qui permet au serveur de reprendre sans interruption
    • Une bonne partie de ces points est abordée dans l’article lié, et rxdb dispose de mécanismes qui atténuent plusieurs de ces inquiétudes

  • Ce n’est pas dans l’article, mais le short polling est aussi pertinent. Ce n’est pas une manière d’envoyer des messages du serveur vers le client, mais cela reste utile quand il n’y a pas d’autre option, par exemple sur de l’hébergement mutualisé
    D’après mon expérience, même avec un intervalle de polling long, par exemple 20 secondes, ça fonctionne assez bien si chaque réponse inclut aussi une liste de messages. Quand l’utilisateur appuie sur un bouton, le client envoie une requête au serveur, et le serveur répond avec les données et la liste des messages les plus récents, ce qui remet le client à jour

    • Cela peut aussi s’appliquer à des données qui changent rapidement. C’est particulièrement vrai si une forte proportion des requêtes de polling contiennent des mises à jour

  • Je ne comprends toujours pas pourquoi WebSocket et SSE ne prennent pas en charge l’envoi de headers comme Authorization dans la requête initiale. Ils laissent toute l’authentification des services temps réel aux implémenteurs
    Il existe peut-être une bonne approche dans la spec, mais j’ai vu tellement de méthodes différentes qu’on peut quasiment dire qu’il n’y en a pas

    • L’API EventSource a beaucoup de lacunes. Je suis mainteneur du polyfill EventSource le plus utilisé, mais j’ai récemment démarré un projet qui réécrit un client EventSource de manière plus moderne : https://github.com/rexxars/eventsource-client
      En plus des headers personnalisés, il prend en charge toutes les méthodes de requête (POST, PATCH, etc.), l’inclusion d’un corps de requête, l’abonnement à des événements nommés et la définition de l’ID initial du dernier événement. Il peut aussi être utilisé comme itérateur asynchrone
      J’aime la simplicité de Server-Sent Events, mais l’API EventSource donne l’impression d’avoir été implémentée à la hâte puis simplement laissée telle quelle
      [1] : https://github.com/eventsource/eventsource
    • La requête initiale ne peut-elle pas envoyer l’ensemble des headers HTTP standards, ainsi que les cookies ?
    • Les cookies sont bien envoyés
    • Il y a aussi les certificats TLS
    • Je l’utilise depuis des années ; est-ce que je rate quelque chose ?

  • C’est peut-être naïf, mais si l’on part du principe qu’on utilise HTTP/2 ou plus, la combinaison d’EventSource et de fetch() pour l’envoi de messages me semble aussi correcte que les autres protocoles qui utilisent une seule connexion TCP. Et HTTP/3 utilise UDP, donc c’est encore mieux
    Cela suppose que la connexion n’a besoin d’être maintenue que lorsque l’onglet est au premier plan. Je serais curieux de savoir quels problèmes sont apparus en essayant réellement cette approche

    • L’une des limites est que SSE est uniquement textuel, donc on ne peut pas envoyer efficacement des données binaires. Il faut un encodage comme base64
    • Il existe une bibliothèque qui fait ce que tu veux
      https://www.npmjs.com/package/@microsoft/fetch-event-source
    • J’ai eu exactement la même réflexion. Avec HTTP/2 et SSE, j’ai l’impression que 99 % du problème est réglé
      Plutôt que de faire quelque chose de complètement différent, je me demandais s’il serait possible de pousser SSE plus loin tout en réduisant encore la latence, l’usage mémoire et les ressources CPU
    • Oui, si le cas d’usage principal est serveur→client

  • Je trouve ce genre d’article assez amusant. À la fin des années 90, j’ai conçu un système d’enchères en ligne, et il n’y avait absolument aucune requête XHR
    Toutes les mises à jour en temps réel étaient gérées avec du server-push/streaming HTTP. À l’époque, gérer toutes les connexions ouvertes n’était pas simple, mais avec une architecture appropriée, on pouvait atteindre une échelle acceptable

    • J’ai passé énormément de temps à expliquer aux gens l’importance du streaming HTTP, et ce n’est clairement pas un combat facile
      Les avantages de HTTP/2 ou HTTP/3 sont excellents, mais il faut aussi savoir ce qu’on peut exploiter avec HTTP 1.1, qui est pratiquement pris en charge partout

  • Le long polling me manque un peu. Comparé aux technologies récentes, c’était vraiment simple. Je le ressens même en pensant que WebRTC est ce qu’il y a de mieux

    • SSE n’est pas vraiment plus complexe que le long polling. La seule différence, c’est que le serveur ne ferme pas la connexion juste après avoir envoyé la réponse
      À la place, il attend de nouvelles données puis envoie une réponse supplémentaire sur le même flux
    • J’aimerais que ce soit aussi simple, mais non
      Le réseau de Second Life utilise du HTTPS en long polling pour des « canaux d’événements », et le serveur envoie des messages d’événements au client via ce canal. La plupart des messages passent par UDP, mais ceux qui nécessitent du chiffrement ou les gros messages passent par le canal d’événements HTTPS/TCP
      Côté client, le client C++ utilise libcurl, dont les paramètres de timeout par défaut ne conviennent pas au long polling. libcurl coupe la connexion et crée une nouvelle requête, ce qui peut entraîner des pertes ou des doublons de messages
      Côté serveur, Apache se place devant le serveur de simulation réel pour filtrer les tentatives de connexion sans rapport, mais Apache a aussi ses propres timeouts, ce qui interrompt la connexion et provoque une nouvelle tentative du client
      Des numéros de séquence de messages sont censés éviter les pertes, mais le serveur Second Life ignore les numéros de séquence que le client renvoie en guise d’accusé de réception. Certains serveurs compatibles d’Open Simulator sautent même des numéros de séquence
      Au final, on obtient un système basé sur HTTPS qui peut perdre ou dupliquer des messages pourtant censés être fiables. Pour certains messages, leur perte bloque l’activité de l’utilisateur dans le jeu
      Les personnes qui ont conçu cela sont parties depuis longtemps, et les employés actuels ne savaient pas à quel point ce désordre était grave. Des utilisateurs externes ont dû identifier et documenter le problème, et les employés de l’entreprise essaient de le corriger depuis des mois. C’est suffisamment difficile à corriger pour qu’il semble désormais que le travail soit repoussé
      Donc le long polling n’est pas « simple au point d’être idiot ». La bonne approche consiste probablement à envoyer des messages keep-alive assez souvent pour que les couches TCP et HTTPS n’expirent pas. Apache et libcurl resteraient ainsi sur un chemin qui fonctionne bien
    • On l’utilise encore souvent. Il existe beaucoup d’applications où il est logique d’accepter le surcoût des requêtes en échange du fait de tout garder dans le contexte d’une API HTTP existante
    • Aujourd’hui encore, on peut utiliser le long polling avec HTTP/2, et il ne va pas disparaître