一站式學習Wireshark（五）：TCP視窗與擁塞處理

轉載請在文首保留原文出處：EMC中文支援論壇

介紹  

TCP通過滑動視窗機制檢測丟包，並在丟包發生時調整資料傳輸速率。滑動視窗機制利用資料接收端的接收視窗來控制資料流。

接收視窗值由資料接收端指定，以位元組數形式儲存於TCP報文頭，並告知傳輸裝置有多少資料將會儲存在TCP緩衝區。緩衝區就是資料暫時放置的地方，直至傳遞至應用層協議等待處理。因此，傳送端每次只能傳送Window Size欄位指定的資料量。為了使傳送端繼續傳送資料，接收端必須傳送確認資訊：之前的資料接收到了。同時必須對佔用緩衝區的資料進行處理以釋放快取空間。下圖顯示了接收視窗是如何工作的：

上圖中，客戶端向伺服器傳送資料，伺服器接收視窗是5000位元組。客戶端傳送了2500位元組，伺服器緩衝區還剩2500位元組，之後又傳送了2000位元組，從而緩衝區只剩500位元組。伺服器傳送確認資訊。對快取中資料進行處理並清空快取。此過程重複進行，客戶端又傳送3000位元組和1000位元組，伺服器快取減少至1000位元組，客戶端再次確認資料並處理快取中內容。

更多資訊  

調整視窗大小：

當TCP堆疊接收到資料的時候，生成一個確認資訊並以回覆的方式傳送，但是放置在接收端快取中的資料並不總是立即被處理。當伺服器忙於處理從多個客戶端接收的報文，伺服器很有可能因為清理快取而變得緩慢，無法騰出空間接收新的資料，如果沒有流控，則可能會造成丟包和資料損壞。好在，接收視窗所設定的速率無法使伺服器正常處理資料時，能夠調整接收視窗大小。通過減小返回給傳送端的ACK報文的TCP頭視窗大小值來實現。如下圖所示：

上圖中，伺服器初始視窗大小為5000位元組。客戶端傳送2000位元組，之後又傳送了2000位元組，緩衝區中只有1000位元組可用。伺服器意識到緩衝區正在快速填滿，它知道如果資料繼續以此速率傳輸，很快會有報文丟失。為了防止報文丟失，伺服器傳送確認資訊給客戶端，更新視窗大小為1000位元組。結果，客戶端減少資料傳送，伺服器以可以接受的速率處理快取內容，即保持資料流以穩定的速率傳輸。

調整視窗大小在兩個方向都是可行的。當伺服器能夠更加快速的處理報文時，它會發送一個較大視窗的ACK報文。

零視窗暫停資料流：

某些情況下，伺服器無法再處理從客戶端傳送的資料。可能是由於記憶體不足，處理能力不夠，或其他原因。這可能會造成資料被丟棄以及傳輸暫停，但接收視窗能夠幫助減小負面影響。

當上述情況發生時，伺服器會發送視窗為0的報文。當客戶端接收到此報文時，它會暫停所有資料傳輸，但會保持與伺服器的連線以傳輸探測（keep-alive）報文。探測報文在客戶端以穩定間隙傳送，以檢視伺服器接收視窗狀態。一旦伺服器能夠再次處理資料，將會返回非零值視窗大小，傳輸會恢復。下圖示例了零視窗通知過程。

伺服器初始接收資料視窗為5000位元組大小。從客戶端接收4000位元組資料之後，伺服器負載變得非常繁重，無法繼續處理客戶端任何資料。伺服器於是傳送視窗大小值為0的報文。客戶端暫停資料傳輸併發送一個探測報文。探測報文之後，伺服器回覆以告知客戶端現在可以接收資料的報文，以及視窗大小為1000位元組。客戶端恢復傳送資料。

TCP滑動視窗實戰：

本例中，開始從192.168.0.20傳送至192.168.0.30。我們關心的是視窗大小欄位，可以從Packet List面板的Info欄以及Packet Details的TCP報文頭看到。前三個報文後，可看到該值立刻減小，如下圖所示：

