ゲーム開発者向けのネットワークプログラミング。 パート1：UDPと TCP

翻訳者から：これは、 ゲームプログラマ向けのネットワーキングシリーズの最初の記事の翻訳です。 私は一連の記事全体が本当に好きで、それに加えて私は常に翻訳者として自分自身を試してみたかったです。 おそらく、この記事は経験豊富な開発者にはあまりにも明白に思えるかもしれませんが、私の意見では、どのような場合でも役立つでしょう。

---

こんにちは、私の名前はグレンフィードラーです。私のオンラインブック、ゲーム開発者向けのネットワークプログラミングの最初の記事であなたを歓迎します。









この記事では、ネットワークプログラミングの最も基本的な側面（ネットワークを介したデータの送受信）から始めます。 データの受信と送信は、ネットワークプログラマーが関与するタスクの全範囲の主要かつ最も単純な部分ですが、多くの場合、どちらの方法が適切かを判断することは困難です。 この部分に十分な注意を払ってください-まだ誤解がある場合、これは将来のマルチプレイヤーゲームに恐ろしい結果をもたらす可能性があります！



おそらくソケットについて何か聞いたことがあるでしょう。そして、それらが2つの主なタイプ-TCPとUDPに分かれていることをおそらく知っているでしょう。 マルチプレイヤーゲームを開発する際に最初に決めることは、使用するソケットのタイプ（TCP、UDP、またはその両方）です。



ソケットタイプの選択は、開発中のゲームのジャンルに完全に依存します。 このシリーズの記事では、Halo、Battlefield 1942、Quake、Unreal、CounterStrike、Team Fortressなどのアクションスタイルのゲームを書いていると仮定します。



次に、各タイプのソケットのプロパティ（アクションスタイルのゲームを開発しているという事実を考慮して）をより詳細に調べ、インターネットの詳細を少し詳しく見ていきます。 詳細なレビューの後、正しいオプションが明らかになります！



TCPは「伝送制御プロトコル」の略で、IPは「インターネットプロトコル」の略です。 これらはともに、Webの閲覧からIRCや電子メールとの通信にいたるまで、Webで行うほとんどすべての基礎となるもので、すべてTCP / IPに基づいています。



TCPソケットを使用したことがある場合、TCPは信頼できる接続の原則を使用するプロトコルであることを知っておく必要があります。 これは、2台のコンピューター間の接続を確立し、そのコンピューター間でデータを送信することを意味します。まるで1台のコンピューター上のファイルに情報を書き込み、もう1台のコンピューターで同じファイルから情報を読み取る場合と同じです。



この場合、接続は信頼性が高く一貫性があると見なされます。つまり、送信するすべての情報は、送信されたのと同じ順序で受信者に到達することが保証されている必要があります。 また、TCP接続はデータの連続ストリームと見なすことができます。プロトコル自体がデータをパケットに分割し、ネットワーク経由で送信します。



もう一度-すべてがファイルの書き込みまたは読み取りと同じくらい簡単です。 小学生、ワトソン！



しかし、このような扱いやすさは、実際には「ボンネットの下」で行われるものとはまったく異なり、より低いレベル（IPプロトコルのレベル）で行われます。



このレベルでは接続の概念はありません。代わりに、個々のパケットが1つのコンピューターから別のコンピューターに転送されます。 このプロセスは、人でいっぱいの部屋で、ある人から別の人にメモを転送することであると想像できます。最終的に、メモは必要な人に届きますが、同時に多くの手を通り抜けました。



ただし、メモが宛先に届くという保証はありません。 送信者は単に到着することを期待してメモを送信しますが、受信者が書き戻すことを決定するまで、メッセージが到着したかどうかさえ知りません。

当然、実際には、送信側のコンピューターはパケットを送信するネットワーク上のコンピューターの正確なシーケンスを認識していないため、できるだけ早く取得できるため、すべてが少し複雑になります。 IPが同じパケットの複数のコピーを送信する場合がありますが、コピーは異なる方法で宛先に送られる可能性があり、ほとんどの場合、異なる時間に到着します。



これは、インターネットが自己組織化および自己修復システムであり、ネットワーク内の問題領域をバイパスできるためです。 実際、ネットワーク上でこのような低いレベルで何が起こるかは本当にクールです。 これについては、すでに古典的な本「TCP / IP Illustrated」で詳しく読むことができます。



しかし、ファイルの読み取り/書き込みのスタイルではなく、個別のパケットを直接送受信するコンピューター間で情報を送信する場合はどうでしょうか？



さて、UDPを使用してこれを行うことができます。 UDPは「ユーザーデータグラムプロトコル」の略で、IP（TCPなど）上で動作しますが、多数の機能を追加する代わりに、IPの単なるアドオンです。



UDPを使用して、特定のIPアドレス（112.140.20.10など）とポート（52423など）にパケットを送信できます。送信先に到達する（または途中で失われる）まで、コンピューターからコンピューターに送信されます。



