上面的圖表是從發(fā)送方的角度拍攝的快照。我們可以將數(shù)據(jù)分為4組：

• 已發(fā)送并已確認(rèn)的字節(jié)(藍(lán)色)
• 已發(fā)送但尚未確認(rèn)的字節(jié)(黃色)
• 未發(fā)送但接收方準(zhǔn)備好接收的字節(jié)(綠色)
• 未發(fā)送且接收方未準(zhǔn)備好接收的字節(jié)(灰色)

第3類也稱為可用窗口，因?yàn)檫@是發(fā)送方可以使用的窗口。

發(fā)送窗口包括黃色和綠色部分。這些字節(jié)要么已經(jīng)被發(fā)送，要么可以被發(fā)送。

1*OqqxQKu4ZGasXzIlUZ9lyw.png

可用窗口在發(fā)送方發(fā)送了21-25字節(jié)并使用了可用窗口中的所有字節(jié)時(shí)可能為空。發(fā)送窗口保持不變。

1*JdTCgvYpVPRDcLyVb8Rwsg.png

當(dāng)發(fā)送方接收到16-19字節(jié)的確認(rèn)時(shí)，發(fā)送窗口向右滑動(dòng)4個(gè)字節(jié)。隊(duì)列中的接下來的字節(jié)會(huì)有一個(gè)更新的可用窗口。

1*9zFu_scvenahSK6m-khSjw.png

一些定義可以幫助我們更好地理解本文后面的復(fù)雜情況：

• SND.WND，表示發(fā)送窗口
• SND.UNA，表示發(fā)送未確認(rèn)指針，指向發(fā)送窗口的第一個(gè)字節(jié)
• SND.NXT，表示發(fā)送下一個(gè)指針，指向可用窗口的第一個(gè)字節(jié)

1*IYBc3_OiPWAZ7JCvIaktkA.png

基于這些定義，我們可以用以下公式表示可用窗口的大小。

接收窗口

1*SbgJAvyVKyXYvPLuoBbGtA.png

接收窗口分為3個(gè)類別：

• 已接收并已確認(rèn)的字節(jié)
• 尚未接收但發(fā)送方允許發(fā)送的字節(jié)
• 尚未接收且發(fā)送方可能不允許發(fā)送的字節(jié)

第2類被稱為接收窗口，也可以稱為RCV.WND。

與發(fā)送窗口類似，有一個(gè)指針RCV.NXT，表示接收窗口的第一個(gè)字節(jié)。

1*u3KoxvVK-rrM1g4gX6fbZQ.png

接收窗口并非靜態(tài)。如果服務(wù)器運(yùn)行得高效，接收窗口可以擴(kuò)展。否則，它可能會(huì)縮小。

接收方通過在TCP段頭中的窗口字段中指示大小來傳達(dá)其接收窗口。當(dāng)發(fā)送方收到它時(shí)，這個(gè)窗口大小就成為了可用窗口。

發(fā)送和接收段需要時(shí)間。因此，接收窗口在特定時(shí)刻不等于可用窗口。

簡(jiǎn)化的示例

讓我們模擬一次請(qǐng)求和響應(yīng)，以更好地理解滑動(dòng)窗口的工作原理。

有兩個(gè)修改簡(jiǎn)化了我們的計(jì)算。

• 我們忽略了最大段大小(MSS)。MSS根據(jù)所選的網(wǎng)絡(luò)路由而變化。
• 我們使接收窗口等于可用窗口，而且在整個(gè)過程中都保持不變。

1*sAF4A2TyNeItzw2yK0xI9g.png

上面是一個(gè)顯示了10個(gè)步驟示例的圖表。

客戶端請(qǐng)求一個(gè)資源，服務(wù)器以三個(gè)段響應(yīng)它：

• 50字節(jié)的頭部
• 80字節(jié)的正文部分1
• 100字節(jié)的正文部分2

每一方都可以同時(shí)是發(fā)送方和接收方。

我們假設(shè)客戶端的發(fā)送窗口(SND.WND)為300字節(jié)，接收窗口(RCV.WND)為150字節(jié)。因此，服務(wù)器的SND.WND為150字節(jié)，RCV.WND為300字節(jié)。

1*cU9TEaEoezDwvw__3G1DFw.png

這是客戶端的起始狀態(tài)。

我們假設(shè)它之前已經(jīng)從服務(wù)器接收了300字節(jié)，因此RCV.NXT指向301。

由于它還沒有發(fā)送任何內(nèi)容，SND.UNA和SND.NXT都指向1。

