/proc/net/udp
Linuxには「drops」列があります。
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パケットの送信者とアプリケーションの間で発生する削除が私のボックスの外で発生していると確信できますか?、一部のスイッチやルーターなどで?
それとも、私のネットワークカードドライバがカウンタに影響を与えず、何らかの理由で自動的にパケットをドロップしているのでしょうか?
Windowsでは、受信バッファにまだ多くのスペースがある場合でもパケットが破棄される可能性があることを知っていますが、Linuxにも同様の状況があるかどうかはわかりません。
答え1
いいえ。
パケットは、ユーザーソケットに逆多重化される前に失われる可能性があります。
これは、カーネルが何らかの理由でネットワークカードからパケットを十分に高速に読み取れない場合に発生します。
ネットワークカードはポートごとに失われたパケット数をカウントしません。少なくとも必ずしもそうではありません/proc/net/udp
。
2015年にパケットロスを詳しく紹介した文書がありましたが、興味深く見たのかと思います。 https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf
答え2
定義によると、UDPは接続されていないプロトコルです。定義によると、システムレベルでは、発信者は受信を確認せずに送信にのみ関心を持ちます。したがって、発信者の立場では、UDPパケットを送信することができれば成功です。
輻輳/エラーが発生したり、マルチパスルーティングやさまざまな輻輳レベルを含むさまざまな要因によって、受信者がこれらのパケットをすべて受信したり、送信された順序で受信したりすることは保証されません。
バッファサイズも制限されており、パケットがバッファを超えるとパケットが失われます。
あなたの質問に答えるために、接続指向でないプロトコルを処理し、システムレベルでパケット損失カウンタを見ると0です。接続の一方(発信者または受信者)で両方を実行するだけでは、画像全体がわかりません。 。
したがって、統計はバッファから破棄されたパケットを反映しますが、送信中に失われたすべてのパケットを考慮するわけではありません。
これに加えて、両方のサイズについて送受信されたパケット数を確認することもできます。
上位層、つまりアプリケーションレベル(DNSやNTPなど)に移動すると、より意味のあるサービス統計を取得するための追加の制御がある可能性があります。
~からUDP-ウィキペディア
UDPは、単純な非接続伝送モデルと最小限のプロトコルメカニズムを使用します。これにはハンドシェイクダイアログボックスがないため、ユーザープログラムはデフォルトのネットワークプロトコルの不安定性にさらされます。配送、注文、または重複保護は保証されません。 UDP は、データグラムのソースと宛先のさまざまな機能を処理するためのデータ整合性チェックサムとポート番号を提供します。
Stack Overflowの関連スレッドLinux UDPバッファの空き領域を監視する方法は?