接続リセット/再送信の問題を特定するtshark（wireshark）
Windows Server2003。
サーバーに最新のWireSharkをインストールしていて、サーバーでパケットをキャプチャして、ランダムに発生した接続のリセット/再送信の問題を特定する必要があります。接続リセットが発生すると、約600接続/秒がリセットされます。通常の値は100 /秒未満である必要があります。サーバーは、実際にはCiscoUCSホスト上の仮想マシンです。 tsharkパケットキャプチャは原因を見つけるのに役立ちますか？
もう1つの副次的な質問は、すべてのトラフィックをキャプチャするため（それが良いアイデアかどうかはわかりません）、パケットスライスも行うことです。私の質問は、各パケットにいくつのバイトを制限する必要があるかです。キャプチャしたパケットのヘッダーは54バイトのようです（フレーム、イーサネットII、インターネットプロトコル、TCP部分）を含むようです）。
tshart -q -b "filesize:20000" -b "files:5" -s 54 -w c:\outfile.pcap
だからすべてのペイロードが保存されないのですか？アドバイスしてください、ありがとう！
通常のイーサネットの場合、snaplen（-s option）パケット全体が必要な場合は、1500にする必要があります。これにより、パケット全体が提供され、WireShark自体にロードされたときに完全なプロトコルデコードが可能になります。何をスニッフィングしているかによっては、ファイルサイズも大きくすることをお勧めします。
少なくともほとんどのパケットのヘッダーを取得するには、通常、200のスナップレンで十分です。 E_II、IP、TCP/UDP、およびいくつかの高レベルのプロトコルヘッダーを取得します。
接続のリセットにはいくつかの種類があり、それぞれに独自の意味があります。
既存のすべての接続をすぐにリセットします
このスタイルのリセットは、サーバーによって送信されるRSTの大きなブロックとしてスニフに表示されます。おそらく、パケット間のトラフィックはほとんどありません。これは、TCP/IPスタックの上のアプリケーションがそれ自体をリセットし、そのモジュールに関連付けられているすべての接続ハンドルを強制終了するようにTCP/IPスタックに指示することによって発生する可能性があります。
トラフィックがある場合に既存のすべての接続をリセットする
これは、より卑劣なパターンでスニフに現れます。ある時点以降、既存の接続がクライアントステーションからトラフィックを受信するたびに、RSTパケットが発行されます。クライアントが行うことは、より高いレベルのプロトコルに依存し、おそらく再接続の試みが発行されます。これは通常、TCP/IPスタック自体がサイレントに接続状態を失うことが原因です。スタックに関する限り、クライアントからのそのパケットは開いている接続に関連付けられていないため、RSTパケットを発行して無視します。
新しい接続試行のリセット
既存の接続は引き続き機能しますが、SYNパケットはRSTで応答されます。通常の操作では、SYNパケットにリストされているポートに開いているポートがないため、これが行われます。これは通常、上位レベルのアプリケーションの障害が原因で発生します。
再送信に関しては、クライアントが期待するパケットを受信していないことが原因です。これは、完全なパケット損失が原因である可能性があります。または、サーバーがそれらのパケットをまったく送信していない可能性があります。サーバー上のスニフに再送信パケットが表示され、会話を一覧表示すると、サーバーからパケットが送信されていないことが示されている場合は、問題が発生していることを示しています。サーバー自体に。これは、上位レベルのアプリケーション、TCP/IPスタック、またはNICドライバー自体の障害に関連している可能性があります。NICドライバーの更新の修正を見てきましたこれですが、VMでは、問題の原因となる可能性は低くなります。このような大量のリセットは、サーバー側のリソースの枯渇が原因である可能性があります。