web udp public
1.0.0
该存储库旨在表达公众对一种技术的需求，该技术可以实现服务器-客户端低延迟通信，而无需底层传输协议的强制可靠性和/或有序交付机制。
并根据现有需求和潜在的未来应用来制定要求。为了激励 W3C 成员、IETF 社区和浏览器供应商开始讨论并提出 RFC，以推动解决方案的进一步开发。
欢迎 PR 和问题中的讨论。请转发，欢迎转发。
Web 在过去几年中发展迅速，使用以下技术改进了网络功能： WebSockets、WebRTC、HTTP/2、服务器发送事件、QUIC 。
这些技术有自己的应用领域，并使网络平台具有：
以及更多丰富而强大的体验
近年来另一种媒介诞生： HTML5游戏。 Adobe Flash 正在消失，HTML5 游戏行业正在稳步增长。
这导致了 IO Games 的诞生——这是最容易上手的多人游戏之一。一些流行的例子：agar.io、slither.io 等等。它们都依赖于当前唯一可行的实时服务器-客户端通信技术 - WebSockets。服务器-客户端的 WebRTC 过于复杂（进一步阅读）。
但这限制了网络功能，因为游戏的 TCP 也有限制。值得一提的是，这不仅与游戏有关，还有大量低延迟、不可靠和无序服务器-客户端通信的用例。
延迟和拥塞。 TCP 具有可靠且有序的数据包传输，并且是基于连接的协议。相对于 TCP 的 UDP（或替代方案）的需求不存在问题，因为许多文章都广泛讨论了 UDP（或替代方案）在不同情况下相对于 TCP 的优势。这里我们只是尝试总结一下。值得一提的是，UDP 是最流行的，但不是唯一的传输协议选项。
可靠性- 应用程序逻辑并不总是需要这一点，过时的信息可能不再相关并且可以被忽略。 TCP 将确保数据包的传送，这会导致拥塞，从而由于需要确认和重新传送数据包而导致延迟峰值。 UDP（或替代方案）不保证开箱即用的可靠性，因此可以避免拥塞问题，这可以用来确保尽快传送最新数据。
有序传送- TCP 使用排序和确认来保证数据包的有序读取和重新传送。这会导致阻塞读取，从而导致延迟峰值，如果网络环境丢包率较高，情况会变得更糟。
协议不保证可靠性和开箱即用的有序交付，允许开发人员在需要时在其之上实施任何技术或使用混合方法。这可以在不太完美的网络环境中提供稳定的传输时间和低延迟。通过拥塞控制来缓解互联网基础设施不堪重负的情况，从而解决安全问题。
解决此问题的选项之一是使用 RFC 6455 中描述的协商机制向现有 WebSockets 协议添加新的扩展。这将实现额外的功能来建立 UDP（或替代）协议通信。这将受益于现有的基于源的 WebSocket 安全模型，并允许开发人员遵循渐进式方法，如果任何一方（服务器或客户端）不支持此类扩展，他们可以回退到 TCP 逻辑。
另一种方法是开发全新的 API，与 WebSocket 非常相似，它将解决 UDP（或替代）网络逻辑的独特功能，并可能为开发人员提供额外的功能，以及如何发送消息的细粒度选项。
WebRTC 的当前状态过于复杂，主要是为点对点通信而设计的。由于这在服务器-客户端通信中没有得到很好的采用，并且需要大量的开发人员资源。简而言之，它不像今天的 WebSocket 那样对单独的 Web 开发友好。扩展规范以模块化和简化要求的潜在选项，允许使用 WebRTC 的某些部分，使其更易于服务器客户端场景使用，并简化 API，使其更易于 Web 开发人员使用。
WebTransport API 的草案规范允许 Web 应用程序建立交互式、双向、多路复用的网络连接 - 支持可靠和不可靠的通信。
此类 API 和底层协议实现应解决安全问题，使其网络友好：
API 应该解决这些安全问题，而不会使前端的 API 以及后端的实现过于复杂。这就是为什么 UDPSocket 不是一个选项。
可用于实现的潜在底层协议列表：
