web udp public
1.0.0
This repo is to express public need for a technology to enable server-client low-latency communication, without mandatory reliability and/or ordered delivery mechanics of underlying transport protocol.
And shape the requirements from existing needs and potential future applications. To motivate W3C Members, IETF Community and Browser Vendors to start discussion and propose RFC to fuel further development for a solution.
PR's and discussions in Issues are welcome. Spread the word, RT's are welcome.
Web evolved over past years rapidly, improving networking capabilities using such technologies as: WebSockets, WebRTC, HTTP/2, Server-Sent Events, QUIC.
Those technologies have own area of application and enabled web platform to have:
and many more rich and powerful experiences
In recent years another medium have born: HTML5 Games. Adobe Flash is going away, and HTML5 games industry is steadily growing.
Which lead to birth of IO Games - one of the most accessible multiplayer games out there. Some of popular examples: agar.io, slither.io and many more. They all rely on currently the only viable technology for real-time server-client communication - WebSockets. WebRTC for server-client is overly complex (read further).
But this limits network capabilities as TCP for games has limits. It's worth mentioning that it's not only about the games - there are plenty use cases for low-latency unreliable and unordered server-client communications.
Latency and congestion. TCP has reliable and ordered packet delivery and is connection based protocol. The need of UDP (or alternative) over TCP is not under a question as it is widely discussed in many articles about benefits of UDP (or alternative) over TCP in different cases. Here we trying just to summarize it. Worth mentioning that UDP being the most popular, but not the only transport protocol option for this effort.
Reliability - this is not always desired by application logic, outdated information might not be relevant anymore and can be ignored. TCP will ensure delivery of packets, which leads to congestions that results in latency spikes due to need of acknowledgments and redelivery of packets. UDP (or alternative) does not guarantee reliability out of the box, thus avoids congestion problem which can be used as a benefit to ensure latest data is delivered ASAP.
Ordered Delivery - TCP uses sequencing and acknowledgments to guarantee ordered read and re-delivery of packets. This leads to blocking read, which leads to latency spikes and gets worse if network environment has higher packet loss.
Protocol that does not guarantee reliability and ordered delivery out of the box, allowing developer to implement any of the techniques on top of it if required or use hybrid approaches. This provides stable delivery timings and low latency in less than perfect network environments. With congestion control to mitigate overwhelming the internet infrastructure to address security concern.
One of the option to solve this, is by adding new extension to existing WebSockets protocol using negotiation mechanics described in RFC 6455. Which would implement extra functionality to establish UDP (or alternative) protocol communication. This would benefit from existing origin-based security model of WebSockets and allow developers to follow progressive approach where they can fall-back to TCP logic if such extension is not supported by either side (server or client).
Another approach would be by developing completely new API, very similar to WebSockets that would address unique features of UDP (or alternative) networking logic, as well as potentially provide extra features for developer with fine-grain options of how to send messages.
Current state of WebRTC is overly complex and was designed primarily for peer-to-peer communication. Due to this is not well adopted for server-client communication and requires a lot of developer resources. Simply speaking, it is not solo-web-dev friendly like WebSockets are today. Potential option of extending the spec to modularize and simplify the requirements that would allow use of some parts of WebRTC making it more accessible for server-client scenarios and simplified API that would make it more accessible for web developers.
There's a draft spec of the WebTransport API that allows web applications to establish interactive, bidirectional, multiplexed network connections - with support for both reliable and unreliable communication.
Such API and underlying protocol implementation should address security concerns to make it web friendly:
API should address those security concerns, without overcomplicating the API for front-end as well as implementation for the back-end. That's why UDPSocket is not an option.
List of potential underlying protocols that can be used for an implementation:
