11

サーバーでいくつかの負荷テストを行っており、tshark を使用して一部のデータを pcap ファイルにキャプチャし、wireshark GUI を使用して分析に移動し、表示されているエラーまたは警告を確認しています -> pcap をロードしたエキスパート情報..

よくわからないことや、まだ完全には理解できていないことがいろいろ見えてきます..

警告の下に: TCP の 779 警告: キャプチャされなかった ACKed セグメント (キャプチャ開始時に共通) 446 TCP: 前のセグメントがキャプチャされません (キャプチャ開始時に共通)

例: 40292 0.000 xxx xxx TCP 90 [TCP ACKed unseen segment] [TCP 前のセグメントがキャプチャされていない] 11210 > 37586 [PSH, ACK] Seq=3812 Ack=28611 Win=768 Len=24 TSval=199317872 TSecr=4506547

また、データのコマンド ライン列を作成する便利なコマンドを使用して、pcap ファイルを実行しました。

指図

tshark -i 1 -w file.pcap -c 500000

基本的に、tcp.analysis.lost_segment 列にいくつかのものを見ただけですが、多くはありません..\

誰が何が起こっているのかを教えてくれますか? tshark がデータの書き込みについていけない、その他の問題はありますか? 偽陽性？

4

3 に答える 3

5

それは非常によく誤検知である可能性があります。警告メッセージが示すように、TCP セッションの途中でキャプチャが開始されるのは一般的です。そのような場合、その情報はありません。ACK が本当に欠落している場合は、ホストのアップストリームで ACK が消えている場所を探し始めます。tshark がデータに追いつかない可能性があるため、いくつかのメトリックがドロップされています。キャプチャの最後に、「カーネルがパケットをドロップした」かどうか、およびその数が表示されます。デフォルトでは、tshark は dns ルックアップを無効にしますが、tcpdump は無効にしません。tcpdump を使用する場合は、「-n」スイッチを渡す必要があります。ディスク IO の問題がある場合は、メモリ /dev/shm への書き込みなどを行うことができます。ただし、キャプチャが非常に大きくなると、マシンがスワッピングを開始する可能性があるため、注意してください。

私の賭けは、非常に長時間実行されている tcp セッションがいくつかあり、キャプチャを開始すると、そのために tcp セッションの一部が欠落しているだけであるということです。そうは言っても、重複した/欠落したACKの原因となっていることがいくつかあります。

  1. スイッチ - (非常にまれですが、時々病気の状態になります)
  2. ルーター - スイッチより可能性が高いが、それほど多くはない
  3. ファイアウォール - ルーターより可能性が高い。ここで確認すべきことは、リソースの枯渇 (ライセンス、CPU など) です。
  4. クライアント側のフィルタリング ソフトウェア - ウイルス対策、マルウェア検出など。
于 2013-08-20T16:26:40.743 に答える
1

Acked Unseen サンプル

こんにちは！キャプチャで見つけたものからのいくつかの観察:

多くの場合、パケット キャプチャは、クライアント側で「キャプチャされなかった ACKed セグメント」を報告します。これは、クライアント PC がデータ パケットを送信したという状態を警告します。サーバーはそのパケットの受信を確認しますが、クライアントで行われたパケット キャプチャには、クライアントから送信されたパケットが含まれていません

。実行している Wireshark が遅い」 ( https://osqa-ask.wireshark.org/questions/25593/tcp-previous-segment-not-captured-is-that-a-connectivity-issue )
しかし、この「ACKed segment that was not Captured」アラートが表示されるたびに、クライアント PC から送信された「無効な」パケットの記録が表示されることに気付きました。

  • 上記のキャプチャ例では、フレーム 67795 が 10384 の ACK を送信します。

  • Wireshark が偽の IP の長さ (0) を報告しても、フレーム 67795 の長さは 13194 であると報告される

  • フレーム 67800 は 23524 の ACK を送信します
  • 10384+13194 = 23578
  • 23578 – 23524 = 54
  • 54 は、実際には Ethernet / IP / TCP ヘッダーの長さです (Ethernt の場合は 14、IP の場合は 20、TCP の場合は 20)。
  • したがって、実際には、フレーム 67796 は、オペレーティング システムが装着しようとした大きな TCP パケット (13194 バイト) を表しています。
    • NIC ドライバーは、ネットワーク経由で送信するために、それをより小さな 1500 バイトの断片にフラグメント化します。
    • しかし、私の PC で実行されている Wireshark は、それが有効なパケットであることを認識して解析することができません。2012 Windows サーバーで実行されている Wireshark は、これらのキャプチャを正しく読み取ると思います
  • 結局のところ、これらの「偽の IP 長」と「キャプチャされなかった ACK セグメント」アラートは、実際には私の場合は誤検知でした。
于 2017-12-21T00:24:27.643 に答える