TCP發(fā)送窗口、接收窗口以及其工作原理

作者：小技術(shù)君 2023-11-10 16:28:02

網(wǎng)絡(luò) 無線技術(shù)

可用窗口的計算是理解TCP滑動窗口的關(guān)鍵，要了解可用窗口的計算，我們需要理解三個指針——SND.UNA、SND.NXT和RCV.NXT。

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

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

第3類也稱為可用窗口，因為這是發(fā)送方可以使用的窗口。

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

1*OqqxQKu4ZGasXzIlUZ9lyw.png

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

1*JdTCgvYpVPRDcLyVb8Rwsg.png

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

1*9zFu_scvenahSK6m-khSjw.png

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

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

1*IYBc3_OiPWAZ7JCvIaktkA.png

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

接收窗口

1*SbgJAvyVKyXYvPLuoBbGtA.png

接收窗口分為3個類別：

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

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

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

1*u3KoxvVK-rrM1g4gX6fbZQ.png

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

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

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

簡化的示例

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

有兩個修改簡化了我們的計算。

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

1*sAF4A2TyNeItzw2yK0xI9g.png

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

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

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

每一方都可以同時是發(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ù)這個公式，客戶端的可用窗口大小是1 + 300 - 1 = 300。

1*kfa6ZdhSR_VJggJ2abUSAQ.png

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

因為它已經(jīng)發(fā)送了300字節(jié)，SND.UNA和SND.NXT都指向301。

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

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

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

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

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

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

1*ug0laVIMWQ3HGG-kPjZ0KA.png

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

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

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

1*GAZqLwbVGj2yqUnm5DyI4w.png

移動到客戶端。

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

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

1*50UitYxS9XW3N4XV2Z7tOg.png

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

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

SND.NXT向右滑動了80個字節(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ù)時，RCV.NXT向右滑動。
其他指針保持不變。

可用窗口保持在300。

1*QJKwuY3HvslR9601ZRWCxA.png

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

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

1*thuJ7lCYqreqxsL8nMz_ag.png

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

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

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

1*8sS5S0OkW0I2Vbp40nkkZQ.png

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

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

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

1*qXP9BCX80vPpkplc5utP6Q.png

接下來，輪到客戶端。

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

可用窗口保持不變。

1*LkQ7tG-_1XQROjOZ3vTC9g.png

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

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

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

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

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

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