かつて、ダイアルアップ/ ISDN /低速ブロードバンドを介したTCP接続では、パケットが1つドロップされただけで再同期が行われたため、ゲームが途切れ途切れになりました。つまり、多くのゲーム開発者は、UDPの上に独自の信頼性レイヤーを実装する必要がありました。または、ドロップまたは順序が狂う可能性のあるメッセージにUDPを使用し、信頼性が必要な情報にパラレルTCP接続を使用しました。
平均的なユーザーのネットワーク接続が高速になったとすると、FPSなどのリアルタイムゲームはTCP接続で優れたパフォーマンスを発揮できますか？
回答:
私はノーと言うでしょう。ゲームオブジェクトの空間情報は可能な限り高速である必要があります。そのため、信頼性は100％重要ではないため、UDPを使用することをお勧めします。最新の接続でも、UDPはまだ十分に遅いため、補間などの特別な考慮が必要です。転送されたデータの量だけでも、TCPはこれに大きなオーバーヘッドを追加します。
ただし、TCPは、マルチプレイヤーネゴシエーション、チャットメッセージ、スコアの更新など、リアルタイムではないものには完全に受け入れられます。
FlashはUDPをサポートしていないので、マルチプレイヤーFlashゲームを見ると、TCP / IPで可能なこととできないことのかなり良いアイデアを得ることができます。基本的に、超高速応答時間に依存しない限り、リアルタイムゲームを作成できます。いくつかの例：
http://www.xgenstudios.com/play/stickarena
UDPを使用するオプションがある場合は、実際に使用する必要がありますが、Flashでは、残念ながらそのオプションを使用できません。
場合によります。
World of Warcraftのようなゲームは、通信にTCPを使用します。これを使用すると、多くの問題を回避できるためです。結果としてpingが高くなる場合がありますが、多くのゲームではこれは許容されます。プロトコルとしてUDPを使用する場合でも、空間補間を行う必要があります。
クライアント/サーバーアーキテクチャがクリーンであれば、トランスポートレイヤー（ほとんど）は関係ありません。
TCPにはいくつかの欠点がありますが、これらは簡単に回避されます。
はい、TCPと頭脳だけで十分です。
今日の一般的なネットワーク設定（プロキシ、ファイアウォールなど）を使用すると、UDPはローカル（読み取り：LAN）ゲーム以外ではほとんど役に立ちません。
UDPの代わりにTCPを使用することは完全に受け入れられます-Nagleのアルゴリズムをオフにした場合。
Nagleをオフにすると、UDPのほとんどの速度が得られ、単収縮反応ゲームを完全に作成できるようになります。実際、FlashでTCPを使用してこのようなゲームを作成しました。
http://2dspacemmo.wildbunny.co.uk
お役に立てば幸いです！
それはゲームの種類に依存します。
RTSなどの一部のゲームは、TCPよりもはるかに優れており、通常は常にTCPを使用します。
TCPの本当の問題は、たとえわずかでもパケットが失われると、再送信が発生するまで接続が「停止」することです。OSは順不同のデータをアプリケーションに配信できません（これはTCPの保証を破りますが、TCPはアプリケーションフレームの境界を表示しません）。接続が停止するということは、後からデータが到着することを意味します。ただし、（たとえば）FPSゲームでは、古いデータは役に立ちません。
UDPを使用すると、アプリケーションは、遅延データまたは順序が乱れたデータの処理を選択できます。古いデータを無視し、最新のデータのみを取得できます（FPSなどのゲームの場合、通常はそうします）。時々パケットが失われても、後続のパケットはまったく遅延しません。最終的に遅延パケットが到着した場合、ゲームでは無視できます。
ここで「yes or no cuz I」と答えるだけの答えをそのまま受け入れないでください。実際に直面する必要のないUDPの問題と戦うことになります。
ここでの他の答えはどれも、これを証明する明白な方法を述べていません。
いくつかの簡単な事実を取ります
したがって、1バイトのメッセージを回線に送信するたびに、IPヘッダーも必要であると想定して、プロトコルに応じて25または41バイトを実際に送信しました。
ソース：
私のアドバイス
クライアントとサーバーの相互作用が必要な状況を考えて、クライアントの数を見積もり、2の間で実際に送信するデータに基づいて計算を行います。
例
ゲームの更新ごとに1バイトのメッセージを10個送信し、約60 fpsを更新するため、実際のメッセージデータと関連ヘッダーの60 * 10 = 600バイト/秒を送信する必要があるとします。
ゲームに応じて、すべてを単一のメッセージとして送信できるため、TCPレイヤーからのオーバーヘッドはわずか40バイト（事実上、UDPの1秒あたり20バイトのコスト）であり、そのオーバーヘッドがないと、600バイトの潜在的なコスト（メッセージストリーム全体を再送信する必要があるためです）。
ただし、すべてのメッセージをすぐに送信できるようにすることが非常に重要な場合、600メッセージ（600バイトも）+ 40 * 600 = 24kのTCPオーバーヘッドまたは1秒あたり〜14kのUDPオーバーヘッド+ 600バイトのメッセージデータ。
繰り返しますが、これらのメッセージはどれほど重要であり、どのくらいの頻度で発生するのでしょうか。また、オーバーヘッドを削減するために何らかの方法でバッチ処理できますか？
それは単なるシングルバイトメッセージの束に基づいています。通常、あなたは非常に異なることをしますが、送信される生データを知らずに、UDPよりもTCPがあなたの状況に適している場合、どちらの方法でも証明するのは難しいです。
だから、それは動作しますか？
まあ、典型的なfpsがあり、位置が重要である場合（不正や誤った決定を避けるため）、ネットワークストリームが実現可能であることを知っておく必要がありますが、各プレーヤーはそれぞれ24k +メッセージバイトをストリーミングしますs + messages）...これは、サーバーを介して各クライアントから他のすべてのクライアントにフレームごとに少なくとも1つのメッセージを送信することに基づいた個々のヘッダーのための約10mb / sのブロードバンド回線です。
サーバーとクライアントをそのように動作するようにコーディングしないことは明らかであり、ほとんどの場合、メッセージサイズはフレームあたり1バイトよりもはるかに大きく、おそらく少し少ない可能性が高いため、現実の世界を見ずに言うのは困難です「これは送信する必要があるデータです」の例。
私の場合
私の場合、合理的なオーバーヘッドであると呼びましたが、これはメッセージストリームをどのように構築するかに基づいているため、一部の設計に比べて大きなオーバーヘッドはありません。
TCPは正常に動作し、スケーラブルなMMOサーバーとクライアントフレームワークがありますが、呼び出しをバッチ処理できるので、大量のデータを大量にストリーミングしたり、大量の小さなパケットをストリーミングしたりする必要はありません。
他の人のために：TCPはちょうどしません、そして、彼らはUDPだけを使うことができます、しかし、彼らが得るものについて彼らに保証を与えないことを受け入れなければなりません（順序/到着保証）。
その他の考慮事項
コーディングが不十分なゲームエンジンの多くはCPUのメインスレッドのすべてを処理するため、CPUにはネットワークコードの処理に非常に短い時間しか与えられないことが多く、サーブとクライアントの適切な実装は完全に非同期であり、プッシュとバッチでメッセージをプルします。
いくつかの優れたネットワークライブラリがありますが、ここに見られるように、多くの人はUDPが「ちょうど良い」という意見を持っているようです。まず自分のニーズを考慮し、そうではないかもしれません。同じライブラリのUDPバリアントと比較して、TCPのセットアップが適切にコーディングされていない可能性があります（これを見て、ロードテストで証明されたと言っています）。
最初に送信するデータの技術ベースを構築してテストし、その後、数学を実行してスケールアップし、最悪の場合はクラウドに展開して負荷テストを行い、50台のコンピューターでテストクライアントを実行して処理できるかどうかを確認しますゲームごとに32人のプレイヤーの制限（または制限がある場合）。