同時に、受信側では、特定のポート（この場合は52423）をリッスンして待機し、誰かからパケットが来ると（接続が使用されていないことを思い出してください）、アドレスと通知を受け取ります送信側コンピューターのポート、パケットサイズ、その後、このパケットからデータを読み取ることができます。



UDPはデータ配信を保証しません。 実際には、ほとんどのパケットはもちろん到達しますが、常に約1-5％の損失があり、時にはパケットがまったく到達しない期間があります（送信者と受信者の間に数千台のコンピューターが存在する可能性があることに注意してください）失敗または破損する可能性があります）。



UDPは、パケット配信も保証しません。 1、2、3、4、5の順序で5つのパケットを送信できます。また、3、1、2、5、4など、まったく異なる順序で送信することもできます。ほとんどの場合、正しい順序で、しかしあなたはそれに頼ることはできません！



最後に、UDPは実際にはIPに何も追加しませんが、それでも1つのことを保証します。 パケットを転送すると、パケットは完全に到達するか、まったく到達しません。 したがって、256バイトのパケットを別のコンピューターに転送する場合、パケットから最初の100バイトのみを受信することはできません。256バイトすべてを受信する必要があります。 UDPプロトコルが保証するのはこれだけです。他のすべてはあなたの肩にかかっています。



したがって、決定する必要があります-TCPまたはUDPソケットを使用するために？ それらのプロパティを見てみましょう：



TCP：

• 接続の原則を使用する
• 配送と優先度の保証
• 情報をパッケージに自動的に分割します
• データが集中的に送信されないようにします（データフロー制御）
• 使いやすい-ファイルからの書き込み/読み取りとして

UDP：

• 接続の原則を使用しません-手動で実装する必要があります
• パッケージの配達と配達順序は保証しません-彼らは間違った順序で、重複して、またはまったく届かないかもしれません！
• データを手動でパケットに分割して送信する必要があります
• データを過度に送信しないように注意する必要があります。
• パケットが失われた場合は、何らかの方法で追跡する必要があり、必要に応じて再度転送する必要があります

このようなリストを使用すると、ソリューションは明らかなように見えます。TCPは必要なすべての機能を実装し、使いやすく、UDPを使用すると、世界のすべてを手作業でゼロから書くことができます。 TCPを使用しますか？



しかし、違います。



TCPの使用は、おそらくマルチプレイヤーゲームを開発する際に犯す可能性のある最悪の間違いです。 理由を理解するために、TCPが非常に使いやすい理由を理解しましょう！

TCPの仕組み

TCPとUDPはどちらもIP上で動作しますが、実際には完全に異なります。 UDPはIPと非常によく似た動作をしますが、TCPはすべてのパケットの問題からユーザーを引き離し、ユーザーとのやり取りをファイルの読み取り/書き込みのように見せます。



それで彼はどのようにそれをしますか？



まず、TCPはデータストリームの抽象化を使用します。このストリームにデータバイトを書き込むだけで、TCPは宛先に確実に到達します。 IPプロトコルはデータをパケットで送信し、TCPはIP上で実行されるため、TCPはユーザー入力ストリームを個別のパケットに分割する必要があります。 したがって、TCPの内部では、一部のロジックがデータをキューに収集し、十分な量が蓄積されるとパケットを形成して宛先に送信します。



非常に小さなパケットを転送する必要がある場合、この動作はマルチプレイヤーゲームの問題になる可能性があります。 特定のサイズ（たとえば、100バイト以上）のパケットを形成するのに十分なデータが蓄積されるまで、TCPがデータを転送しないことを決定する場合があります。 そして、これは大きな問題です。なぜなら、クライアントからデータをできるだけ早くサーバーに転送する必要があるためです（プレーヤーのキーを押す）。そして、プロトコルによるデータバッファリングによる遅延がある場合、クライアント側のプレーヤーにとって、ゲームは最も遠くないでしょう楽しい方法で。 同時に、ゲームのオブジェクトの更新は遅れて行われ、まれにしか行われませんが、オブジェクトを時間通りに頻繁に更新する必要があります。



TCPには、これを修正するオプション「TCP_NODELAY」があります。 彼女は、送信のためにキューにデータが蓄積されるのを待たずに、すぐに送信するようにプロトコルに指示します。



残念ながら、このオプションをインストールしても、ネットワークゲームでTCPを使用する場合、TCPには多くの問題があります。



すべての問題の根本は、TCPが失われたパケットや順番がずれたパケットを処理する方法にあり、信頼性の高い一貫した接続の錯覚を作り出します。

TCPが信頼できる接続を提供する方法

TCPは、送信時にデータストリームを個別のパケットに分割し、信頼性の低いIPプロトコルを使用してネットワーク経由で送信し、受信したコンピューターから受信したパケットから元のストリームを復元します。



しかし、パッケージの1つが失敗するとどうなりますか？ または、パケットの順序が間違っていたり、重複していたり​​しますか？



