# 網絡基本功（二十六）：Wireshark抓包實例分析TCP窗口及reset **轉載請在文首保留原文出處：EMC中文支持論壇**[https://community.emc.com/go/chinese](https://community.emc.com/go/chinese) [](https://community.emc.com/servlet/JiveServlet/showImage/2-867817-107581/image001.gif) ## 介紹 TCP最重要的機制之一是滑動窗口機制，以及用以控制TCP終端節點愿意接收的數據總量的流控機制。 TCP reset可以在幾種情況下被發送。有一些是協議的正常工作過程，有一些則表明可能有問題。本節中，我們查找問題以及分析解決問題的方法。 本章討論以上兩個問題。 ## 更多信息 **TCP窗口問題:** TCP零窗口，零窗口探測，零窗口違例 TCP零窗口發生于接收方在TCP頭部的window字段廣播接收窗口零字節的時候。這一事件告知發送方停止發送數據，因為接收方緩存已滿。這也表明接收方可能發生以下問題： * 服務器無法為進程分配組后的內存 * 應用碰到沒有足夠內存的問題，因此TCP需告知發送方停止發送數據 * 應用消耗太多內存因此操作系統要限制應用資源 TCP零窗口探測由發送方發出，以查看接收方的零窗口是否依然存在。這一消息通過發送下一字節數據給接收方，如果接收方回復窗口大小仍然為零，則發送方的探測計時器加倍。 TCP窗口違例：發送方忽略接收方的零窗口大小并發送額外字節數據。TCP零窗口違例表明協議棧中有TCP錯誤。為了檢查是何問題，檢查是否有以下事件： * 某一終端設備（服務器或客戶機）報出終端設備故障 * 某一應用報出常規應用錯誤 * 應用中執行某一操作時報錯，例如，打開一個表格，發送一份文件至打印機，創建一個報告，或其他操作。這種情況下，是應用問題。 TCP窗口更新 TCP將窗口更新發送至連接的對端，以表明緩存大小更改，并且準備好接受更高或更低的數據速率（緩存大小決定了發送方被允許的發送速率）。這一情況發生于： * TCP接收方從零窗口中恢復，告知發送方重新發送速率。這一情況下，無需進行處理，只需檢查第一次導致零窗口的問題。 * TCP接收方頻繁更改窗口大小。該情況下檢查接收方被干擾的原因。可能是應用問題，內存問題，或終端設備上的其他問題。 看到這類現象無需擔心，這就是TCP的工作機制。 TCP窗口已滿 這一信息表明已發送的報文會完全填滿接收方的接收緩存。發生于接收方沒有對先前接收到的數據發出任何ACK確認信息，因此，這將會成為發送方從接收方收到ACK之前的最后一個報文數據。 這一事件的觸發原因與觸發零窗口的原因相同，是服務器或應用無響應的標志。典型實例如下圖所示： [](https://community.emc.com/servlet/JiveServlet/showImage/2-867817-107582/image002.jpg) 上圖中可以看到： 1. 報文183816，192.168.2.138告知192.168.1.58發送窗口已滿。 2. 下一個報文，192.168.1.58發送一個信號至192.168.2.138，告知對方停止發送數據。這是一個零窗口信號。 3. 雙方繼續發送零窗口以及零窗口探測。 4. 連接的最后一個報文是192.168.2.138發送的RST報文，目的是斷開連接。 5. 某些情況下零窗口可以通過窗口更改信息來回復。某些情況下可通過reset來關閉（可以是應用零窗口從而沒有收到任何數據導致）。 工作原理 TCP滑動窗口機制如下： 1. 連接建立之后，發送方將數據發送至接收方，填入接收窗口。 2. 若干報文之后，接收方發送ACK至發送方，確認接收到其發送的字節數。發送ACK將接收窗口清零。 3. 這一過程持續下去，發送方向窗口中填入數據，接收方清空并發送確認信息。 4. 擴大接收窗口大小告知發送方增加吞吐量，減小窗口告知對方減小吞吐量。這一機制按照WS/RTT規則（隨著TCP版本不同而有所改變）： [](https://community.emc.com/servlet/JiveServlet/showImage/2-867817-107583/image003.jpg) 也可以通過TCP吞吐量圖表和IO圖來查看問題。在TCP吞吐量圖表中，使用TCP trace圖表，上面一行顯示了窗口大小，與下面一行的距離表明窗口的剩余大小。沒有距離表示零窗口。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-867817-107584/image004.jpg) 兩行之間的固定距離表明接收方工作良好。當兩行漸漸靠近，表明發送方速度高于接收方。只要這兩行沒有重疊，TCP就會繼續發送數據。 **TCP reset及原因:** 在可疑的鏈路或服務器兩端連接Wireshark，開始抓包。觀察抓包窗口的每一個窗口信息。TCP reset可以在幾種情況下被發送。有一些是協議的正常工作過程，有一些則表明可能有問題。本節中，我們查找問題以及分析解決問題的方法。 reset是用以告知接收方斷開連接的TCP信號，通過將RST標志位置1來發送。正常的操作過程中，TCP通過SYN信號打開連接，通過FIN信號關閉連接。TCP的一大特性在于有問題時，或只是為了更好的性能，它能夠快速關閉連接。 無故障時發送reset TCP關閉連接的標準方式是通過FIN和FIN-ACK信號。為了關閉連接，用戶需要四個報文：來自一方的FIN/ACK和ACK，以及另一方的同樣報文。當你打開一個網頁，可能同時打開了數十個連接（主頁，新聞，廣告，定期更新的圖片等），要關閉所有這些有時需要數百個FIN和FIN-ACK報文。為了防止其發生，web服務器在很多情況下會在發送請求數據之后用reset斷開連接。這是標準的做法，并取決于應用程序。 有故障時發送reset 某些情況下reset表明有故障發生（并不一定是通信故障）： * **防火墻發送的reset**：當遠端服務器嘗試打開連接但沒有結果時，也許會看到返回RST信號。這是防火墻阻隔連接的情況。下圖中，可看到發送的每一個SYN都返回以RST。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-867817-107585/image005.jpg) * **由于收發一方有問題發送的reset**：可能的原因如： * 五個連續沒有收到ACK回復的重傳。當發送方沒有收到任何重傳回復，它就會發送一個reset信號到對端，告知其斷開連接。 * 另一個原因是連接之上幾分鐘都沒有任何數據（分鐘數取決于系統默認）。打開連接的一方通常會發送reset（但并不總是會這樣做，取決于實現方式）。 ## 參考 Network Analysis Using Wireshark Cookbook