TCPとUDPの両方を同時に使用することには意味がありますか？

読んだ後であるUDPをまだ良いTCPよりもデータが重いリアルタイムゲームのため？、TCPとUDPの両方を同時に使用するのは理にかなっているのでしょうか。

• まれに送信されるが、確実に到着することが保証されている情報を送信するためのTCP。
  スコアの更新、プレーヤーの名前、ゲームの世界でのライトのオン/オフの状態など。

• 絶えず更新され、時々失われる可能性がある情報を送信するためのUDP。新しい情報が常に送信されるためです。
  位置、回転など

これは理にかなっていますか？考えられる欠点は何ですか？
これを処理するより良い方法はありますか？

2つのプロトコル間の競合が原因で、UDPのパケット損失が発生します。UDPは配信が保証されていませんが、TCPは保証されていることに注意してください。UDPが影響を受ける間、より多くのTCPパケットが通過します-TCPはUDPパケット損失を引き起こします。また、ルーターインフラストラクチャはTCP over UDPを優先するという（歴史的な）考えもありましたが、この後期段階ではまだそうだとは思いません。

ゲームなどで使用できる接続指向のUDPプロトコルの1つを見つけた方がいいと思います。このプロトコルは、TCPの利点のいくつかをその欠点なしに提供します。いくつかありますが、通常は各コンセプトの詳細が記載されたホワイトペーパーがあります。

それらの例は、オープンソースのEnetライブラリーであり、その主な機能は、UDPを介したパケットのオプションの信頼できる順序どおりの配信です。

gafferongames.comへのコメントからのSam Jansenによる引用は次のとおりです。

ゲーム開発者ではなくネットワーク研究者として話すと、TCPとUDPを一緒に使用しないという結論は少し強いようです。TCPは、送信するデータが多すぎる場合にのみパケット損失を引き起こします。送信しているUDPデータと同じようにいくつかの方法で。違いは、TCPが送信する速度を直接制御できないことです。これはあなたには隠されています。

信頼できるデータを送信する必要があるだけで、再送信や信頼できるプロトコルの実装について心配したくない場合、レートが低くなることがわかっていれば、TCPとUDPの両方を使用しても問題はありません。

2つの関係はそれほど複雑ではありません。TCPは、パケット損失が発生するまで送信レート（送信するデータがある場合）を増加させるだけです。時間をゆっくりと）。レートの増加によりパケット損失が発生すると、UDPパケットを含む他のデータストリームにもヒットする可能性が高くなります。

紙のUDPパケット損失の特性：TCPトラフィックの影響は、一度に複数のTCP接続を開き、ネットワークにデータをフラッディングすることで結果を得ました。これにより、輻輳に続いてグローバル同期が発生します。どちらもパケットのドロップを引き起こします。明らかに、ゲームクライアントは一度に数十の接続を開き、ネットワークでデータをフラッディングしないため、結果は異なります。

あなたの質問に答えるには：

TCPとUDPの両方を同時に使用するのは理にかなっているのでしょうか。

はい、これは、帯域幅の制限内にいることを前提として行うには許容できることです。

• まれに送信されるが、確実に到着することが保証されている情報を送信するためのTCP。スコアの更新、プレーヤーの名前、ゲームの世界でのライトのオン/オフの状態など。

TCPとUDPの両方を使用する場合は、常にUDPを介してできるだけ多く、TCPを介してできるだけ少なく送信することを優先する必要があります。

さて、私はあなたにこれを尋ねます：スコア、プレーヤーの名前、およびTCP上のライトの状態を送信することは本当に必要ですか？このデータを最終的に受信する必要があるのは本当ですが、このデータを厳密に順序正しく正確に1回受信する必要があるのは本当ですか。

おそらく違います。

UDPはこれらの場合に問題なく機能し、Quake 3はその良い例です。

では、UDPと一緒のTCPの良い例は何でしょうか。さて、ゲームのチャットボックスを考えてみてください。このチャットボックスへの更新（つまり、テキストの新しい行）は、確実かつ順序どおりに送信する必要があります。したがって、TCPが適しています。

これは理にかなっていますか？

• はい

考えられる欠点は何ですか？

• パケット損失、コードの複雑さの増加、管理するための別の接続==切断、タイムアウト、例外、その他の可能性...

これを処理するより良い方法はありますか？

• 既存の信頼できるUDPライブラリを使用します。最も人気のある2つは、Lidgren Network（C＃）、RakNet（C ++）です。経験から、Lidgrenは非常に使いやすく、高速で、信頼性が高いと言えます。

考慮すべき追加のリソース制約があります。サーバー上のTCPのほとんどの実装（私は信じていますが、参照はありません）では、サーバーが同時に開くことができる同時TCP接続の数に制限があります。これにより、各プレーヤーが独自の接続を必要とする場合、同時に開くことができるプレーヤーの数が制限されます。

制限は、ネットワークシステムの設定によって定義されます。さらに、すべての接続は、サーバー上のどこかから取得する必要があるメモリを消費します。

1つの解決策は、データの転送中に一時的なTCP接続のみを開き、すぐに閉じることです。これによりトランザクションが遅くなり、TCP接続を開くのはかなり「高価な」プロセスです。いつものように、大規模な成長を可能にするために、最初から堅牢なシステムを設計することがすべてです。