TCPの詳細を特に掘り下げない場合（これは非常に複雑なトピックです-TCP / IP Illustratedで読むことができます）、プロセスは次のようになります。TCPはパケットを送信し、パケットが到着していないと判断し、同じパケットを宛先に再度送信します。 宛先側で重複するパケットが排除され、順序どおりに到着しないパケットは、すべてが正常に、つまり確実に順序どおりになるように並べ替えられます。



問題は、パケット損失の場合にTCPがデータストリームを「同期」すると、失われたパケットが再度送信される（宛先で受信される）まで送信が停止することです。 待機中に新しいデータが到着すると、キューに入れられ、同じ失われたパケットが到着するまでデータを読み取ることができなくなります。 パッケージを再送信するのにどれくらい時間がかかりますか？ 少なくともパケットの往復時間（TCPがどのパケットを再送信するかを決定するとき）に加えて、失われたパケットを再配信するまでの時間がかかります。 そのため、コンピューター間のpingが125ミリ秒の場合、パケットの再送信には約5分の1秒かかり、最悪の場合は最大0.5秒かかります（再送信するパケットも失われると想像してください）。 楽しい！

マルチプレイヤーゲームにTCPを使用してはならない理由

ネットワークゲームでTCPを使用する場合の問題は、ブラウザー、電子メール、およびその他のアプリケーションとは異なり、ゲームがリアルタイムの相互作用に関連付けられていることです。 たとえば、ユーザーが押したキーやゲーム内のプレーヤーの位置など、ゲームの多くの側面については、1秒前に何が起こったかは関係ありませんが、ゲーム世界の最新の状態のみが重要です。



3Dシューティングゲームなど、マルチプレイヤーゲームの簡単な例を考えてみましょう。 ゲームのネットワーク部分は非常に簡単に構築されます：ゲームサイクルの各反復、クライアントはすべてのプレーヤーアクション（キーストローク、マウス位置など）の説明をサーバーに送信し、各反復はサーバーがこのデータを処理し、ゲームワールドのモデルを更新し、現在をクライアントに送り返します彼がプレイヤーのために新しいフレームを描くように、ワールドオブジェクトの位置。



したがって、このゲームでは、ネットワークを介した送信中にパケットが失われた場合、ゲームは停止し、パケットが再び配信されるまで待機します。 サーバーは新しいパケットを受信できないため、クライアント側ではゲームオブジェクトがフリーズし、サーバーではプレイヤーが移動したり射撃したりできません。 失われたパケットが最終的に到着すると、関連のない古い情報がすでに含まれています。 さらに、この後、待機時間中にキューに蓄積されたすべてのパケットが来ます。すべてのパケットは、ループの1回の反復で処理する必要があります。 完全な混乱！



残念ながら、このTCPの動作を変更することはできません。TCPの意味なので、変更する必要はありません。 インターネットを介したデータ送信を信頼性の高い一貫したデータストリームにする必要があります。

ただし、信頼性の高い一貫したデータストリームは必要ありません。



クライアントからサーバーにできるだけ早くデータが到着する必要があり、データが再び送信されるのを待ちたくありません。

これが、マルチプレイヤーゲームにTCPを使用すべきではない理由です。



しかし、待って！ UDPとTCPの両方を一緒に使用できないのはなぜですか？



ユーザーのクリックやゲームワールドの状態などのリアルタイムゲームデータの場合、最も関連性の高いデータのみが重要ですが、他の種類のデータ、たとえば、あるコンピューターから別のコンピューターに送信されるコマンドセットの場合、チャネルの信頼性と一貫性は非常に重要です。



もちろん、UDPを使用してユーザー入力データと世界状態データを送信し、配信を保証する必要があるデータにはTCPを使用するのは魅力的です。 おそらく、レベルのロード用、AIコマンド用など、いくつかのコマンドの「ストリーム」を作成できるとさえ考えるかもしれません。 「レベルをロードするためのデータを含むパケットが失われた場合、AIチームは完全に無関係であるため、列に並んで待つ必要はありません！」 この場合、あなたは正しいです、そして、あなたはコマンドの各流れのためにTCPソケットを作成することに決めることができます。



一見、これは素晴らしいアイデアです。 しかし問題は、TCPとUDPの両方がIPを介して機能するため、両方のプロトコルのパケットが互いに影響を及ぼし合うことです-すでにIPレベルで。 この影響がどの程度正確に現れるかは非常に複雑な問題であり、TCPの信頼性を確保するメカニズムに関連しています。 ただし、いずれにしても、通常TCPを使用するとUDPパケット損失が増加することに注意してください。 これについてもっと知りたい場合は、 この記事を読むことができます。

おわりに

UDPを使用するだけでなく、UDPのみを使用することをお勧めします。 TCPとUDPを一緒に使用しないでください。代わりに、UDPに基づいて、必要なTCP「チップ」を独自に実装する方法を学ぶ方が良いでしょう。



次の記事では、UDPベースの接続を使用して独自のプロトコルを実装することから、データフローの信頼性の高い伝送と制御を実現する実装まで、これを行う方法を説明します。