web udp public
1.0.0
Ce référentiel vise à exprimer le besoin public d'une technologie permettant une communication serveur-client à faible latence , sans fiabilité obligatoire et/ou mécanisme de livraison ordonné du protocole de transport sous-jacent.
Et façonnez les exigences à partir des besoins existants et des applications futures potentielles. Motiver les membres du W3C, la communauté IETF et les fournisseurs de navigateurs à entamer la discussion et à proposer des RFC pour alimenter le développement ultérieur d'une solution.
Les relations publiques et les discussions sur les problèmes sont les bienvenues. Faites passer le message, les RT sont les bienvenus.
Le Web a évolué rapidement au cours des dernières années, améliorant les capacités de mise en réseau grâce à des technologies telles que : WebSockets, WebRTC, HTTP/2, Server-Sent Events, QUIC .
Ces technologies ont leur propre domaine d'application et permettent à la plateforme Web d'avoir :
et bien d'autres expériences riches et puissantes
Ces dernières années, un autre média est né : les jeux HTML5 . Adobe Flash disparaît et l'industrie des jeux HTML5 est en croissance constante.
Ce qui a conduit à la naissance de IO Games, l'un des jeux multijoueurs les plus accessibles du marché. Quelques exemples populaires : agar.io, slither.io et bien d’autres. Ils s'appuient tous sur la seule technologie actuellement viable pour la communication serveur-client en temps réel : les WebSockets. WebRTC pour serveur-client est trop complexe (lire plus loin).
Mais cela limite les capacités du réseau, car TCP pour les jeux a des limites . Il convient de mentionner qu'il ne s'agit pas uniquement de jeux : il existe de nombreux cas d'utilisation de communications serveur-client à faible latence, peu fiables et désordonnées.
Latence et congestion . TCP offre une livraison de paquets fiable et ordonnée et est un protocole basé sur la connexion. La nécessité d'UDP (ou alternative) sur TCP n'est pas remise en question car elle est largement discutée dans de nombreux articles sur les avantages d'UDP (ou alternative) sur TCP dans différents cas. Ici, nous essayons simplement de le résumer. Il convient de mentionner que UDP est l'option de protocole de transport la plus populaire, mais pas la seule, pour cet effort.
Fiabilité - ceci n'est pas toujours souhaité par la logique de l'application, les informations obsolètes peuvent ne plus être pertinentes et peuvent être ignorées. TCP assurera la livraison des paquets, ce qui entraînera des congestions entraînant des pics de latence dus au besoin d'accusés de réception et de relivraison des paquets. UDP (ou alternative) ne garantit pas la fiabilité dès le départ, évitant ainsi les problèmes de congestion qui peuvent être utilisés comme un avantage pour garantir la livraison des données les plus récentes dès que possible.
Livraison ordonnée - TCP utilise le séquençage et les accusés de réception pour garantir la lecture ordonnée et la relivraison des paquets. Cela conduit à un blocage de la lecture, ce qui entraîne des pics de latence et s'aggrave si l'environnement réseau présente une perte de paquets plus élevée.
Protocole qui ne garantit pas la fiabilité et la livraison ordonnée, permettant au développeur de mettre en œuvre n'importe quelle technique par-dessus si nécessaire ou d'utiliser des approches hybrides. Cela fournit des délais de livraison stables et une faible latence dans des environnements réseau loin d’être parfaits. Avec contrôle de la congestion pour atténuer la surcharge de l’infrastructure Internet afin de répondre aux problèmes de sécurité.
L'une des options pour résoudre ce problème consiste à ajouter une nouvelle extension au protocole WebSockets existant à l'aide des mécanismes de négociation décrits dans la RFC 6455. Ce qui implémenterait des fonctionnalités supplémentaires pour établir une communication par protocole UDP (ou alternatif). Cela bénéficierait du modèle de sécurité existant basé sur l'origine des WebSockets et permettrait aux développeurs de suivre une approche progressive dans laquelle ils pourraient recourir à la logique TCP si une telle extension n'est prise en charge par aucune des parties (serveur ou client).
Une autre approche consisterait à développer une toute nouvelle API, très similaire aux WebSockets, qui aborderait les fonctionnalités uniques de la logique réseau UDP (ou alternative), et fournirait potentiellement des fonctionnalités supplémentaires au développeur avec des options précises sur la façon d'envoyer des messages.
L'état actuel de WebRTC est trop complexe et a été conçu principalement pour la communication peer-to-peer. Pour cette raison, ce n'est pas bien adopté pour la communication serveur-client et nécessite beaucoup de ressources de développement. En termes simples, il n’est pas convivial pour le développement Web solo comme le sont les WebSockets aujourd’hui. Option potentielle d'extension de la spécification pour modulariser et simplifier les exigences qui permettraient l'utilisation de certaines parties de WebRTC, le rendant plus accessible pour les scénarios serveur-client et une API simplifiée qui le rendrait plus accessible aux développeurs Web.
Il existe un projet de spécification de l'API WebTransport qui permet aux applications Web d'établir des connexions réseau interactives, bidirectionnelles et multiplexées, avec prise en charge des communications fiables et non fiables.
Une telle implémentation d'API et de protocole sous-jacent doit répondre aux problèmes de sécurité pour la rendre conviviale pour le Web :
L'API doit répondre à ces problèmes de sécurité, sans trop compliquer l'API pour le front-end ainsi que la mise en œuvre pour le back-end. C'est pourquoi UDPSocket n'est pas une option.
Liste des protocoles sous-jacents potentiels pouvant être utilisés pour une implémentation :
