ブラウザを介してUDPパケットを送信できないのはなぜですか？

はじめに

2017年、 agar.ioのような人気のあるWebゲームのほとんどは、TCPでWebSocketを使用してデータを転送します。 ブラウザにWebSocketのUDPアナログが組み込まれている場合、これらのゲームのネットワークでの作業が大幅に改善されます。

入門情報

Webブラウザーの動作は、 HTTPプロトコル （ステートレス要求および応答プロトコル）に基づいています 。 もともと静的なWebページを提供するために設計されました。 HTTPは、信頼性の高い配信とインターネット経由で送信されるデータの正しい順序を保証する低レベルのプロトコルであるTCPの上で実行されます。



これらはすべて長年にわたってうまく機能していましたが、最近ではWebサイトがよりインタラクティブになり、HTTP要求/応答パラダイムへの応答が停止しました。 この問題を解決するために、WebSocket、WebRTC、HTTP 2.0、QUICなどの最新のWebプロトコルが発明されました。これらは、ネットワークの対話性を大幅に改善する可能性があります。



残念ながら、新しい一連のWeb開発標準は、マルチプレイヤーゲームのニーズを満たしていないか、実装するには複雑すぎます。



ブラウザを介してUDPパケットを送受信したいだけなので、これはゲーム開発者にとっては残念です。

問題

Webは、パケット保存プロトコルであるTCPの上に構築されています。 パケット損失の状況で正しい順序で信頼性の高いデータ配信を行うには、TCPは最新のデータをキューに保存し、失われたパケットの再送信を待機する必要があります。 そうでない場合、データは間違った順序で配信されます。



この原則は、キューの開始をブロックすると呼ばれます 。 それは迷惑な開発者とほとんど悲劇的な状況を作り出します。 彼らが必要とする最新のデータは、古いデータの再送信を待っていますが、転送されたデータの受信時には、それらはすでに古くなっていて使い物になりません。



残念ながら、このプロセスはTCPのフレームワーク内で修正することはできません。すべてのデータを確実に正しい順序で受信する必要があります。 したがって、過去20年間のゲーム業界の標準ソリューションは、UDPを介したデータ転送です。



実際には、これは各ゲームがUDPを介して独自のプロトコルを開発し、必要な機能をすべて実装し、順序を維持せずにほとんどのデータを信頼できない方法で送信することを意味しました。 これにより、失われたパケットの再送信を待たずに、可能な限り高速で一時データを配信できます。



しかし、Webゲームの場合は何をする必要がありますか？



今日のWebゲームの主な問題は、ゲーム開発者がゲーム業界が選択したブラウザで最適なソリューションを使用できないことです。 代わりに、WebゲームはTCPを介してゲームデータを送信するため、応答性が低下します。



TCPの使用は完全にオプションであり、WebゲームにUDPパケットを送受信する機会があれば、「指でクリックするだけ」でこの問題を解決できます。

WebSocketとは何ですか？

WebSocketsは、HTTPプロトコルを拡張したもので、HTTP接続を変更して、データを双方向に転送できるようにします。 この場合、標準の要求/応答パターンは使用されません。



この手法により、動的に変化するコンテンツを表示する必要があるWebサイトの問題をエレガントに解決できます。これは、Webソケット接続が確立された後、サーバーが対応するリクエストなしでブラウザーにデータを送信できるためです。



残念ながら、WebSocketはTCPの上に実装されているため、データは依然としてキューの開始をブロックする傾向があります。

QUICとは何ですか？

QUICはUDP上に構築された実験プロトコルであり、HTTPの代替トランスポートレイヤーとして開発されました。 現在、Google Chromeでのみサポートされています。



QUICの最も重要な機能は、複数のデータストリームのサポートです。 クライアントまたはサーバーは、チャネルIDを増やすことで暗黙的に新しいチャネルを作成できます。



チャネルの概念には、2つの大きな利点があります。

