TCP 可靠傳輸與流量控制的實現

TCP 可靠傳輸與流量控制的實現

一、TCP可靠傳輸的實現

現在所講的可靠傳輸是根據之前所說的可靠傳輸原理的實現，是現實中應用的技術。

1.1.以字節為單位的滑動窗口

如圖A端一份文件分為了多個字節，每個字節用帶有字節號的方塊表示。A需要把這份文件發個B，發送時文件先放入A的發送緩存中排隊，准備發送。B中有一個接收緩存，用於存放接收到的由文件分成的多個字節數據。

• 通信時，B要與A建立會話（連接）（TCP是面向連接的），建立連接時B計算機要根據自己的接收緩存的大小設定合適的接收窗口，單位為字節，並告訴A計算機。如圖中B的接收窗口設為20字節。
• A根據B告知的接收窗口大小設定字節的發送窗口為20個字節，二者要一致。
• 隨后A開始向B發送數據，第一個發送的數據包可以是由26_{28字節組成，不用等待B回復確認信息，繼續發送發送窗口中剩下的29}45字節數據。於是可以發出由29_{32字節組成的第二個數據包、由33}35字節組成的第三個數據包、由36~45字節組成的第四個數據包（組成一個數據包的字節數是不固定的）。

• A發出總共包含26_{45二十個字節的四個數據包，A在沒有收到B的確認信息前不能把發送窗口中26}35字節的數據刪除，因為由於網絡原因可能需要重發這些字節的數據。但是發送窗口外的數據不能繼續發送。
• 當B收到了前兩個數據包發現編號是連續的，就向A發送一個確認信息，表示已正確無誤接收了前7個字節數據並要求A發送第36個字節之后的數據，即確認號ACK=36；

• A收到B發出的確認信息之后，發送窗口刪除窗口中26_{32字節數據的緩存，並向右移動到33字節處。即46}52字節的數據進入發送窗口可以以數據包的形式向B發送。

• 緊接着B陸續接收到數據包2、3，並向A發送確認信息。由於已發送了數據包1的確認信息，所以B的接收窗口向右移動，把數據包1包含的26_{32字節數據移出接收窗口。這就相當於B計算機已經接收到了文件的26}32字節部分，相當於下載東西時的臨時文件，應用進程可讀取該部分。

如此循環，A的發送緩存和B的接收緩存會動態地清理空間，供發送窗口和接收窗口循環使用，直至把文件傳輸完成。這就是以字節為單位的滑動窗口實現的TCP可靠傳輸。

注意：

• A中，P3 – P1 = A 的發送窗口（又稱為通知窗口）；

  P2 – P1 = 已發送但尚未收到確認的字節數；

  P3 – P2 = 允許發送但尚未發送的字節數（又稱為可用窗口）。

• A 的發送窗口內的序號都已用完，但還沒有再收到確認，必須停止發送。

1.2.當存在數據包丟失情況下實現可靠傳輸

• A向B發送3個數據包，再發送過程中第二個數據包丟了，只有第一個和第三個數據包到達B。

• 26_{29連續字節數據到達B后，B向A發送確認數據包，其中ACK=30，A收到后相應地移動發送窗口；B只接收到30}35字節數據中的33_{35字節，於是向A發送確認數據包，其中有一個選擇性確認號SACK，告訴A端收到了33}35字節，只需要發送缺失的30_{32字節數據即可。最終B收到30}35連續的字節了，再向A發送確認數據包，其中ACK=36，A收到后再次移動發送窗口。

補充說明：

• A 的發送窗口並不總是和 B 的接收窗口一樣大（因為有一定的時間滯后）。
• TCP 標准沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到后，再按序交付上層的應用進程。
• TCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。

---

二、超時重傳時間的選擇

2.1.加權平均往返時間RTT

TCP 每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。

由於網絡的通暢情況隨時間變化，所以數據往返時間RTT是變化的。采用以下公式計算新的平均往返時間。

• 式中RTTs表示加權平均往返時間 （又稱為平滑的往返時間），即傳輸數據時多次往返時間RTT的平均值。
• 式中，0 < a < 1。若 a 接近於零，表示新RTTs值較依賴舊RTT值，說明 RTT 值更新較慢，網速穩定；若選擇 a 接近於 1，表示新RTTs值較依賴新RTT值，說明 RTT 值更新較快，網速不穩定。
• RFC 2988 推薦的 a 值為 1/8，即 0.125。

2.2.超時重傳時間 RTO (RetransmissionTime-Out)

• RTO 應略大於上面得出的加權平均往返時間 RTTs。

• RFC 2988 建議使用下式計算 RTO：

  ​ RTO = RTTs + 4 x RTTd

• RTTd 是 RTT 的偏差的加權平均值。

• RFC 2988 建議這樣計算 RTTd。第一次測量時，RTTd 值取為測量到的 RTT 樣本值的一半。在以后的測量中，則使用下式計算加權平均的 RTTd：

• β 是個小於 1 的系數，其推薦值是 1/4，即 0.25。

**往返時間的測量相當復雜 **

• TCP 報文段 1 沒有收到確認。重傳（即報文段 2）后，收到了確認報文段 ACK。
• 如何判定此確認報文段是對原來的報文段 1 的確認，還是對重傳的報文段 2 的確認？

2.3.Karn 算法

• 在計算平均往返時間 RTT 時，只要報文段重傳了，就不采用其往返時間樣本。
• 這樣得出的加權平均平均往返時間 RTTS 和超時重傳時間 RTO 就較准確。

2.4.修正的 Karn 算法

• 報文段每重傳一次，就把 RTO 增大一些：

• 系數 g 的典型值是 2 。

• 當不再發生報文段的重傳時，才根據報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數值。

• 實踐證明，這種策略較為合理。

2.5.選擇確認 SACK (Selective ACK)

• 接收方收到了和前面的字節流不連續的兩個字節塊。
• 如果這些字節的序號都在接收窗口之內，那么接收方就先收下這些數據，但要把這些信息准確地告訴發送方，使發送方不要再重復發送這些已收到的數據。
• RFC 2018 的規定：
  • 如果要使用選擇確認，那么在建立 TCP 連接時，就要在 TCP 首部的選項中加上“允許 SACK”的選項，而且雙方必須都事先商定好。
  • 如果使用選擇確認，那么原來首部中的“確認號字段”的用法仍然不變。只是以后在 TCP 報文段的首部中都增加了 SACK 選項，以便報告收到的不連續的字節塊的邊界。
  • 由於首部選項的長度最多只有 40 字節，而指明一個邊界就要用掉 4 字節，因此在選項中最多只能指明 4 個字節塊的邊界信息。

---

三、TCP的流量控制

3.1.利用滑動窗口實現流量控制

• 一般說來，我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快，接收方就可能來不及接收，這就會造成數據的丟失。

• 流量控制(flow control)就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞。

• 流量控制舉例：

A 向 B 發送數據。在連接建立時，B 告訴 A：“我的接收窗口 rwnd = 400（字節）”。

由圖可知，利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制。