web-dev-qa-db-ja.com

理解[TCP ACKed unseen segment] [TCP Previous segment not capture]

サーバーで負荷テストを行っており、tsharkを使用して一部のデータをpcapファイルにキャプチャしてから、wireshark GUIを使用して、分析->エキスパート情報にアクセスし、pcapを読み込んで表示します..

まだわからない、またはまだ完全に理解していないさまざまなものを見ています。

[警告]の下にある：779 TCPに関する警告：キャプチャされなかったACKされたセグメント（キャプチャ開始時に共通）446 TCP：前のセグメントがキャプチャされなかった（キャプチャ開始時に共通）

例は次のとおりです：40292 0.000 xxx xxx TCP 90 [TCP ACKed unseen segment] [TCP Previous segment not capture] 11210> 37586 [PSH、ACK] Seq = 3812 Ack = 28611 Win = 768 Len = 24 TSval = 199317872 TSecr = 4506547

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

コマンド

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

基本的にはtcp.analysis.lost_segment列にいくつかの項目が表示されますが、多くは表示されません。

誰が何が起こっているのかを知っていますか？ tsharkはデータの書き込みに追いつくことができません、他の問題？誤検知？

tcpwiresharktshark
8
Steve

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

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

  1. スイッチ-（非常に可能性は低いが、時には病気の状態になる）
  2. ルーター-スイッチよりも可能性が高いが、それほど多くはない
  3. ファイアウォール-ルーターよりも可能性が高い。ここで探すべきことは、リソースの枯渇（ライセンス、CPUなど）です。
  4. クライアント側のフィルタリングソフトウェア-ウイルス対策、マルウェア検出など.
4
dtorgo

「TCP ACKed Unseen」のもう1つの原因は、キャプチャでドロップされる可能性のあるパケットの数です。ビジー状態のインターフェイス上のすべてのトラフィックに対してフィルタリングされていないキャプチャを実行すると、tsharkの停止後に大量の「ドロップされた」パケットが表示されることがあります。

これを見た最後のキャプチャでは、2893204パケットがキャプチャされましたが、Ctrl-Cを押すと、87581パケットのドロップメッセージが表示されました。これは3％の損失であるため、wiresharkがキャプチャを開くと、パケットが失われ、「見えない」パケットが報告される可能性があります。

先ほど述べたように、キャプチャフィルタのない非常に忙しいインターフェイスをキャプチャしたため、tsharkはすべてのパケットをソートする必要がありました。キャプチャフィルタを使用してノイズの一部を除去すると、エラーは発生しなくなりました。

2
Nathan

未確認サンプルの取得

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

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

最初は、「たとえば、Wiresharkを実行しているマシンが遅い」ため、PCが送信するパケットをキャプチャに記録できないことを示していると思いました（ https：// osqa-ask。 wireshark.org/questions/25593/tcp-previous-segment-not-captured-is-that-a-connectivity-issue ）
ただし、この「キャプチャされなかったACKセグメント」アラートを見るたびに、クライアントPCから送信された「無効な」パケットの記録を見ることができることに気付きました。

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

  • Wiresharkが偽のIP長（0）を報告しているにもかかわらず、フレーム67795の長さは13194であると報告されています

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