1. 新しい要求が作成されるたびに接続の確認要求を送信することを避けます。
2. 無関係なデータストリーム間のキューの先頭のブロックを排除します。

残念ながら、個々のスレッドのキューの先頭をブロックする問題を排除していますが、各スレッド内には依然として存在しています。

WebRTCとは何ですか？

WebRTCは、ストリーミングオーディオやビデオなどのアプリケーションのブラウザ間でピアツーピア接続を提供するプロトコルのセットです。



WebRTCは、「信頼性の低い」モードに設定できるデータチャネルをサポートしているため、順序を維持せずにブラウザを介した信頼性の低いデータ送信が可能です。



では、なぜWebSocketsは現代の2017ブラウザーゲームでまだ使用されているのでしょうか？



その理由は、マルチプレイヤーゲームでは、ピアツーピア転送からクライアントサーバーモデルに移行する傾向があるためです。 WebRTCを使用すると、信頼性のない「不安定な」データをブラウザからブラウザに簡単に送信できますが、ブラウザと専用サーバー間のデータ転送が必要になるとクラッシュします。



この問題は、 WebRTCの極端な複雑さによるものです。 この複雑さの理由は理解できる：WebRTCは主にブラウザー間のピアツーピアデータ交換のために設計されたため、最悪の場合のシナリオでは、NATをバイパスしてパケットを送信するためにSTUN、ICE、およびTURNのサポートが必要です。



しかし、ゲーム開発者の観点から見ると、パブリックIPアドレスを持つ専用サーバーとデータを交換するためにSTUN、ICE、およびTURNは絶対に必要ないため、この複雑さはすべて彼らにとって重荷です。

「WebSocketのUDPバージョンが必要だと感じました。 これが私たちが夢見ていた唯一のことです。」

agar.ioの作成者であるMatheus Valadares

要するに、ゲーム開発者はシンプルさが大好きであり、WebSockets for UDPソリューションはWebRTCの複雑さよりもはるかに魅力的です。

UDPの送信を許可しないのはなぜですか？

この問題の最終的な解決策は、ユーザーがブラウザーを介してUDPパケットを直接送受信できるようにすることです。 もちろん、これは絶対に恐ろしい考えであり、これが決して許されるべきではないという十分な理由があります。

1. Webサイトは、ブラウザからのUDPパケットの大量配信を調整することにより、DDoS攻撃を開始する可能性があります。
2. Webページで実行されているJavaScriptが悪意のあるUDPパケットを作成して企業ネットワークの内部システムをプローブし、HTTPSを介してレポートを送信する可能性があるため、新しいセキュリティホールが存在します。
3. UDPパケットは暗号化されていないため、攻撃者がこれらのパケットで送信されるすべてのデータのスニッフィングと読み取りを整理したり、送信中にデータを変更したりすることは非常に簡単です。 ブラウザーが暗号化されていないパケットを送信できるようにすることは、ネットワークセキュリティの大きな後退です。
4. UDPには認証がありません。そのため、ブラウザから送信されたパケットを読み取る専用サーバーは、それに接続するユーザーの有効性の独自の方法を使用する必要があります。 このような人件費は、ゲーム開発者がこの問題の解決に喜んで投資する努力よりもはるかに高くなります。

そのため、JavaScriptがブラウザでUDPパケットを作成するべきではないことは非常に明確です。

解決策は何ですか？

しかし、もう一方の端から来た場合はどうなりますか？ Webの世界からゲームへの架け橋を作る代わりに、ゲームに必要な技術から始めて、それらをWeb上でうまく機能するソリューションに改良することができます。



私の名前はグレンフィードラーです 。私は過去15年間ゲームを開発しています。 この時間のほとんどは、ネットワークプログラミングを専門としていました。 私はダイナミックアクションゲームでの素晴らしい経験を積んでいます。 私が取り組んだ最後のゲームはTitanfall 2でした。



