1

を使用してクライアントとホスト間の速度をテストしていますiperf。私のアプリケーションでは、およそ 5KHz で 2 バイトの UDP フレームを送信できる必要があります。

通常の UDP 速度テストを実行すると、簡単に 10Mb/s を取得できます。

 $iperf -uVc some_ip -b 10M
 Interval     Transfer    Bandwidth    Dropped/Sent
 0.0-10.0 sec 11.9 MBytes 10.0Mbit/sec 0 / 8504 (0%)

次に、2B を 5Hz (80Kb/s に相当) で送信してアプリケーションをミラーリングしようとすると、次のようになります。

 $iperf -l 2 -uVc some_ip -b 80K

サーバー側は、パケットが通過しなかったと言っていますが、これは、カウンターまたはiperfパケットを追跡するために使用するものが 2B ペイロード内に収まらないためです。これは理にかなっていますか？

一般的な経験則として、多くの小さなパケットを送信することと、大きなパケットを送信しないことのどちらが悪いでしょうか? 大きなデータグラムを「パック」するのを待つことと、取得したらすぐに2Bのデータを即座に送信することとのトレードオフを説明する文献を指摘できる人はいますか?

さらに明確にするために、多くの小さなパケット (オーバーヘッドを含め、パケットは約 60B しかありません) を送信した場合と、少数ではあるが大きなパケットを送信した場合に支払うペナルティに関心があります。これまでの私のテストでは、パケット ドロップは明らかに帯域幅の使用と相関しておらず、むしろ直感に反するパケット数と相関しています。

編集：

私はこれを最も単純なクライアント - サーバーのセットアップで行っています。ローカル ネットワークに接続された 2 台の Linux PC 間で、その間にイーサネット スイッチがあるネットワーク上の唯一のインターフェイスです。

4

2 に答える 2

1

2 バイトがペイロードであり、ネットワーク層がペイロードの前にヘッダーを追加することを認識する必要があります。IP ヘッダーだけでも 20 バイトですが、UDP や TCP にもヘッダーがあり、もちろんイーサネット ヘッダーもあります。

ほとんどの場合、ネットワークはイーサネット ネットワークであることが保証されていません。つまり、mtu は約 1500 です。ヘッダーを含むパケットがそのサイズでない場合は、ネットワークを最適に使用していません。

パケットが mtu に収まらない場合、IP はフラグメンテーションを行います。したがって、mtu が 1500 で、異なるレイヤーが何も追加しないと仮定すると、2000 バイトを送信すると 1500 と 500 に分割されます。または、1501 の場合は 1500 と 1 に分割されます。これも最適ではありません。IP は最大 64K までフラグメント化できます。そのサイズのものを送信すると、もちろん IP によって分割され、最後のパケットを除いて最適なパケットが大量に得られます。

パケットの最適サイズ = mtu - 使用されるさまざまなレイヤーのヘッダー。レイヤーは

  • TCP または UDP
  • 知財
  • イーサネット

mtu は 1492 で保証されていないことに注意してください。ネットワーク全体に依存する場合よりも低くなる可能性があります。

TCP がすべての作業を行います。mtu を最適に利用しようとするのは TCP の性質だからです。Nagle は連続 50 ミリ秒のタイマーとして実装されており、セグメントが送信されるのは、そのタイマーが期限切れになった場合、またはピアが自分自身に送信したものに対する ack を期待している場合のみです。

于 2015-04-09T18:53:55.647 に答える
0

一般的な「どれくらい悪いのか」という質問に対する答えは、通信が行われているネットワーク トポロジとデバイスの種類に大きく依存します。

  1. インターネット経由でデータグラムを送信する場合、多数の小さなパケットは最適ではありません。TCP はNagle のアルゴリズムを実装して、1 または 2 バイトのペイロードを持つ小さなパケットの送信を回避します。これは、RFC 896 で指摘されているように、輻輳の崩壊を引き起こす可能性があります。
  2. 多数のホップがあるネットワークを介してデータグラムを送信すると、各ホップがキュー内の同じ数のパケットを処理できない可能性があるため、パケットがドロップされる可能性が高くなります。
  3. 送信元と送信先が同じローカル ネットワーク セグメントにある場合は、それほど問題にはなりません。パケットごとのオーバーヘッドにより、帯域幅がいくらか失われます。

送受信しているシステムの種類によっては、小さなパケットが多数あると、ネットワーク スタック、ドライバー、およびアプリケーションのチャーンが増加します。組み込みシステムでは、デバイスは、データを処理するのではなく、ネットワーク スタックを介してすべてのパケットをマーシャリングするために、より多くの CPU サイクルを費やす可能性があります。

于 2015-04-09T18:42:53.650 に答える