7

FTP アプリケーションのパケット損失をテストする必要があります。Wiresharkパケット スニファーを使用して、TCP ストリームを取得しました。

Wireshark を使用してパケット損失を見つけるにはどうすればよいですか?

4

2 に答える 2

6

パケット損失や、ビット エラー レート (BER) などのその他の関連メトリックは、調べたいレイヤーによっては、Wireshark のダンプを見て経験的に確認するのが困難または不可能な場合があります。そして、その多くは、使用しているプロトコルと、それを実装しているソフトウェア/ファームウェアに大きく依存しています.

たとえば、Wi-Fiルーターでこれとまったく同じ経験がありました。特定の Wi-Fi リンクの BER を経験的にテストする必要がありました。しかし、802.11 には TCP に似た CRC ベースの再送信システムがあり、すべてリンク層で発生することが判明しました。

したがって、たとえば、Wi-Fi デバイス A から Wi-Fi デバイス B に UDP パケットを送信できます。転送中に、いくつかのビットが反転し、デバイス B は CRC が間違っていることを確認し、再送信の要求を送信します。パケットが再度送信され、再び破損します。ただし、3 回目の試行では、パケットは正常に通過します。

このことから、ある種のパケット損失メトリックが表示されることを期待できますか? 残念ながら、いいえ。このインターチェンジ全体が Wireshark の下で発生します。UDP パケットが正常に送信されたことがわかりますが、そこに到達するまでに通常の 3 倍の時間がかかります。(結局、リンク層の CRC エラーが発生したときに通知を送信するためにカーネルを変更する必要がありました。めちゃくちゃでした!)

于 2010-11-12T21:09:12.230 に答える
-1

[Zr40は、この部分が間違っていることを以下に指摘しています:私のコメントを拡張するために-Wiresharkは、下部のステータスバーにドロップされたパケットの数を示します(サンプルキャプチャを実行したところ、「パケット:65表示:65マーク:0ドロップ:0 ")しかし、どちらの端で実行しているかによって、同じ結果が得られるかどうかはわかりません。]

その場合、両端でWiresharkを実行し、パケット統計(パケット数A-> B、B-> A)を確認して、違いを比較する必要があると思います。TCPの再試行などに依存することはできません。これは、必ずしもパケットが失われることを意味するわけではないためです。

また、統計をARP、DNSルックアップなどの他のものによって歪めたい場合を除いて、FTPに対してのみキャプチャフィルターを設定する必要があります。

于 2009-06-30T11:25:07.790 に答える