約1か月間、Hacker News： WebRTC：the future of web gamesでこの記事を読みました。



その中で、 agar.ioの作成者であるMateus Valadaresは、 WebRTCは彼にとって複雑すぎると言い、彼はゲームでWebSocketを使い続けています。



私は思った：確かにWebRTCよりも簡単な解決策があるはずですか？



私はそのような解決策がどのように見えるかと思っていましたか？



私の意見では、ソリューションには次のプロパティが必要です。

1. 接続を確立して 、DDoS攻撃で使用したり、セキュリティホールを検索したりできないようにする必要があります。
2. 暗号化 。2017年には、ゲームやアプリケーションが暗号化されていないパケットを送信してはならないためです。
3. 認証 。専用サーバーは、バックエンドで承認されたクライアントからの接続のみを受け入れる必要があるためです。

私のソリューションを紹介したいと思います。 私はそれがブラウザの標準として完全に受け入れられるという幻想に惑わされていません。私はウェブプログラマではなく、ゲームを書いています。 しかし、少なくともブラウザメーカーとWeb開発者が、クライアントサーバーゲームが本当に必要とするものを理解するのに役立つことを願っています。 私が提案したソリューションは、ゲームとWebの橋渡しを少なくとも部分的に支援するのに役立ちます。



その結果、近い将来、より優れたマルチユーザーブラウザーゲームが提供されることを願っています。

netcode.io

私が来た解決策はnetcode.ioです



netcode.ioは、クライアントが専用サーバーに安全に接続し、UDPを介してデータを交換できるようにするシンプルなネットワークプロトコルです。 接続指向であり、パケットを暗号化および署名し、認証サポートも提供するため、許可されたクライアントのみが専用サーバーに接続できます。



agar.ioなどのゲーム用に設計されており、メインWebサイトから専用サーバーインスタンスにプレイヤーをポストする必要があります。 各サーバーには、プレーヤーの最大数に制限があります（基本実装では、サーバーインスタンスごとに最大256プレーヤー）。



基本的な考え方は、Webバックエンドが認証を実行することです。 プレーヤーがプレイしたい場合、バックエンドはREST呼び出しを行って接続トークンを取得します。接続トークンは、UDP接続確認要求の一部として専用サーバーに送信されます。



接続トークンの有効期間は短く、Webバックエンドと専用サーバーインスタンス間の共有秘密キーに依存しています。 このアプローチの利点は、許可されたユーザーのみが専用サーバーに接続できることです。



netcode.ioは、WebRTCよりも簡単に優れています。 専用サーバーを使用するスキームのみを使用するため、ICE、STUN、およびTURNは不要です。 libsodiumによる暗号化、署名、認証の実装により、同じレベルのセキュリティを提供しながら、DTLSの完全な実装の複雑さを回避します。



過去1か月にわたって、C で netcode.ioの基本的な実装を作成しました。これは、3ポイントBSDライセンスの下でリリースされています。 数か月以内に、この実装を改善し、仕様を書き、他の開発者と協力してnetcode.ioをさまざまな言語に移植したいと考えています。

仕組み

クライアントは、標準の認証手法（たとえば、OAuthを使用）を使用してWebバックエンドにログインします。 クライアントを承認した後、彼はゲームを開始するリクエストを送信し、REST呼び出しを行います。 REST呼び出しは、HTTPSを介してクライアントにbase64エンコード接続トークンを返します。



接続トークンは2つの部分で構成されます。

1. libsodiumのAEADプリミティブを使用して、共有秘密キーで暗号化および署名されたプライベート部分。 クライアントで考慮、変更、または偽造することはできません。
2. クライアントが接続するために必要な情報を提供する公開部分。 たとえば、UDADパケットの暗号化キー、接続可能なサーバーアドレスのリスト、およびAEADの「関連データ」部分に関連するその他の情報。

