網絡基本功（二十六）：Wireshark抓包實例分析TCP窗口及reset

網絡基本功（二十六）：Wireshark抓包實例分析TCP窗口及reset

 

轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese 

 

介紹

 

TCP最重要的機制之一是滑動窗口機制，以及用以控制TCP終端節點願意接收的數據總量的流控機制。

TCP reset能夠在幾種狀況下被髮送。有一些是協議的正常工做過程，有一些則代表可能有問題。本節中，咱們查找問題以及分析解決問題的方法。

本章討論以上兩個問題。

 

更多信息

 

TCP窗口問題:

 

TCP零窗口，零窗口探測，零窗口違例

TCP零窗口發生於接收方在TCP頭部的window字段廣播接收窗口零字節的時候。這一事件告知發送方中止發送數據，由於接收方緩存已滿。這也代表接收方可能發生如下問題：

• 服務器沒法爲進程分配組後的內存

• 應用碰到沒有足夠內存的問題，所以TCP需告知發送方中止發送數據

• 應用消耗太多內存所以操做系統要限制應用資源

 

TCP零窗口探測由發送方發出，以查看接收方的零窗口是否依然存在。這一消息經過發送下一字節數據給接收方，若是接收方回覆窗口大小仍然爲零，則發送方的探測計時器加倍。

 

TCP窗口違例：發送方忽略接收方的零窗口大小併發送額外字節數據。TCP零窗口違例代表協議棧中有TCP錯誤。爲了檢查是何問題，檢查是否有如下事件：

• 某一終端設備（服務器或客戶機）報出終端設備故障

• 某一應用報出常規應用錯誤

• 應用中執行某一操做時報錯，例如，打開一個表格，發送一份文件至打印機，建立一個報告，或其餘操做。這種狀況下，是應用問題。

 

TCP窗口更新

TCP將窗口更新發送至鏈接的對端，以代表緩存大小更改，而且準備好接受更高或更低的數據速率（緩存大小決定了發送方被容許的發送速率）。這一狀況發生於：

• TCP接收方從零窗口中恢復，告知發送方從新發送速率。這一狀況下，無需進行處理，只需檢查第一次致使零窗口的問題。

• TCP接收方頻繁更改窗口大小。該狀況下檢查接收方被幹擾的緣由。多是應用問題，內存問題，或終端設備上的其餘問題。

 

看到這類現象無需擔憂，這就是TCP的工做機制。

 

TCP窗口已滿

這一信息代表已發送的報文會徹底填滿接收方的接收緩存。發生於接收方沒有對先前接收到的數據發出任何ACK確認信息，所以，這將會成爲發送方從接收方收到ACK以前的最後一個報文數據。

 

這一事件的觸發緣由與觸發零窗口的緣由相同，是服務器或應用無響應的標誌。典型實例以下圖所示：

 

上圖中能夠看到：

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版本不一樣而有所改變）：

 

也能夠經過TCP吞吐量圖表和IO圖來查看問題。在TCP吞吐量圖表中，使用TCP trace圖表，上面一行顯示了窗口大小，與下面一行的距離代表窗口的剩餘大小。沒有距離表示零窗口。

兩行之間的固定距離代表接收方工做良好。當兩行漸漸靠近，代表發送方速度高於接收方。只要這兩行沒有重疊，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。

 

• 因爲收發一方有問題發送的reset：可能的緣由如：

  • 五個連續沒有收到ACK回覆的重傳。當發送方沒有收到任何重傳回復，它就會發送一個reset信號到對端，告知其斷開鏈接。

  • 另外一個緣由是鏈接之上幾分鐘都沒有任何數據（分鐘數取決於系統默認）。打開鏈接的一方一般會發送reset（但並不老是會這樣作，取決於實現方式）。