計算機網絡 運輸層（二）TCP的實現

計算機網絡（十三）

學習計算機網絡過程中的心得體會以及知識點的整理，方便我自己查找，也希望可以和大家一起交流。

—— 運輸層 ——

上接《計算機網絡 運輸層（一）》

《計算機網絡 運輸層（一）》

5 TCP 報文段的首部格式

• TCP 雖然是面向字節流的，但 TCP 傳送的數據單元卻是報文段。
• 一個 TCP 報文段分爲首部和數據兩部分，而 TCP 的全部功能都體現在它首部中各字段的作用。
• TCP 報文段首部的前 20 個字節是固定的，後面有 4n 字節是根據需要而增加的選項 (n 是整數)。因此 TCP 首部的最小長度是 20 字節。
  
  
  
  
  
  
  
  
  
  
  

5.1 爲什麼要規定 MSS

• MSS 與接收窗口值沒有關係。
• 若選擇較小的 MSS 長度，網絡的利用率就降低。
• 當 TCP 報文段只含有 1 字節的數據時，在 IP 層傳輸的數據報的開銷至少有 40 字節(包括 TCP 報文段的首部和 IP 數據報的首部)。這樣，對網絡的利用率就不會超過 1/41。到了數據鏈路層還要加上一些開銷。
• 若 TCP 報文段非常長，那麼在 IP 層傳輸時就有可能要分解成多個短數據報片。在終點要把收到的各個短數據報片裝配成原來的 TCP 報文段。當傳輸出錯時還要進行重傳。這些也都會使開銷增大。
• 因此，MSS 應儘可能大些，只要在 IP 層傳輸時不需要再分片就行。
• 由於 IP 數據報所經歷的路徑是動態變化的，因此在這條路徑上確定的不需要分片的 MSS，如果改走另一條路徑就可能需要進行分片。
• 因此最佳的 MSS 是很難確定的。

5.2 其他選項

• 窗口擴大選項 ——佔 3 字節，其中有一個字節表示移位值 S。新的窗口值等於 TCP 首部中的窗口位數增大到 (16 + S)，相當於把窗口值向左移動 S 位後獲得實際的窗口大小。
• 時間戳選項——佔 10 字節，其中最主要的字段時間戳值字段（4 字節）和時間戳回送回答字段（4 字節）。
• 選擇確認選項——在後面介紹。

6 TCP 可靠傳輸的實現

6.1 以字節爲單位的滑動窗口

• TCP 的滑動窗口是以字節爲單位的。
• 現假定 A 收到了 B 發來的確認報文段，其中窗口是 20 字節，而確認號是 31（這表明 B 期望收到的下一個序號是 31，而序號 30 爲止的數據已經收到了）。
• 根據這兩個數據，A 就構造出自己的發送窗口，
  
  
  
  
  
  

6.1.1 發送緩存與接收緩存的作用

• 發送緩存用來暫時存放：
  • 發送應用程序傳送給發送方 TCP 準備發送的數據；
  • TCP 已發送出但尚未收到確認的數據。
• 接收緩存用來暫時存放：
  • 按序到達的、但尚未被接收應用程序讀取的數據；
  • 不按序到達的數據。

【注意】

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

6.1.2 接收方發送確認

• 接收方可以在合適的時候發送確認，也可以在自己有數據要發送時把確認信息順便捎帶上。
• 但請注意兩點：
  • 第一，接收方不應過分推遲發送確認，否則會導致發送方不必要的重傳，這反而浪費了網絡的資源。。
  • 第二，捎帶確認實際上並不經常發生，因爲大多數應用程序很少同時在兩個方向上發送數據。

6.2 超時重傳時間的選擇

• 重傳機制是 TCP 中最重要和最複雜的問題之一。
• TCP 每發送一個報文段，就對這個報文段設置一次計時器。
• 只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。
• 重傳時間的選擇是 TCP 最複雜的問題之一。

6.2.1 TCP 超時重傳時間設置

• 如果把超時重傳時間設置得太短，就會引起很多報文段的不必要的重傳，使網絡負荷增大。
• 但若把超時重傳時間設置得過長，則又使網絡的空閒時間增大，降低了傳輸效率。
• TCP 採用了一種自適應算法，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間 RTT。

6.2.2 加權平均往返時間

• TCP 保留了 RTT 的一個加權平均往返時間 RTT_S（這又稱爲平滑的往返時間）。
• 第一次測量到 RTT 樣本時，RTTS 值就取爲所測量到的 RTT 樣本值。以後每測量到一個新的 RTT 樣本，就按下式重新計算一次 RTT_S：
  
• 式中，0<α<1。若 α 很接近於零，表示 RTT 值更新較慢。若選擇α 接近於 1，則表示 RTT 值更新較快。
• RFC 2988 推薦的 α 值爲 1/8，即 0.125。

6.2.2 超時重傳時間 RTO

• RTO (Retransmission Time-Out) 應略大於上面得出的加權平均往返時間 RTT_S。
• RFC 2988 建議使用下式計算 RTO：
  
• RTT_D 是 RTT 的偏差的加權平均值。
• RFC 2988 建議這樣計算 RTT_D。第一次測量時，RTT_D 值取爲測量到的 RTT 樣本值的一半。在以後的測量中，則使用下式計算加權平均的 RTT_D：
  
• β個小於 1 的係數，其推薦值是 1/4，即 0.25。

6.2.3 往返時間 (RTT) 的測量

往返時間 (RTT) 的測量相當複雜

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

6.2.4 Karn 算法

• 在計算平均往返時間 RTT 時，只要報文段重傳了，就不採用其往返時間樣本。
• 這樣得出的加權平均平均往返時間 RTT_S 和超時重傳時間 RTO 就較準確。
• 但是，這又引起新的問題。當報文段的時延突然增大了很多時，在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據 Karn 算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。

修正的 Karn 算法

• 報文段每重傳一次，就把 RTO 增大一些：
  
• 係數 γ 的典型值是 2 。
• 當不再發生報文段的重傳時，才根據報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數值。
• 實踐證明，這種策略較爲合理。

6.2.5 接收到的字節流序號不連續

6.3 選擇確認 SACK

• 接收方收到了和前面的字節流不連續的兩個字節塊。
• 如果這些字節的序號都在接收窗口之內，那麼接收方就先收下這些數據，但要把這些信息準確地告訴發送方，使發送方不要再重複發送這些已收到的數據。

6.3.1 RFC 2018 的規定

• 如果要使用選擇確認，那麼在建立 TCP 連接時，就要在 TCP 首部的選項中加上“允許 SACK”的選項，而雙方必須都事先商定好。
• 如果使用選擇確認，那麼原來首部中的“確認號字段”的用法仍然不變。只是以後在 TCP 報文段的首部中都增加了 SACK 選項，以便報告收到的不連續的字節塊的邊界。
• 由於首部選項的長度最多隻有 40 字節，而指明一個邊界就要用掉 4 字節，因此在選項中最多隻能指明 4 個字節塊的邊界信息。

後續內容查看《計算機網絡 運輸層（三）》