情報をより小さなパケットに分割すると、TCPのスループットが低下するという投稿を見てきました。しかし、私は実際にはほんの少しの情報を送信するだけでよいゲームサーバーを作っています。これはターン制ストラテジーゲームなので、1台のサーバーでサポートできるプレーヤーの数はレイテンシーよりも重要です。とにかく将来のプロジェクトのレイテンシーの制御について学びたいと言っています。
それで、たくさんの小さなパケットにとって、UDPはより良い選択ですか？信頼できるものである必要があるので、パケットを失った場合は再送する必要があります...また、UDPパケットの実際の損失率はどれくらいですか？サーバーが通常の状態で実行されているとすると、5〜10％の高さになりますか？私はクライアントがモバイルデバイス上にあることを言及する必要があります...彼らの損失率はおそらくPCよりもはるかに高いですか？
プロトコル（TCP、UDP、その他）に関係なく、多くの小さなパケットは、少数の大きなパケットよりも効率が低くなります。各パケットには、固定サイズのヘッダー（より正確には、最小サイズのヘッダーがありますが、特定の状況では大きくなる可能性があります）と、場合によってはトレーラーもあります。したがって、スループットが制限されているネットワークパイプの場合は、次のパケットで埋めます。ヘッダー+トレーラー+1バイトのペイロードは、容量のほぼすべてが実際のデータではなく、メタデータによって使用されていることを意味します。各パケットでより大きなデータチャンクを送信すると、効率が向上します。とは言うものの、アプリケーションアーキテクチャに送信するデータがあまりない場合もあるため、オプションは、小さなパケットか、一度に送信する一連のパケットを集約する際の大きな遅延のいずれかです。どのアプローチを取るか（またはその間の何か、でも）アプリケーションの設計の一部です。あなたの特定のケースでは、ターンベースのアプローチで、あなたがそれが何を意味するのかを正しく理解していれば、後続のパケット間の期間はすでに重要になります（とにかくネットワークタイムスケールによって）ので、小さなパケットはおそらく最適なルート。パケット間の遅延が大きいため、小さなパケットのストリームが全体的なスループットに与える影響はおそらく無視できます。
信頼性は確かに複雑さを増します。TCPを使用すると、コーディングの観点から信頼性が「簡単」になりますが、ネットワークの実際の特性によっては、特にチャネルの全体的な信頼性が低下するため、独自の再送信UDPコードを作成する方が適切なルートになる可能性があります。TCPはほとんどの場合回復しますが、さまざまなタイムアウトと特定のイベントによる調整方法は、信頼性の低いチャネルでは問題になる可能性があります（多くのVPNソリューションがUDPベースである主な理由の1つ）。
実際の損失率の予測はネットワークに大きく依存しますが、トラバースする損失LAN - internet - LAN - mobile network（または同様のトポロジ）がローカルLANの損失よりも大幅に高いことは間違いありません。