スループットを最大にするためのUDPパケットの最適サイズはどれくらいですか？
潜在的に損失の多いネットワークを介して、あるホストから別のホストにパケットを送信する必要があります。パケットの待ち時間を最小限にするために、TCP/IPについては考慮していません。しかし、UDPを使用してスループットを最大化したいと思います。使用するUDPパケットの最適なサイズはどれくらいですか？
ここに私の考慮事項のいくつかがあります：
ネットワーク内のスイッチのMTUサイズは1500です。8192などの大きなパケットを使用すると、断片化が発生します。 1つのフラグメントが失われると、パケット全体が失われますよね？
小さいパケットを使用すると、UDPおよびIPヘッダーのオーバーヘッドが発生します
本当に大きなパケットを使用する場合、使用できる最大のパケットはどれですか。最大のデータグラムサイズは65507であると読みました。このようなサイズを送信できるようにするには、どのバッファーサイズを使用すればよいですか？それは私のスループットを上げるのに役立ちますか？
一般的なOS（Windows、Linuxなど）でサポートされる一般的な最大データグラムサイズは何ですか？
更新しました：
データの一部の受信者は、TCP/IPスタックが実装されていない組み込みシステムです。
この場所は、入手可能なものを使うことに非常に熱心な人々でいっぱいであることを知っています。しかし、MTUだけに焦点を合わせるよりも良い答えが欲しいと思います。
別の答え：車輪を再発明しないように注意してください。
TCPは何十年にもわたるネットワーキングの経験の産物です。それがするすべてまたはほとんどすべてのことには共鳴があります。ほとんどの人があまり考えないいくつかのアルゴリズムがあります（輻輳制御、再送信、バッファー管理、並べ替えられたパケットの処理など）。
すべてのTCPアルゴリズムの再実装を開始すると、（パラフェージング Greenspunの第10規則 ） "アドホックで、非公式に指定され、バグに埋もれて、遅くなるリスクがありますTCPの実装」。
まだ行っていない場合は、SCTPやDCCPなど、TCP/UDPの最近の代替手段を検討することをお勧めします。これらは、TCPもUDPも適切に一致しなかったニッチ向けに設計されたものであり、新しいアプリケーションごとにホイールを再発明する代わりに、すでに「デバッグ済み」のプロトコルを使用できるようにするためのものです。
理想的なデータグラムサイズを見つける最善の方法は、TCP自体が理想的なパケットサイズを見つけるために行うことを正確に実行することです パスMTU検出 。
また、TCPには広く使用されているオプションがあり、MSS（基本的にはMTUマイナスヘッダー）がどちらであるかを両側から相手に伝えます。
さて、私はあなたのためにMTU以外の答えを持っています。接続されたUDPソケットを使用すると、速度が向上します。 UDPソケットで接続を呼び出す理由は2つあります。最初は効率です。接続されていないUDPソケットでsendtoを呼び出すと、カーネルが一時的にソケットを接続し、データを送信してから切断します。送信時の処理時間の約30％を占めるとの調査結果を読みました。 connectを呼び出すもう1つの理由は、ICMPエラーメッセージを取得できるようにするためです。接続されていないUDPソケットでは、カーネルはICMPエラーを配信するアプリケーションを認識していないため、破棄されます。
考慮すべきもう1つのことは、一部のネットワークデバイスは断片化をあまりうまく処理しないことです。断片化されたUDPパケットや大きすぎるパケットをドロップする多くのルーターを見てきました。パスMTUを使用するという CesarB による提案は良いものです。
最大スループットは、パケットサイズだけで決まるわけではありません（もちろんこれは寄与します）。多くの場合、レイテンシの最小化とスループットの最大化は互いに矛盾しています。 TCPには、全体的なスループットを向上させるために（部分的に）設計されたNagleアルゴリズムがあります。ただし、一部のプロトコル（telnetなど）は、しばしばNagleを無効にします（つまり、遅延なしビットを設定します）。待ち時間を改善するため。
データにリアルタイム制約がありますか？オーディオのストリーミングは、非リアルタイムデータ（ログ情報など）をプッシュするのとは異なり、前者は低レイテンシのメリットが多く、後者はスループットの向上とおそらく信頼性のメリットがあります。信頼性の要件はありますか？パケットを見逃すことがなく、再送信を要求するプロトコルが必要な場合、これは全体的なスループットを低下させます。
これには他にも無数の要素があり、（別の応答で示唆されているように）ある時点でTCPの不適切な実装が得られます。そうは言っても、低遅延を実現し、パケットサイズ全体をPATH MTUに設定したUDPを使用して損失を許容できる場合は（ヘッダーを考慮してペイロードサイズを必ず設定してください）、おそらく最適なソリューションです（特にUDPが一方の端から他方の端に到達できることを保証できます。
C＃でmtuを見つける最も簡単な回避策は、dontfragmentフラグをtrueに設定してudpパケットを送信することです。例外がスローされる場合は、パケットサイズを減らしてみてください。例外がスローされなくなるまでこれを行います。 1500パケットサイズから開始できます。
Uhh Jason、TCPしないUDPを使用しない。TCP IPを使用するTCP/IPと呼ばれることが多いのはこのためです。UDPもIPを使用するため、UDPは技術的にはUDP/IPです。IPレイヤーは、エンドからエンドへ（異なるネットワーク間で）データの転送を処理するため、 Inter-networkingプロトコルTCPおよびUDPはデータ自体のセグメンテーションを処理します。イーサネットなどの下位層またはPPPまたは他に使用するものはすべて、コンピュータ間のデータ転送を処理します（つまり、単一のネットワーク内で）。
IPヘッダーは20バイト以上ですが、ほとんどの場合20バイトで、UDPヘッダーは8バイトです。これにより、1500-28 = 1472バイトのデータが残ります。 PATH MTUディスカバリーは、宛先に向かう途中で可能な限り最小のMTUを見つけます。ただし、これは、必ずしも最小のMTUを使用すると、最高のパフォーマンスが得られるという意味ではありません。私は最良の方法はベンチマークを行うことだと思います。あるいは、途中で最小のMTUを気にする必要はまったくないかもしれません。ネットワークデバイスは、小さいMTUを非常によく使用し、パケットを非常に高速に転送することもできます。そして、その価値は将来非常によく変わるかもしれません。したがって、これを発見してどこかで保存して後で使用することはできません。定期的に実行する必要があります。私があなたなら、MTUを1440のような値に設定して、アプリケーションのベンチマークを行います...
スイッチのMTUが1500であっても、パケットの周りにいくつかの追加ヘッダーをラップする状況（VPNを介したトンネリングなど）が発生する可能性があります。それらを少し減らして1450程度にするとよいでしょう。
ネットワークをシミュレーションして、さまざまなパケットサイズでパフォーマンスをテストできますか？