クライアントは接続トークンを読み取り、接続可能なN個のIPアドレスのリストを持っています。 Nは1に等しくなる可能性があるため、クライアントが接続するまでに最初のサーバーがすでにいっぱいになっている場合は、いくつかのサーバーのアドレスをクライアントに渡すのが最善です。



専用サーバーに接続するとき、クライアントは定期的に接続要求パケットをUDP経由で送信します。 このパッケージには、接続トークンのプライベートデータと、AEADの追加データ（netcode.ioのバージョン情報、プロトコル識別子（特定の各ゲームに固有の64ビット番号）、接続トークンの有効期限のタイムスタンプ、AEADプリミティブシリアル番号）が含まれます。



専用サーバーがUDP経由で接続要求を受信すると、まずAEADプリミティブを使用してパケットコンテンツの有効性を検証します。 接続要求パケット内のパブリックデータが変更されている場合、署名チェックはエラーを生成します。 これにより、顧客は接続トークンの有効性のタイムスタンプを変更できなくなり、期限切れのトークンをすばやく拒否することもできます。



接続トークンが有効な場合、復号化されます。 内部には、有効な専用サーバーのアドレスのリストが含まれています。 これにより、悪意のあるクライアントが単一のトークンを使用して利用可能なすべてのサーバーに接続することを防ぎます。



サーバーは、 HMACトークンの簡単な履歴を検索することにより、接続トークンが既に使用されているかどうかも確認します。 一致が見つかった場合、接続要求は無視されます。 このため、1つのトークンを使用して複数のクライアントを接続することはできません。



さらに、サーバーでは、常に1つのクライアントのみが1つのIPアドレスとポートに接続できます。 また、一意のクライアントIDを使用して、一度にサーバーに接続できるクライアントは1つだけです。 クライアントIDは、Webバックエンドによって承認されたクライアントを一意に識別する64ビット整数です。



接続トークンの有効期限が切れていない場合、復号化されます。 専用サーバーのパブリックIPアドレスがサーバーアドレスのリストにあり、他のすべてのチェックが成功した場合、専用サーバーはクライアントIPアドレスと接続トークンのプライベートデータに含まれる暗号化キーの間の通信を確立します。



これ以降、クライアントとサーバー間で送信されるすべてのパケットはこれらのキーで暗号化されます。 UDPパケットが短時間（たとえば5秒）アドレスから受信されない場合、アドレスと暗号化キーのリンクは無効になります。



サーバーは、サーバー上にクライアント用のスペースがあるかどうかを確認します。 各サーバーは、特定の最大数のクライアントをサポートします。 たとえば、64プレーヤーのゲームでは、クライアントを接続するための64の場所があります。 サーバーがいっぱいの場合、 接続要求に失敗パケットで応答します。 これにより、顧客は、サーバーがいっぱいであり、リスト内の次のサーバーに移動する必要があることをすばやく見つけることができます。



サーバーにクライアント用の場所がある場合、サーバーはこの場所をすぐに提供しません。 代わりに、クライアント接続トークンの+ HMACアドレスを潜在的なクライアントとして保存します 。 サーバーは、 呼び出しトークンを含む接続呼び出しパケットで応答し ます 。 呼び出しトークンは、ランダムキーで暗号化されたデータのブロックです。 サーバーの起動時にキーが発行されます。



キーのランダム化により、同じ序数で複数のサーバーを呼び出すためのトークンを暗号化する際に発生するセキュリティ上の問題がなくなります（サーバーは相互に調整されません）。 さらに、接続コールパケットは接続要求パケットよりもはるかに小さいため、ゲインタイプのDDoS攻撃にプロトコルを使用する必要がありません。



クライアントはUDP 経由で接続呼び出しパケットを受信し、サーバーに接続応答パケットを送信する状態に切り替えます。 接続応答パケットは、 コールトークンを専用サーバーに単に転送し、クライアントが実際にパケットが送信された送信元IPアドレスへのパケットを受信できることを確認します。 これにより、パッケージの送信元アドレスのなりすましが回避されます。