視窗大小值從第一個報文的8760位元組變成第二個報文的5840位元組到第三個報文的2920位元組①。視窗大小值的減小是主機延時的典型標誌。在時間欄注意到這一過程發生的非常迅速②。當視窗大小迅速減小的時候，通常就有可能下降為零。這就是第四個報文所發生的，如下圖所示：

第四個報文從192.168.0.20傳送至192.168.0.30，目的是告訴192.168.0.30它不再接收任何資料。0值見於TCP報文頭①，Wireshark的Packet List面板Info欄，以及TCP報文頭的SEQ/ACK Analysis欄位②也告訴我們這是一個0視窗報文。

一旦傳送了零視窗報文，192.168.0.30的裝置不會再發送任何資料，直到收到從192.168.0.20的視窗更新，告知視窗大小已經增加了。本例中導致零視窗的問題是暫時的，所以在下一個報文中傳送了視窗更新資訊，如下圖所示。

本例中，視窗大小增加到一個非常健康的數值64，240位元組①。Wireshark再次在SEQ/ACK Analysis告訴我們這是一個視窗更新。

一旦收到更新報文，192.168.0.30的主機就再次開始傳送資料，在報文6和報文7中。這一過程發生很快。如果它持續時間再長一點，就可能會導致網路的潛在中斷，引起資料傳輸減慢或失敗。

下一個關於滑動視窗的例子，第一個報文是正常HTTP，從195.81.202.68至172.31.136.85。此報文之後立刻跟隨一個從172.31.136.85傳送的零視窗報文，如下圖所示：

這與上一個例子中的零視窗報文十分類似，但結果顯著不同，172.31.136.85主機不是傳送一個視窗更新並回復通訊，而是一個探測報文，如下圖所示：

此報文被Wireshark標註為探測報文①。時間欄告訴我們這一報文發生於最後一個接收到的報文3.4秒之後。這一過程持續若干次，一端傳送零視窗報文另一端傳送探測報文，如下圖所示：

探測報文傳送間隙為3.4，6.8，13.5秒。這一過程可能會持續相當長一段時間，取決於通訊裝置的作業系統。該情況下，把時間欄的值加起來，通訊暫停了25秒。

TCP差錯控制和流控排查總結：

重傳報文

重傳的發生是由於客戶端檢測到伺服器沒有接收到它所傳送的資料。因此，取決於你所分析的是通訊的哪一端，有可能是看不見重傳的。如果從伺服器端抓取資料，並且它確實沒有接收到客戶端所傳送的和重傳報文，可能會一無所獲因為無法看見重傳報文。如果懷疑並不是伺服器端導致的報文丟失，可以考慮在客戶端嘗試抓取報文，以檢視實際是否有重傳發生。

重複ACK

可以將重複ACK看作重傳的“所謂相反面”，因為它是在伺服器檢測到客戶端傳送報文丟失的時候產生的。大多數情況下，在通訊兩端抓取流量時都可以看到重複ACK。需記住當接收報文亂序時會觸發重複ACK。例如，如果伺服器之接收到傳送的第一個和第三個報文，就會導致傳送重複ACK引起客戶端對第二個報文的快速重傳，因為你已經收到了第一個和第三個報文，因此不管導致第二個報文丟棄的原因是什麼，都很有可能是暫時的，因此大多數情況下重複ACK都會成功傳送和接收。當然，這種情形並不一定永遠會發生，因此當你懷疑在伺服器端丟失報文而又看不到任何重複ACK，考慮從通訊的客戶端抓取報文。

零視窗和探測報文

滑動視窗直接與伺服器無法接收和處理報文有關，任何視窗大小的縮小以及零值都是伺服器問題的直接結果。所以如果你在哪裡看到這兩者之一發生，就應該在那裡深入研究。通常應當在網路通訊兩端一直主機視窗更新報文。