tshark (wireshark) 查明連接重置/重傳問題
視窗伺服器 2003。
我在伺服器上安裝了最新的 WireShark，需要在伺服器上擷取數據包以查明隨機發生的連接重置/重新傳輸問題。當連接重置發生時，它會重置大約 600 個連接/秒，正常值應低於 100/秒。伺服器實際上是 Cisco UCS 主機上的虛擬機。tshark抓包能否幫助查明原因？
另一個問題是因為我要擷取所有流量（不確定這是否是一個好主意），所以我也會進行數據包切片。我的問題是每個數據包應該限制多少字節。看起來我擷取的數據包有 54 個字節的標頭（似乎包括幀、乙太網 II、網際網路協議、TCP 部分）。我應該使用
tshart -q -b "filesize:20000" -b "files:5" -s 54 -w c:\outfile.pcap所以所有的有效載荷都不會被保存？請指教，謝謝！
-s對於普通乙太網，如果您想要整個數據包，您的 snaplen （選項）應該是 1500。這將為您提供整個數據包，並在載入到 WireShark 本身時允許完整的協議解碼。根據您嗅探的內容，您可能還想增加文件大小。要至少獲得大多數數據包的標頭，通常 200 個 snaplen 就足夠了。它將獲得 E_II、IP、TCP/UDP 和一些更高級別的協議標頭。
有幾種類型的連接重置，每種都有自己的含義。
立即重置所有現有連接
這種重置方式在嗅探中顯示為伺服器發送的一大塊 RST，數據包之間的流量可能非常少。這可能是由於 TCP/IP 堆棧上方的應用程序自行重置導致的，這反過來又告訴 TCP/IP 堆棧終止與該模組關聯的所有連接句柄。
有流量時重置所有現有連接
這在嗅探中以更狡猾的模式出現。在某個點之後，任何時候現有連接從客戶端站接收到流量，都會發出一個 RST 數據包。然後客戶端所做的取決於更高級別的協議，可能會發出重新連接嘗試。這通常是由 TCP/IP 堆棧本身默默地失去連接狀態引起的。就堆棧而言，來自客戶端的數據包與任何打開的連接都沒有關聯，因此它只是發出一個 RST 數據包並忽略它。
重置新的連接嘗試
現有連接繼續工作，但 SYN 數據包以 RST 回复。在正常操作中，這是因為 SYN 數據包上列出的埠沒有開放埠。這通常是由更高級別的應用程序中的故障引起的。
至於您的重傳，這些是由於客戶端沒有收到他們期望獲得的數據包造成的。這可能是由徹底的封包遺失引起的，也可能是伺服器根本沒有發送這些數據包。如果您在伺服器上的嗅探顯示重傳數據包，並且列出會話顯示伺服器沒有發送數據包，則表明伺服器本身出現問題。這可能與更高級別的應用程序、TCP/IP 堆棧或 NIC 驅動程序本身的故障有關。我已經看到 NIC 驅動程序更新解決了這個問題，但在不太可能成為問題根源的 VM 中。像這樣的大規模重置可能是由伺服器的資源耗盡引起的。