網絡基本功（八）：細說TCP滑動窗口

網絡基本功（八）：細說TCP滑動窗口

 

轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese 

 

介紹

 

將TCP與UDP這樣的簡單傳輸協議區分開來的是它傳輸數據的質量。TCP對於發送數據進行跟蹤，這種數據管理須要協議有如下兩大關鍵功能：

可靠性：保證數據確實到達目的地。若是未到達，可以發現並重傳。

數據流控：管理數據的發送速率，以使接收設備不致於過載。

要完成這些任務，整個協議操做是圍繞滑動窗口確認機制來進行的。所以，理解了滑動窗口，也就是理解了TCP。

更多信息

 

TCP面向流的滑動窗口確認機制:

 

TCP將獨立的字節數據看成流來處理。一次發送一個字節並接收一次確認顯然是不可行的。即便重疊傳輸（即不等待確認就發送下一個數據），速度也仍是會很是緩慢。

TCP消息確認機制如上圖所示，首先，每一條消息都有一個識別編號，每一條消息都可以被獨立地確認，所以同一時刻能夠發送多條信息。設備B按期發送給A一條發送限制參數，制約設備A一次能發送的消息最大數量。設備B能夠對該參數進行調整，以控制設備A的數據流。

爲了提升速度，TCP並無按照字節單個發送而是將數據流劃分爲片斷。片斷內全部字節都是一塊兒發送和接收的，所以也是一塊兒確認的。確認機制沒有采用message ID字段，而是使用的片斷內最後一個字節的sequence number。所以一次能夠處理不一樣的字節數，這一數量即爲片斷內的sequence number。

 

TCP數據流的概念劃分類別

假設A和B之間新創建了一條TCP鏈接。設備A須要傳送一長串數據流，但設備B沒法一次所有接收，因此它限制設備A每次發送分段指定數量的字節數，直到分段中已發送的字節數獲得確認。以後，設備A能夠繼續發送更多字節。每個設備都對發送，接收及確認數據進行追蹤。

若是咱們在任一時間點對於這一過程作一個「快照」，那麼咱們能夠將TCP buffer中的數據分爲如下四類，並把它們看做一個時間軸：

1.    已發送已確認 數據流中最先的字節已經發送並獲得確認。這些數據是站在發送設備的角度來看的。以下圖所示，31個字節已經發送並確認。

2.    已發送但還沒有確認 已發送但還沒有獲得確認的字節。發送方在確認以前，不認爲這些數據已經被處理。下圖所示14字節爲第2類。

3.    未發送而接收方已Ready 設備還沒有將數據發出，但接收方根據最近一次關於發送方一次要發送多少字節確認本身有足夠空間。發送方會當即嘗試發送。如圖，第3類有6字節。

4.    未發送而接收方Not Ready 因爲接收方not ready，還不容許將這部分數據發出。

接收方採用相似的機制來區分已接收並已確認，還沒有接受但準備好接收，以及還沒有接收並還沒有準備好接收的數據。實際上，收發雙方各自維護一套獨立的變量，來監控發送和接收的數據流落在哪一類。

 

Sequence Number設定與同步：

 

發送方和接收方必須就它們將要爲數據流中的字節指定的sequence number達成一致。這一過程稱爲同步，在TCP鏈接創建時完成。爲了簡化假設第一個字節sequence number是1，按照上圖示例，四類字節以下：

1.     已發送已確認字節1至31。

2.     已發送但還沒有確認字節32至45。

3.     未發送而接收方已Ready字節46至51。

4.     未發送而接收方Not Ready字節52至95。

 

發送窗口與可用窗口：

 

整個過程關鍵的操做在於接收方容許發送方一次能容納的未確認的字節數。這稱爲發送窗口，有時也稱爲窗口。該窗口決定了發送方容許傳送的字節數，也是2類和3類的字節數之和。所以，最後兩類（接收方準備好而還沒有發送，接收方未準備好）的分界線在於添加了從第一個未確認字節開始的窗口。本例中，第一個未確認字節是32，整個窗口大小是20。

可用窗口的定義是：考慮到正在傳輸的數據量，發送方仍被容許發送的數據量。實際上等於第3類的大小。左邊界就是窗口中的第一個字節（字節32），右邊界是窗口中最後一個字節（字節51）。概念的詳細解釋看下圖。

 

可用窗口字節發送後TCP類目與窗口大小的改變：

 

當上圖中第三類的6字節當即發送以後，這6字節從第3類轉移到第2類。字節變爲以下：

1.     已發送已確認字節1至31。

2.     已發送但還沒有確認字節32至51。

3.     未發送而接收方已Ready字節爲0。

4.     未發送而接收方Not Ready字節52至95。

 

確認處理以及窗口縮放：

 

過了一段時間，目標設備向發送方傳回確認信息。目標設備不會特別列出它已經確認的字節，由於這會致使效率低下。目標設備會發送自上一次成功接收後的最長字節數。

 

例如，假設已發送未確認字節（32至45）分爲4段傳輸：32-34，35-36，37-41，42-45。第1，2，4已經到達，而3段沒有收到。接收方只會發回32-36的確認信息。接收方會保留42-45但不會確認，由於這會表示接收方已經收到了37-41。這是很必要的，由於TCP的確認機制是累計的，只使用一個數字來確認數據。這一數字是自上一次成功接收後的最長字節數。假設目標設備一樣將窗口設爲20字節。

 

當發送設備接收到確認信息，則會將一部分第2類字節轉移到第1類，由於它們已經獲得了確認。因爲5個字節已被確認，窗口大小沒有改變，容許發送方多發5個字節。結果，窗口向右滑動5個字節。同時5個字節從第二類移動到第1類，5個字節從第4類移動至第3類，爲接下來的傳輸建立了新的可用窗口。所以，在接收到確認信息之後，看起來以下圖所示。字節變爲以下：

1.     已發送已確認字節1至36。

2.     已發送但還沒有確認字節37至51。

3.     未發送而接收方已Ready字節爲52至56。

4.     未發送而接收方Not Ready字節57至95。

每一次確認接收之後，這一過程都會發生，從而讓窗口滑動過整個數據流以供傳輸。

 

處理丟失確認信息：

 

可是丟失的42-45如何處理呢？在接收到第3段（37-41）以前，接收設備不會發送確認信息，也不會發送這一段以後字節的確認信息。發送設備能夠將新的字節添加到第3類以後，即52-56。發送設備以後會中止發送，窗口停留在37-41。

TCP包括一個傳輸及重傳的計時機制。TCP會重傳丟失的片斷。但有一個缺陷是：由於它不會對每個片斷分別進行確認，這可能會致使其餘實際上已經接收到的片斷被重傳（好比42至45）。