web-dev-qa-db-ja.com

/ proc / net / udpは、イーサネットプラグとアプリの間で発生するすべてのドロップをカウントしますか？

/proc/net/udp Linuxでは「ドロップ」列があります：

cat /proc/net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops
16151: 00000000:CB53 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 39947169 2 ffff88084c108080 0

特定のソケットのドロップカウンターが0の場合、正当なUDPパケットの送信者とアプリケーションの間で発生したドロップが私のボックスの外で発生したことを確認できます、たとえば、いくつかのスイッチまたはルーターで等。？

または、つまり、私のNICドライバーが、カウンターに影響を与えることなく、何らかの理由でサイレントにパケットをドロップした可能性がありますか？

受信バッファーにまだ多くのスペースがあるにもかかわらず、Windowsではパケットがドロップされる可能性があるという事実を知っています。Linuxに同様のものが存在するかどうかはわかりません。

linuxnetworkingudp
2
Eugene Beresovsky

番号。

パケットは、ユーザーソケットに逆多重化される前に失われる可能性があります。

これは、カーネルが何らかの理由でネットワークカードから十分な速度でパケットを読み取ることができない場合に発生します。

ネットワークカードは、ポートごとに失われたパケットをカウントしません...少なくとも必ずしもそうとは限りません。そのようなものが/proc/net/udpのパケットごとのカウントに統合されているとは思いません。

パケットドロップについて詳しく説明している2015年のドキュメントがありますが、興味深いかどうかはわかりません。 https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf

3
sourcejedi

UDPは、定義上、コネクションレス型プロトコルです。定義上、システムレベルでは、送信者は送信のみを考慮し、受信の確認は行いません。したがって、送信者に影響を与えるものについては、UDPパケットをディスパッチできる限り、成功しました。

可能性のある輻輳/エラーのため、または複数の経路ルーティングを含む複数の要因のため、および輻輳の程度が異なるため、輻輳/エラーの可能性があるため、または送信された順序で、受信者がこれらのパケットをすべて受信する保証はありません。

バッファのサイズも制限されており、パケットがバッファをオーバーランすると、パケットも失われます。

あなたの答えに答えるために、接続に向けられていないプロトコルを扱い、システムレベルで0のパケットドロップコントローラーを見て、接続の片側、送信者または受信者、あるいは両側で、全体像を伝えていません。

したがって、統計はバッファからドロップされたパケットを反映しますが、送信で失われたすべてのパケットは考慮されません。

それに加えて、両方のサイズで送受信されたパケットの数を確認することをお勧めします。

上位層、つまりアプリケーションレベル、つまりDNSまたはNTPなどに移動すると、サービスのより意味のある統計を取得するための追加の制御が存在する可能性があります。

から DP-ウィキペディア

UDPは、最小限のプロトコルメカニズムでシンプルなコネクションレス型伝送モデルを使用します。ハンドシェイクダイアログがないため、ユーザーのプログラムが基盤となるネットワークプロトコルの信頼性にさらされます。配達、注文、または重複保護の保証はありません。 UDPは、データの整合性のチェックサムと、データグラムの送信元と宛先でさまざまな機能をアドレス指定するためのポート番号を提供します。

スタックオーバーフローのスレッドを関連付ける Linux UDPバッファーの使用可能なスペースを監視する方法は？

2
Rui F Ribeiro