1*IYBc3_OiPWAZ7JCvIaktkA.png

根據(jù)這個(gè)公式，客戶端的可用窗口大小是1 + 300 - 1 = 300。

1*kfa6ZdhSR_VJggJ2abUSAQ.png

這是服務(wù)器的起始狀態(tài)，反映了另一側(cè)的狀態(tài)。

因?yàn)樗呀?jīng)發(fā)送了300字節(jié)，SND.UNA和SND.NXT都指向301。

由于客戶端還沒有發(fā)送任何請(qǐng)求，RCV.NXT指向1。

服務(wù)器的可用窗口是301 + 150 - 301 = 150。

現(xiàn)在，第1步開始了。

客戶端發(fā)送了第一個(gè)100字節(jié)的請(qǐng)求。在這一刻，窗口發(fā)生了變化。

• 這100字節(jié)已發(fā)送但尚未確認(rèn)。因此，SND.NXT向右滑動(dòng)了100字節(jié)。
• 其他指針保持不變。

可用窗口變?yōu)? + 300 - 101 = 200。

1*ug0laVIMWQ3HGG-kPjZ0KA.png

在第2步，我們關(guān)注了服務(wù)器。

• 當(dāng)服務(wù)器接收到請(qǐng)求時(shí)，RCV.NXT向右滑動(dòng)了100字節(jié)。
• 然后發(fā)送了帶有ACK的50字節(jié)響應(yīng)。這50字節(jié)已發(fā)送但尚未確認(rèn)，所以SND.NXT向右移動(dòng)了50個(gè)字節(jié)。
• SND.UNA保持不變。

可用窗口變?yōu)?01 + 150 - 351 = 100。

1*GAZqLwbVGj2yqUnm5DyI4w.png

移動(dòng)到客戶端。

• 當(dāng)客戶端接收到50字節(jié)的響應(yīng)時(shí)，RCV.NXT向右滑動(dòng)了50字節(jié)。
• 當(dāng)它收到前面發(fā)送的100字節(jié)的ACK時(shí)，SND.UNA向右滑動(dòng)。
• 由于客戶端沒有發(fā)送任何數(shù)據(jù)，SND.NXT保持不變。

可用窗口變?yōu)?01 + 300 - 101 = 300。

1*50UitYxS9XW3N4XV2Z7tOg.png

再次移動(dòng)到服務(wù)器的一端。

可用窗口是100字節(jié)。服務(wù)器可以發(fā)送80字節(jié)的段。

• SND.NXT向右滑動(dòng)了80個(gè)字節(jié)。
• 由于前面的50字節(jié)尚未確認(rèn)，SND.UNA保持不變。
• 由于服務(wù)器未接收任何數(shù)據(jù)，RCV.NXT保持不變。

可用窗口變?yōu)?01 + 150 - 431 = 20。

1*soNJeyvqRj0zqDDrtBL9Fg.png

客戶端接收了文件的第一部分并立即發(fā)送了ACK。

• 當(dāng)客戶端接收到80字節(jié)的數(shù)據(jù)時(shí)，RCV.NXT向右滑動(dòng)。
• 其他指針保持不變。

可用窗口保持在300。

1*QJKwuY3HvslR9601ZRWCxA.png

此時(shí)，服務(wù)器在發(fā)送第2步時(shí)接收到ACK時(shí)。

• 當(dāng)服務(wù)器發(fā)送50字節(jié)的響應(yīng)時(shí)，SND.UNA向右滑動(dòng)了50個(gè)字節(jié)。
• 其他指針保持不變。

1*thuJ7lCYqreqxsL8nMz_ag.png

在第4步中，服務(wù)器發(fā)送了文件的第一個(gè)80字節(jié)部分，并再次收到了ACK確認(rèn)。

• SND.UNA(已確認(rèn)序列號(hào))向右移動(dòng)了80個(gè)字節(jié)。
• 其他指針保持不變。

可用窗口的計(jì)算變?yōu)?31 + 150 - 431 = 150。

1*8sS5S0OkW0I2Vbp40nkkZQ.png

在第8步，服務(wù)器發(fā)送了文件的第二部分，共100字節(jié)。

• SND.NXT(下一個(gè)要發(fā)送的序列號(hào))向右移動(dòng)了100個(gè)字節(jié)。
• 其他指針保持不變。

可用窗口的計(jì)算變?yōu)?31 + 150 - 531 = 50。

1*qXP9BCX80vPpkplc5utP6Q.png

接下來，輪到客戶端。