サーバーは、接続応答パケットを受信すると 、待機中のクライアントに関する対応するレコードを検索し、存在する場合は、クライアントを接続する場所を再度検索します。 空いている席がない場合、接続要求の拒否パケットで応答します。これは、接続要求が最初に受信された時点で空きだった場所がすでに使用されているためです。



それ以外の場合、サーバーはサーバー上のクライアントの空きスペースを割り当て、サーバー上のスペースが割り当てられたことをクライアントに通知する接続サポートパッケージで応答します。 このような場所は、顧客インデックスと呼ばれます 。 マルチプレイヤーゲームでは、通常、サーバーに接続されているクライアントを識別するために使用されます。 たとえば、4人用ゲームの顧客0、1、2、3は、プレーヤー1、2、3、および4に対応します。



現在、サーバーは、クライアントが接続されており、 ペイロードパケットを送信できると見なします。 これらのパッケージには、ゲーム関連のデータが含まれています。 パッケージは注文なしで配送されます。 この方法の唯一の欠点は、クライアントがクライアントインデックスを受信して​​完全に接続されていることを確認する前に、最初に接続サポートパッケージを受信する必要があるため、サーバーが各クライアントの場所を確認してクライアントが検証されるかどうかを監視することです。



各クライアントの確認フラグは最初はfalseで、サーバーがクライアントから接続サポートパケットまたはペイロードパケットを受信するとtrueになります。 クライアントが確認されるまで、ペイロードパケットが送信されるたびに、接続サポートパケットが事前にこのクライアントに送信されます。 これにより、クライアントがインデックスを認識し、最初のペイロードパケットを受信するまで完全に接続される統計的確率が確保され、接続セットアップサイクルの数が最小限に抑えられます。



クライアントとサーバーが完全に接続された後、両方向でUDPパケットを交換できます。 通常、ゲームプロトコルは、プレーヤーが入力した情報をクライアントからサーバーに高速で（たとえば、1秒間に60回）送信します。サーバーからクライアントへの世界の状態は、やや頻度が低くなります（たとえば、1秒間に20回）。 ただし、最新のAAAゲームでは、サーバーデータの更新速度が向上しています。



サーバーまたはクライアントが安定したパケットストリームを送信しない場合、接続サポートパケットが自動的に生成されるため、接続がタイムアウトによって中断することはありません。 短い期間（たとえば5秒）、両側からパケットが受信されなかった場合、接続はタイムアウトします。



どちらかの側が明示的に切断する場合、部分的な損失の場合でもパケットを受信する高い統計的確率を確保するために、接続を完了するために過剰な数のパケットが送信されます。 これにより、相手側がタイムアウトを待たずに接続をすばやく完了できます。

おわりに

agar.ioのような一般的なWebゲームでは、専用のWebRTCサーバーを備えたクライアント/サーバー構造のコンテキストでは使用が難しいため、データはTCPを介してWebSocketsを介して転送されます。



Googleの1つのソリューションは、ゲーム開発者がWebRTCデータフィードサポートを専用サーバーに簡単に統合できるようにすることです。



または、「WebSockets for UDP」のようなはるかに単純なソリューションを使用するnetcode.ioを使用できます。 標準化してブラウザに埋め込むと、問題も解決できます。

---

グレンフィードラーはThe Network Protocol Companyの創立者および社長です。 ゲームのネットワーク部分を設定するためのサービスを提供します。 Glennは設立前はRespawn Entertainmentのリードプログラマーであり、Titanfall 1および2に取り組んでいました。



Glennは、ゲームのネットワークデータ転送と物理学に関するgafferongames.comの人気記事の著者でもあります。 フィドラーは、オープンソースネットワークライブラリlibyojimboおよびnetcode.ioを作成しました。