3

小さな UDP ベースのサーバーを構築しています。サーバーは .Net に基づいており、それ自体で Socket クラスを使用します。ReceiveMessageFromAsync と async send を介して完了ポートを使用しています。

私の問題は、トラフィックの約 5% ～ 10% が失われていることです。これは正常なことだと理解していますが、この統計を改善する方法はありますか?

4

5 に答える 5

4

UDP の上に独自の信頼性レイヤーを展開する前に、この質問に対する回答を確認することをお勧めします...信頼性の高い UDP が必要な場合、何を使用しますか?

あるいは、recv を開始する前に適切なソケット オプションを設定して、ソケットの send および recv バッファーをできるだけ大きくすることにより、通過するデータの量を増やしてみることもできます。

于 2010-12-14T15:21:12.020 に答える
2

パス MTU (通常は最大 1400 バイト以下で、場合によってはそれ以下) よりも大きな UDP データグラムを送信しないようにしてください。このようなパケットは複数の IP パケットにフラグメント化され、宛先で再構成されます。これらのフラグメントのいずれかが失われると、UDP データグラム全体が破棄されます。

これにより、パケット損失率が増幅されます。この表は、UDP データグラムの損失率が、伝送に使用されるフラグメントの数が増加するにつれて劇的に上昇する様子を示しています。

Underlying Fragment Loss Rate: 1.00%

Fragments   UDP Datagram Loss Rate
--------------------------------------
1           1.00%
2           1.99%
3           2.97%
4           3.94%
5           4.90%
6           5.85%
7           6.79%
8           7.73%
9           8.65%
10          9.56%
15          13.99%
20          18.21%
30          26.03%
40          33.10%
于 2010-12-15T03:39:44.593 に答える
1

ソケット用のWindowsアーキテクチャは、カーネルからプロトコルハンドラを介してアプリケーションにパケットバッファを複数コピーすることにより、UDPのパフォーマンスが向上するのに悪影響を与えるようです。MSDNは、信頼性の高いUDPプロトコルの実装など、妥当なデータグラムパフォーマンスが必要な場合、開発者にWinsockカーネル（WSK）を紹介し、以前のトランスポートドライバーインターフェイス（TDI）を置き換えることを好むようです。

ただし、NICハードウェア用の非恒星のWindowsドライバーである可能性があります。これは、Broadcomハードウェアを使用したLinuxで優れたパフォーマンスが見られるものの、Windowsでのパフォーマンスの25％未満であるためです。私が見ることができるこれのいくつかは、送信割り込み合体の欠如によるものです。Windowsパフォーマンス監視は、送信の場合は常に0の合体を報告しますが、受信の場合は可変範囲を報告します。Linuxでは、合体を調整して、明確なパフォーマンスの変化を確認できます。Broadcomのドライバソフトウェアは、それ以降のハードウェアリリースでの送信合体のみをサポートしているようです。

合体とは、パケットがNICとの間でバッチで送信されることを意味します。パケットをバッチ処理すると、通常、CPU使用率が低下し、バッファがいっぱいまたは他のシステムアクティビティによってドロップする可能性が低くなります。

したがって、OSを変更することは現実的ではないように見えますが、制限されたドライバーの影響を最小限に抑えるために、さまざまなハードウェアを試すことができます。

于 2010-12-29T04:47:20.307 に答える
0

できることは、TCP が使用するのと同じ一般的な順序で何かを行うことです。受信したパケットを追跡し、ACK/NAK パケットに何かを送り返して、到着しなかったパケットを再送信します。

于 2010-12-14T14:05:22.417 に答える
0

パケット損失を減らすもう 1 つの側面は、パケットを送信する速度を調整することです。パス上のボトルネック ポイントが処理できる速度よりも速くデータを送信している場合、これはパケットのドロップとして明らかになります。平均データ レートが非常に低い場合でも、パケットのバーストを立て続けに送信している可能性があります。

TCP は、未確認の未確認のデータ バイト数を輻輳ウィンドウと呼ばれる値に制限することで、これを処理します。輻輳ウィンドウは小さく始まり、パケット損失が発生するまでゆっくりと増加し、その時点で縮小されます (パケット損失が発生し続ける場合は、徐々に増加します)。プロトコルで送信者にパケット損失が通知される場合、同様のものを実装できます。

于 2010-12-15T23:10:46.603 に答える