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 協定添加新的擴充功能。這將受益於現有的基於來源的 WebSocket 安全模型，並允許開發人員遵循漸進式方法，如果任何一方（伺服器或客戶端）不支援此類擴展，他們可以回退到 TCP 邏輯。
另一種方法是開發全新的 API，與 WebSocket 非常相似，它將解決 UDP（或替代）網路邏輯的獨特功能，並可能為開發人員提供額外的功能，以及如何發送訊息的細粒度選項。
WebRTC 的當前狀態過於複雜，主要是為點對點通訊而設計的。由於這在伺服器-客戶端通訊中沒有得到很好的採用，並且需要大量的開發人員資源。簡而言之，它不像今天的 WebSocket 那樣對單獨的 Web 開發友好。擴展規範以模組化和簡化要求的潛在選項，允許使用 WebRTC 的某些部分，使其更易於伺服器用戶端場景使用，並簡化 API，使其更易於 Web 開發人員使用。
WebTransport API 的草案規範允許 Web 應用程式建立互動式、雙向、多路復用的網路連接 - 支援可靠且不可靠的通訊。
此類 API 和底層協定實作應解決安全性問題，使其網路友善：
API 應該解決這些安全性問題，而不會讓前端的 API 以及後端的實作過於複雜。這就是為什麼 UDPSocket 不是一個選項。
可用於實現的潛在底層協定清單：
