HTML5 WebSocketは現在、TCP通信の形式を使用しています。ただし、リアルタイムゲームの場合、TCPはそれをカットしません（ネイティブなどの他のプラットフォームを使用する大きな理由です）。プロジェクトを続行するにはおそらくUDPが必要なので、HTML6の仕様またはUDPをサポートするものがあるかどうかを知りたいですか？
また、WSプロトコルを低レベルの直接ソケットプロトコルと比較するWebSocketの信頼できるベンチマークはありますか？
質問する
52959 次
5 に答える
216
LANでは、200マイクロ秒のWebSocketを介したメッセージのラウンドトリップ時間を取得できます（ブラウザーJSからWebSocketサーバーへ、およびその逆）。これは、生のICMPpingと同様です。MANでは、約10ミリ秒、WAN（同じ国のサーバーへの住宅用ADSL経由）は約30ミリ秒、以下同様に3.5G経由で最大約120〜200ミリ秒です。重要なのは、WebSocketは、ネットワークに基づいて、とにかく取得するレイテンシーに実質的にレイテンシーを追加しないということです。
WebSocketのワイヤーレベルのオーバーヘッド（生のTCPと比較して）は、メッセージごとに2オクテット（長さ<126オクテットのマスクされていないペイロード）から14オクテット（長さ> 64kのマスクされたペイロード）の間です（前者の数値は、メッセージが複数に断片化されていないことを前提としています） WebSocketフレーム）。とても低い。
WebSocketのワイヤーレベルのオーバーヘッドの詳細な分析については、このブログ投稿を参照してください。これには、WebSocket以外のレイヤーをカバーする分析も含まれます。
さらに言えば、ストリーミング処理が可能なWebSocket実装を使用すると、（最初のWebSocketハンドシェイクの後で）各方向に単一のWebSocketメッセージとフレームを開始し、オーバーヘッドなしで最大2^63オクテットを送信できます。基本的に、これはWebSocketを生のTCPの派手な前奏曲にします。警告：仲介者は、独自の決定でトラフィックを断片化する可能性があります。ただし、WSS（つまり、安全なWS = TLS）を実行している場合、仲介者は干渉できず、HTTP互換のプレリュード（WSハンドシェイク）を備えた生のTCPがあります。
WebRTCはメディアトランスポートにRTP（= UDPベース）を使用しますが、さらにシグナリングチャネル（WebSocketなど）が必要です。RTPは、損失に強いリアルタイムのメディア転送用に最適化されています。「リアルタイムゲーム」とは、多くの場合、メディアではなく、プレーヤーの位置などを転送することを意味します。WebSocketはそのために機能します。
注：WebRTCトランスポートは、RTPを介して実行することも、SRTPを介して保護することもできます。こちらの「RTPプロファイル」をご覧ください。
于 2012-10-24T07:26:34.910 に答える
51
ローカルの有線ネットワークでWebSocketを使用してゲームを開発し、利用可能になったらWebRTC DataChannelAPIに移行することをお勧めします。@oberstetが正しく指摘しているように、WebSocketの平均レイテンシーは、特にローカルネットワークでは、基本的に生のTCPまたはUDPと同等であるため、開発フェーズでは問題ないはずです。WebRTCデータチャネルAPIは、WebSocketと非常によく似ているように設計されているため（接続が確立されると）、広く利用可能になったら統合するのはかなり簡単です。
あなたの質問は、UDPがおそらく低遅延ゲームに必要なものであり、それには真実があることを示唆しています。ゲームを書いているので、これはすでに知っているかもしれませんが、そうでない人のために、リアルタイムゲームのTCPとUDPの簡単な入門書を次に示します。
TCPは順調で信頼性の高いトランスポートメカニズムであり、UDPはベストエフォートです。TCPは、送信されたすべてのデータを送信された順序で配信します。UDPパケットは、到着時に送信され、順序が狂っており、ギャップがある可能性があります（輻輳したネットワークでは、UDPパケットはTCPパケットの前にドロップされます）。TCPは大きな改善のように聞こえます。これはほとんどの種類のネットワークトラフィックに当てはまりますが、これらの機能にはコストがかかります。パケットが遅延またはドロップすると、後続のすべてのパケットも遅延します（順序どおりの配信を保証するため）。
リアルタイムゲームは通常、TCPソケットから発生する可能性のあるタイプの遅延を許容できないため、ほとんどのゲームトラフィックにUDPを使用し、ドロップされたデータと順序が正しくないデータを処理するメカニズムを備えています（たとえば、シーケンス番号をペイロードデータ）。数ミリ秒後に別の位置の更新を受け取るため（おそらく気付かないため）、敵のプレーヤーの1つの位置の更新を見逃しても、それほど大したことではありません。しかし、500ミリ秒の間位置の更新を取得せず、その後突然それらをすべて1回取得すると、ひどいゲームプレイになります。
とはいえ、ローカルの有線ネットワークでは、パケットが遅延したりドロップされたりすることはほとんどないため、TCPは初期の開発ターゲットとしては完全に問題ありません。WebRTCデータチャネルAPIが利用可能になったら、それに移行することを検討してください。現在の提案には、再試行またはタイマーに基づいて構成可能な信頼性があります。
ここにいくつかの参考文献があります：
于 2012-10-24T14:52:56.797 に答える
21
簡単に言うと、マルチプレイヤーゲームにTCPを使用する場合は、アダプティブストリーミング技術と呼ばれる手法を使用する必要があります。つまり、クライアント間でゲームの世界を同期するために送信されるリアルタイムデータの量が、各クライアントで現在利用可能な帯域幅と遅延によって管理されていることを確認する必要があります。
動的スロットリング、コンフレーション、デルタ配信、およびその他のメカニズムは適応型ストリーミング技術であり、TCPを魔法のようにUDPほど効率的にすることはありませんが、いくつかのタイプのゲームで十分に使用できるようにします。
私はこれらのテクニックを記事で説明しようとしました：Webを介したマルチプレイヤー3Dゲーム同期の最適化（http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html）。
また、先月サンフランシスコで開催されたHTML5 Developer Conferenceで、このトピックについて講演しました。ビデオはYouTubeで利用可能になりました：http ：//www.youtube.com/watch？v = cSEx3mhsoHg
于 2013-11-21T18:07:50.203 に答える
6
WebsocketのUDPサポートはありません（実際にはサポートされているはずです）が、UDPのような通信にはWebRTCのRTCDataChannelAPIを使用できるようです。ここに良い記事があります：
http://www.html5rocks.com/en/tutorials/webrtc/datachannels/
RTCDataChannelは、実際には、構成可能な信頼性と注文された配信を備えたSCTPを使用します。メッセージを順序なしで配信するように指示し、再送信の最大数を0に設定することで、UDPのように動作させることができます。
私はこれを試したことがありません。
于 2014-04-06T11:27:36.337 に答える
2
HTML6またはUDPをサポートするものの仕様を知りたいですか？
WebSocketはそうしません。WebSocketの利点の1つは、既存のHTTP接続を便乗させることです。これは、プロキシとファイアウォールにとって、WebSocketはHTTPのように見えるため、ブロックされないことを意味します。
セキュリティ上の懸念から、任意のUDP接続がWeb仕様の一部になることはない可能性があります。あなたが求めているものに最も近いものは、おそらくWebRTCの一部として提供され、それに関連するJSEPプロトコルです。
信頼できるベンチマークはありますか...WSプロトコルを低レベルの直接ソケットプロトコルと比較しますか？
私が知っていることではありません。手足に出て、WebSocketが遅くなると予測します;）
于 2012-10-24T00:51:30.437 に答える