38

損失が発生する可能性のあるネットワークを介して、あるホストから別のホストにパケットを送信する必要があります。パケットの遅延を最小限に抑えるために、TCP/IP は考慮していません。しかし、UDP を使用してスループットを最大化したい。使用する UDP パケットの最適なサイズは?

ここに私の考慮事項のいくつかがあります：

  • ネットワーク内のスイッチの MTU サイズは 1500 です。8192 などの大きなパケットを使用すると、断片化が発生します。1 つのフラグメントが失われると、パケット全体が失われますよね?

  • 小さいパケットを使用すると、UDP および IP ヘッダーのオーバーヘッドが発生します

  • 非常に大きなパケットを使用する場合、使用できる最大サイズは? データグラムの最大サイズは 65507 であると読みました。このようなサイズを送信できるようにするには、どのくらいのバッファ サイズを使用すればよいですか? それは私のスループットを上げるのに役立ちますか?

  • 一般的な OS (Windows、Linux など) でサポートされる典型的な最大データグラム サイズは?

更新しました：

データの受信者の一部は、TCP/IP スタックが実装されていない組み込みシステムです。

この場所には、利用可能なものを使用することに非常に熱心な人がたくさんいることを私は知っています. しかし、MTU だけに注目するよりも、より良い答えが得られることを願っています。

4

7 に答える 7

16

別の答え: 車輪を再発明しないように注意してください。

TCP は、数十年にわたるネットワーキングの経験の産物です。それが行うすべてまたはほとんどすべてのことには理由があります。ほとんどの人があまり考えないアルゴリズムがいくつかあります (輻輳制御、再送信、バッファ管理、並べ替えられたパケットの処理など)。

すべての TCP アルゴリズムの再実装を開始すると、(Greenspunの第 10 規則を言い換えて)「アドホックで、非公式に指定され、バグだらけで、TCP の実装が遅い」という結果になるリスクがあります。

まだ行っていない場合は、SCTP や DCCP など、TCP/UDP の最近の代替手段を検討することをお勧めします。それらは、TCP も UDP も適切に適合しないニッチ向けに設計されており、新しいアプリケーションごとに車輪を再発明するのではなく、すでに「デバッグされた」プロトコルを使用できるようにするためのものです。

于 2008-11-09T16:45:23.797 に答える
14

理想的なデータグラム サイズを見つける最善の方法は、TCP 自体が理想的なパケット サイズを見つけるために行うこととまったく同じことを行うことです: Path MTU discovery。

TCP には、MSS (基本的には MTU からヘッダーを差し引いたもの) が何であるかを双方が相手に伝える、広く使用されているオプションもあります。

于 2008-11-09T16:29:24.267 に答える
4

C# で mtu を見つける最も簡単な回避策は、dontfragment フラグを true に設定して udp パケットを送信することです。例外がスローされる場合は、パケット サイズを小さくしてみてください。例外がスローされなくなるまでこれを行います。1500 パケット サイズから開始できます。

于 2010-11-11T03:59:47.707 に答える
3

考慮すべきもう 1 つの点は、一部のネットワーク デバイスは断片化をうまく処理できないことです。断片化された UDP パケットや大きすぎるパケットをドロップするルーターを数多く見てきました。Path MTU を使用するというCesarBの提案は良いものです。

最大スループットは、パケット サイズだけによって左右されるわけではありません (これはもちろん貢献しますが)。レイテンシーの最小化とスループットの最大化は、相反することがよくあります。TCP には、全体的なスループットを向上させるように (部分的に) 設計された Nagle アルゴリズムがあります。ただし、一部のプロトコル (telnet など) では、遅延を改善するために Nagle を無効にする (つまり、No Delay ビットを設定する) ことがよくあります。

データに対してリアルタイムの制約はありますか? ストリーミング オーディオは、非リアルタイム データ (ロギング情報など) のプッシュとは異なります。前者は低レイテンシーのメリットが大きく、後者はスループットとおそらく信頼性の向上のメリットがあります。信頼性要件はありますか? パケットを見逃すことができず、再送信を要求するプロトコルが必要な場合、これにより全体的なスループットが低下します。

これには他にも無数の要因があり、(別の応答で示唆されているように) ある時点で TCP の実装が不適切になります。そうは言っても、低レイテンシーを達成したい場合、全体的なパケット サイズを PATH MTU に設定した UDP を使用して損失を許容できる場合 (ヘッダーを考慮してペイロード サイズを設定してください) が最適なソリューションである可能性があります (特に、 UDP が一方の端から他方の端まで到達できることを確認できます。

于 2008-11-09T17:09:01.567 に答える
3

さて、MTU 以外の回答を用意しました。接続された UDP ソケットを使用すると、速度が向上するはずです。UDP ソケットで connect を呼び出す理由は 2 つあります。1つ目は効率です。未接続の UDP ソケットで sendto を呼び出すと、カーネルが一時的にソケットに接続し、データを送信してから切断します。これが送信時の処理時間の 30% 近くを占めていることを示す調査について読みました。connect を呼び出すもう 1 つの理由は、ICMP エラー メッセージを取得できるようにするためです。接続されていない UDP ソケットでは、カーネルは ICMP エラーを配信するアプリケーションを認識できないため、破棄されます。

于 2009-03-12T11:58:32.143 に答える
2

IP ヘッダーは 20 バイト以上ですが、ほとんどが 20 バイトで、UDP ヘッダーは 8 バイトです。これにより、データ用に 1500 - 28 = 1472 バイトが残ります。PATH MTU ディスカバリーは、宛先への途中で可能な最小の MTU を検出します。ただし、これは、最小の MTU を使用すると、可能な限り最高のパフォーマンスが得られることを必ずしも意味するものではありません。ベンチマークを行うのが最善の方法だと思います。または、途中で最小の MTU をまったく気にするべきではないかもしれません。ネットワーク デバイスは、小さな MTU をうまく使用し、パケットを非常に高速に転送する場合があります。そして、その価値は将来的に大きく変化する可能性があります。したがって、これを見つけて後で使用するためにどこかに保存することはできません。定期的に行う必要があります。私があなたなら、MTU を 1440 などに設定して、アプリケーションのベンチマークを実行します...

于 2008-11-09T16:51:30.400 に答える
1

スイッチの MTU が 1500 であっても、(VPN を介したトンネリングのような) パケットの周りにいくつかの余分なヘッダーをラップする状況が発生する可能性があります。それらをわずかに減らして 1450 程度にすることをお勧めします。

ネットワークをシミュレートし、さまざまなパケット サイズでパフォーマンスをテストできますか?

于 2008-11-09T16:17:33.197 に答える