計算機網絡中的帶寬、交換結點中的緩存和處理機等，都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞。這種情況就叫做擁塞。擁塞控制就是防止過多的數據注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載。擁塞控制是一個全局性的過程，和流量控制不同，流量控制指點對點通信量的控制。

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

　　接收窗口值由數據接收端指定，以字節數形式存儲于TCP報文頭，并告知傳輸設備有多少數據將會存儲在TCP緩沖區。緩沖區就是數據暫時放置的地方，直至傳遞至應用層協議等待處理。因此，發送端每次只能發送Window Size字段指定的數據量。為了使發送端繼續傳送數據，接收端必須發送確認信息：之前的數據接收到了。同時必須對占用緩沖區的數據進行處理以釋放緩存空間。下圖顯示了接收窗口是如何工作的：

　　上圖中，客戶端向服務器發送數據，服務器接收窗口是5000字節?？蛻舳税l送了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，考慮從通訊的客戶端抓取報文。

　　零窗口和探測報文

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

　　以上就是解決TCP窗口與擁塞控制的辦法，希望能幫到大家，謝謝閱讀。