web udp public
1.0.0
このリポジトリは、基盤となるトランスポート プロトコルの信頼性や順序付けされた配信メカニズムを必須とせずに、サーバーとクライアントの低遅延通信を可能にするテクノロジーに対する一般のニーズを表明することを目的としています。
そして、既存のニーズと潜在的な将来のアプリケーションから要件を形成します。 W3C メンバー、IETF コミュニティ、およびブラウザ ベンダーが議論を開始し、ソリューションのさらなる開発を促進するために RFC を提案するよう促すため。
問題での PR やディスカッションは大歓迎です。拡散、RT大歓迎です。
Web はここ数年で急速に進化し、 WebSocket、WebRTC、HTTP/2、Server-Sent Events、QUICなどのテクノロジーを使用してネットワーク機能を向上させました。
これらのテクノロジーには独自の応用分野があり、Web プラットフォームで次のことが可能になります。
さらに多くの豊かで強力な体験
近年、 HTML5 ゲームという別のメディアが誕生しました。 Adobe Flash は廃止され、HTML5 ゲーム業界は着実に成長しています。
これが、最もアクセスしやすいマルチプレイヤー ゲームの 1 つである IO ゲームの誕生につながりました。よくある例としては、agar.io、slither.io などがあります。これらはすべて、現在サーバーとクライアントのリアルタイム通信に唯一実行可能なテクノロジーである WebSocket に依存しています。サーバー/クライアントの WebRTC は非常に複雑です (さらに読んでください)。
ただし、ゲーム用の TCP には制限があるため、これによりネットワーク機能が制限されます。言及する価値があるのは、これはゲームだけではありません。低遅延で信頼性が低く、順序付けされていないサーバーとクライアントの通信のユースケースは数多くあります。
レイテンシーと輻輳。 TCP は、信頼性が高く順序付けられたパケット配信を備え、接続ベースのプロトコルです。 TCP に対する UDP (または代替) の必要性については、さまざまなケースにおける TCP に対する UDP (または代替) の利点について多くの記事で広く議論されているため、疑問視されていません。ここではそれを要約してみます。 UDP が最も人気がありますが、この取り組みの唯一のトランスポート プロトコル オプションではないことに言及する価値があります。
信頼性- これはアプリケーション ロジックにとって常に望ましいとは限りません。古い情報は関連性がなくなっている可能性があるため、無視できます。 TCP はパケットの配信を保証しますが、これにより輻輳が発生し、パケットの確認応答と再配信が必要になるため、遅延が急増します。 UDP (または代替) は、そのままでは信頼性が保証されないため、輻輳の問題を回避でき、最新のデータができるだけ早く配信されるようにする利点として利用できます。
順序付けされた配信- TCP は順序付けと確認応答を使用して、パケットの順序付けされた読み取りと再配信を保証します。これにより読み取りのブロックが発生し、レイテンシのスパイクが発生し、ネットワーク環境でパケット損失が増加するとさらに悪化します。
信頼性とすぐに使える順序付けされた配信を保証しないプロトコル。開発者は必要に応じてその上に任意の手法を実装したり、ハイブリッド アプローチを使用したりできます。これにより、完璧とは言えないネットワーク環境でも、安定した配信タイミングと低遅延が実現します。インターネット インフラストラクチャの過大な負荷を軽減する輻輳制御により、セキュリティ上の懸念に対処します。
これを解決するオプションの 1 つは、RFC 6455 で説明されているネゴシエーションの仕組みを使用して、既存の WebSocket プロトコルに新しい拡張機能を追加することです。これにより、UDP (または代替) プロトコル通信を確立するための追加機能が実装されます。これにより、WebSocket の既存のオリジンベースのセキュリティ モデルの利点が得られ、開発者は、そのような拡張機能がいずれかの側 (サーバーまたはクライアント) でサポートされない場合に TCP ロジックにフォールバックできる進歩的なアプローチに従うことができます。
もう 1 つのアプローチは、WebSocket に非常によく似た完全に新しい API を開発することです。これは、UDP (または代替) ネットワーキング ロジックの固有の機能に対処するだけでなく、メッセージの送信方法の詳細なオプションを開発者に追加機能を提供する可能性があります。
WebRTC の現状は非常に複雑であり、主にピアツーピア通信用に設計されています。このため、サーバーとクライアントの通信にはあまり採用されず、多くの開発者リソースが必要になります。簡単に言うと、今日の WebSocket のように、単独の Web 開発に適したものではありません。仕様を拡張して要件をモジュール化および簡素化するオプションの可能性。これにより、WebRTC の一部の使用が可能になり、サーバー/クライアントのシナリオで WebRTC を利用しやすくなり、API が簡素化されて Web 開発者が利用しやすくなります。
WebTransport API には、信頼できる通信と信頼できない通信の両方をサポートする対話型の双方向の多重ネットワーク接続を Web アプリケーションが確立できるようにするドラフト仕様があります。
このような API と基礎となるプロトコルの実装は、Web フレンドリーにするためにセキュリティの問題に対処する必要があります。
API は、フロントエンドの API やバックエンドの実装を過度に複雑にすることなく、これらのセキュリティ上の懸念に対処する必要があります。そのため、UDPSocket はオプションではありません。
実装に使用できる潜在的な基礎となるプロトコルのリスト:
