web udp public
1.0.0
Dieses Repo soll den öffentlichen Bedarf an einer Technologie zum Ausdruck bringen, die eine Server-Client-Kommunikation mit geringer Latenz ermöglicht, ohne zwingende Zuverlässigkeit und/oder geordnete Bereitstellungsmechanismen des zugrunde liegenden Transportprotokolls.
Und formen Sie die Anforderungen aus bestehenden Bedürfnissen und potenziellen zukünftigen Anwendungen. Um W3C-Mitglieder, die IETF-Community und Browser-Anbieter zu motivieren, eine Diskussion zu beginnen und RFC vorzuschlagen, um die weitere Entwicklung einer Lösung voranzutreiben.
PRs und Diskussionen in Issues sind willkommen. Verbreiten Sie es weiter, RTs sind willkommen.
Das Web hat sich in den letzten Jahren rasant weiterentwickelt und die Netzwerkfähigkeiten mithilfe von Technologien wie WebSockets, WebRTC, HTTP/2, vom Server gesendeten Ereignissen und QUIC verbessert.
Diese Technologien haben einen eigenen Anwendungsbereich und eine ermöglichte Webplattform, die Folgendes bietet:
und viele weitere reichhaltige und kraftvolle Erfahrungen
In den letzten Jahren ist ein weiteres Medium entstanden: HTML5-Spiele . Adobe Flash wird eingestellt und die HTML5-Spielebranche wächst stetig.
Dies führte zur Geburt von IO Games – einem der zugänglichsten Multiplayer-Spiele auf dem Markt. Einige beliebte Beispiele: agar.io, slither.io und viele mehr. Sie alle setzen auf die derzeit einzig brauchbare Technologie für Echtzeit-Server-Client-Kommunikation – WebSockets. WebRTC für Server-Client ist zu komplex (weiterlesen).
Dies schränkt jedoch die Netzwerkfähigkeiten ein, da TCP für Spiele Grenzen hat . Es ist erwähnenswert, dass es nicht nur um die Spiele geht – es gibt zahlreiche Anwendungsfälle für unzuverlässige und ungeordnete Server-Client-Kommunikation mit geringer Latenz.
Latenz und Überlastung . TCP verfügt über eine zuverlässige und geordnete Paketzustellung und ist ein verbindungsbasiertes Protokoll. Die Notwendigkeit von UDP (oder einer Alternative) gegenüber TCP steht außer Frage, da in vielen Artikeln ausführlich über die Vorteile von UDP (oder einer Alternative) gegenüber TCP in verschiedenen Fällen diskutiert wird. Hier versuchen wir es einfach zusammenzufassen. Erwähnenswert ist, dass UDP die beliebteste, aber nicht die einzige Transportprotokolloption für diesen Zweck ist.
Zuverlässigkeit – dies wird von der Anwendungslogik nicht immer gewünscht, veraltete Informationen sind möglicherweise nicht mehr relevant und können ignoriert werden. TCP stellt die Zustellung von Paketen sicher, was zu Überlastungen und Latenzspitzen aufgrund der Notwendigkeit von Bestätigungen und erneuter Zustellung von Paketen führt. UDP (oder eine Alternative) garantiert keine standardmäßige Zuverlässigkeit und vermeidet so Überlastungsprobleme, die als Vorteil genutzt werden können, um sicherzustellen, dass die neuesten Daten so schnell wie möglich bereitgestellt werden.
Geordnete Zustellung – TCP verwendet Sequenzierung und Bestätigungen, um das geordnete Lesen und erneute Zustellen von Paketen zu gewährleisten. Dies führt zu blockierten Lesevorgängen, was zu Latenzspitzen führt und sich verschlimmert, wenn die Netzwerkumgebung einen höheren Paketverlust aufweist.
Protokoll, das keine Zuverlässigkeit und geordnete Lieferung sofort garantiert, sodass Entwickler bei Bedarf jede der darauf basierenden Techniken implementieren oder hybride Ansätze verwenden können. Dies sorgt für stabile Übermittlungszeiten und geringe Latenz in nicht perfekten Netzwerkumgebungen. Mit Überlastungskontrolle zur Minderung der Überlastung der Internet-Infrastruktur und zur Bewältigung von Sicherheitsbedenken.
Eine Möglichkeit, dieses Problem zu lösen, besteht darin, mithilfe der in RFC 6455 beschriebenen Aushandlungsmechanismen eine neue Erweiterung zum bestehenden WebSockets-Protokoll hinzuzufügen. Dadurch würden zusätzliche Funktionen zum Aufbau der UDP-Protokollkommunikation (oder eines alternativen Protokolls) implementiert. Dies würde vom bestehenden ursprungsbasierten Sicherheitsmodell von WebSockets profitieren und es Entwicklern ermöglichen, einen progressiven Ansatz zu verfolgen, bei dem sie auf die TCP-Logik zurückgreifen können, wenn eine solche Erweiterung von keiner Seite (Server oder Client) unterstützt wird.
Ein anderer Ansatz wäre die Entwicklung einer völlig neuen API, die WebSockets sehr ähnlich ist und einzigartige Funktionen der UDP-Netzwerklogik (oder einer alternativen Netzwerklogik) berücksichtigt und möglicherweise zusätzliche Funktionen für Entwickler mit fein abgestimmten Optionen zum Senden von Nachrichten bereitstellt.
Der aktuelle Stand von WebRTC ist übermäßig komplex und wurde hauptsächlich für die Peer-to-Peer-Kommunikation entwickelt. Aus diesem Grund eignet es sich nicht gut für die Server-Client-Kommunikation und erfordert viele Entwicklerressourcen. Einfach ausgedrückt ist es nicht so für Solo-Webentwickler geeignet wie WebSockets heute. Potenzielle Option zur Erweiterung der Spezifikation, um die Anforderungen zu modularisieren und zu vereinfachen, was die Verwendung einiger Teile von WebRTC ermöglichen würde, um es für Server-Client-Szenarien zugänglicher zu machen, und eine vereinfachte API, die es für Webentwickler zugänglicher machen würde.
Es gibt einen Spezifikationsentwurf der WebTransport-API, der es Webanwendungen ermöglicht, interaktive, bidirektionale, gemultiplexte Netzwerkverbindungen herzustellen – mit Unterstützung sowohl für zuverlässige als auch für unzuverlässige Kommunikation.
Eine solche API- und zugrunde liegende Protokollimplementierung sollte Sicherheitsbedenken berücksichtigen, um sie webfreundlich zu machen:
Die API sollte diese Sicherheitsbedenken berücksichtigen, ohne die API für das Front-End und die Implementierung für das Back-End übermäßig zu komplizieren. Deshalb ist UDPSocket keine Option.
Liste potenzieller zugrunde liegender Protokolle, die für eine Implementierung verwendet werden können:
