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字節。客戶端恢復傳送數據。

我們可以大概看一下上圖的模型：

首先是AB之間三次握手建立TCP連接。在報文的交互過程中，A將自己的緩沖區大小（窗口大小）3發送給B，B同理，這樣雙方就知道了對端的窗口大小。

A開始發送數據，A連續發送3個單位的數據，因為他知道B的緩沖區大小。在這一波數據發送完后，A就不能再發了，需等待B的確認。

A發送過來的數據逐漸將緩沖區填滿。

這時候緩沖區中的一個報文被進程讀取，緩沖區有了一個空位，于是B向A發送一個ACK，這個報文中指示窗口大小為1。
A收到B發過來的ACK消息，并且知道B將窗口大小調整為1，因此他只發送了一個單位的數據并且等待B的下一個確認報文。

如此反復。

總結

以上是生活随笔為你收集整理的TCP滑动窗口机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。