• RCV.NXT(下一個(gè)要接收的序列號(hào))在客戶端接收100字節(jié)后向右移動(dòng)了100個(gè)字節(jié)。
• 其他指針保持不變。

可用窗口保持不變。

1*LkQ7tG-_1XQROjOZ3vTC9g.png

最后，服務(wù)器接收了前一個(gè)響應(yīng)的ACK。

• SND.UNA向右移動(dòng)了100個(gè)字節(jié)。
• 其他指針保持不變。

可用窗口的計(jì)算變?yōu)?31 + 150 - 531 = 150。

當(dāng)窗口發(fā)生變化

在之前，我們假設(shè)發(fā)送窗口和接收窗口保持不變。但在實(shí)際情況中，這個(gè)假設(shè)是不正確的，因?yàn)閮蓚€(gè)窗口中的字節(jié)存在于操作系統(tǒng)緩沖區(qū)中，而緩沖區(qū)中的可用空間可以調(diào)整。當(dāng)我們的應(yīng)用程序無法快速讀取緩沖區(qū)中的字節(jié)時(shí)，可用空間會(huì)減小。

讓我們看看窗口發(fā)生變化的情況，以及它如何影響可用窗口。

1*qyjkUdkAdsfrkRkqVlPClw.png

為了簡(jiǎn)化，本例重點(diǎn)關(guān)注客戶端的可用窗口。在這個(gè)示例中，客戶端始終是發(fā)送方，服務(wù)器是接收方。

1*u3KoxvVK-rrM1g4gX6fbZQ.png

當(dāng)服務(wù)器發(fā)送ACK時(shí)，它還包括了更新后的窗口大小。

1*pkiC_TWGpIZF3aSPOz6lcA.png

一開始，客戶端發(fā)送了一個(gè)150字節(jié)的請(qǐng)求。

• 這150字節(jié)已發(fā)送但尚未得到確認(rèn)。
• 可用窗口縮小為150字節(jié)。
• 發(fā)送窗口保持在300字節(jié)。

1*zs4VuHChJJ-7vWFmXyr8Ug.png

當(dāng)服務(wù)器接收請(qǐng)求時(shí)，應(yīng)用程序讀取了前50字節(jié)，剩下的100字節(jié)仍然在緩沖區(qū)中，從接收窗口中占用了100字節(jié)的可用空間。因此，接收窗口縮小到了200字節(jié)。

接下來，服務(wù)器發(fā)送了一個(gè)帶有更新后的200字節(jié)接收窗口的ACK。

1*SZDl6q22CB6kzY3P-CCHFA.png

客戶端接收ACK并將其發(fā)送窗口大小更新為200。

此時(shí)，可用窗口與發(fā)送窗口相同，因?yàn)樗?50字節(jié)都已得到確認(rèn)。

1*6gKYyaDUdOQSEGfHh6SWdA.png

再次，客戶端發(fā)送了另一個(gè)200字節(jié)的請(qǐng)求，使用了可用窗口中的所有可用空間。

1*uJiRzHmdV4kT8lPW62bz0g.png

在服務(wù)器接收了這200字節(jié)之后，應(yīng)用程序仍然運(yùn)行緩慢，總共只讀取了70字節(jié)，將280字節(jié)留在緩沖區(qū)中。這導(dǎo)致接收窗口再次縮小，現(xiàn)在只剩下20字節(jié)。

在ACK消息中，服務(wù)器與客戶端分享了更新后的窗口大小。

1*xnUjR-R45hPoGO7qhvCHKg.png

再次，客戶端在收到ACK后將其發(fā)送窗口更新為20字節(jié)，可用窗口也變?yōu)?0字節(jié)。

在這種情況下，如果沒有更多來自服務(wù)器的消息，客戶端將停止發(fā)送大于20字節(jié)的請(qǐng)求，直到在后續(xù)消息中收到另一個(gè)窗口更新。

那么，如果沒有更多消息來自服務(wù)器，我們會(huì)被困在20字節(jié)的可用窗口嗎?

不會(huì)。為了避免這種情況，客戶端的TCP定期檢測(cè)窗口大小。

一旦釋放更多的空間，

可用窗口就會(huì)擴(kuò)大，可以發(fā)送更多的數(shù)據(jù)。

主要內(nèi)容

• 可用窗口的計(jì)算是理解TCP滑動(dòng)窗口的關(guān)鍵。
• 要了解可用窗口的計(jì)算，我們需要理解3個(gè)指針——SND.UNA、SND.NXT和RCV.NXT。
• 假設(shè)窗口大小永遠(yuǎn)不會(huì)改變可以幫助我們理解整個(gè)過程。