計算機網絡自頂向下方法第3章-傳輸層 (Transport Layer).1

3.1 概述和運輸層服務

　　運輸層協議爲運行在不一樣主機上的應用進程之間提供了邏輯通訊(logic communication)功能。

　　3.1.1 運輸層和網絡層的關係

　　網絡層提供了主機之間的邏輯通訊，而運輸層爲運行在不一樣的主機上的進程提供了邏輯通訊。

　　3.1.2 因特網運輸層概述

　　Internet上提供TCP(傳輸控制協議) 和 UDP(用戶數據報協議)兩種

 3.2 多路複用和多路分解

　　 一個進程有一個或多個套接字（socket），它至關於從網絡向進程傳遞數據和從進程向網絡傳遞數據的門戶。

• 接收端將運輸層報文段中的數據交付到正確的套接字（即不一樣的進程）的工做稱爲多路分解（demultiplexing）。
• 而在源主機中從不一樣套接字中收集數據塊，併爲每一個數據塊封裝上頭部信息從而生成報文段，而後將報文段傳遞到網絡層，全部這些工做稱爲多路複用（multiplexing）。

　　1.無鏈接的多路複用與多路分解

　　在運輸層，無鏈接的網絡傳輸是經過UDP來實現的，一個UDP套接字是由一個含有目的IP地址和目的端口號的一個二元組來全面標識的。

　　主機收到UDP段後檢查段中的目的端口號，並將UDP段導向綁定在該端口號的Socket，所以若是兩個UDP報文段有不一樣的源IP地址/端口號，卻有相同的目的端口號，那麼兩個報文段將經過相同的目的套接字被定向到相同的目的進程。

　　2.面向鏈接的多路複用與多路分解

　　在運輸層中面向鏈接的網絡傳輸多使用TCP，而TCP套接字和UDP套接字之間有一個細微的差異，TCP套接字是由一個四元組（源IP地址、源端口號，目的IP地址，目的端口號）來標識的。當一個TCP報文段從網絡到達一臺主機時，主機會使用所有4個值來將報文段定向，即多路分解到相應的套接字。

　　與UDP不一樣的是，兩個具備不一樣源IP或源端口號的到達的TCP報文段將被重定向到兩個不一樣的套接字。

 

　　 3.Web服務器與TCP

 

　　當今的高性能Web服務器一般只使用一個進程，可是爲每一個新的客戶鏈接建立一個具備新鏈接套接字的新線程。

 

3.3 無鏈接運輸 : UDP

　　UDP的優點

•  應用層能更好發控制要發送的數據和發送時間。
•  無須創建鏈接。
•  無鏈接狀態。
•  分組首部開銷小。

　　3.3.1 UDP報文段結構

　　

　　UDP報文段結構由RFC 768定義，UDP首部只有4個字段，每一個字段由兩個字節組成。　　

• 源端口號： 本機（客戶端）的應用程序的套接字所對應的端口號，服務器端可利用此端口號向客戶端發送數據。
• 目的端口號： 服務端上的應用進程的套接字所對應的端口號，例如HTTP服務器的80端口。
• 長度：指明瞭首部和數據部分的UDP報文段的總長度，單位爲字節，即首部+數據。
• 檢驗和： 提供了差錯檢測功能，即檢驗和用於肯定當UDP報文段從源到達目的時，其中的比特是否發生了改變。

 　　3.3.2 UDP 檢驗和

• 發送方
  • 將段的內容視爲16-bit整數
  • 校驗和計算：計算全部整數的和，進位加在和的後面，將獲得的值按位求反，獲得校驗和
  • 發送方將校驗和放入校驗和字段
• 接收方
  • 計算所獲得段的檢驗和，並將其他檢驗和字段進行比較。
  • 若是不相等，則檢驗出錯誤，但若相等也可能有錯誤。

3.4 可靠數據傳輸原理

　　3.4.1 構造可靠數據傳輸協議

　　1.經徹底可靠信道的可靠數據傳輸 :rdt 1.0

　　有限狀態機(FSM) 能夠表示有限個狀態及在這些狀態之間的轉移和動做等行爲的數學模型，下圖即表示發送方和接收方的有限狀態機，底層信道是徹底可靠的，發送方和接收方有各自的FSM，每一個FSM都只有一個狀態。

　　（圖解：FSM描述中的箭頭指示了協議從一個狀態變遷到另外一個狀態。引發變遷的事件顯示在橫線的上方，事件發生時所採用的運動顯示在橫線的下方。FSM的初始狀態用虛線表示。）

　　

• 由於信道可靠，接收方也不須要提供任何反饋信息給發送方
• 假定了接收方接收數據的速率可以與發送方發送數據的速率同樣快，因此接收方也沒有必要請求發送方慢一點發送。

　　2.經具備比特差錯信道的可靠數據傳輸: rdt2.0

　　下圖爲rdt 2.0 的有限狀態機描述圖，該數據傳輸協議（自動重傳請求協議）採用了差錯檢測、確定確認與否認確認。

　　

• 在發送端左邊的初始狀態中，發送端協議正等待來自較高層傳下來的數據。當觸發 rdt_send(data) 事件時：
  • 經過 sndpkt = make_pkt(data, checksum) 產生一個包含待發送數據且帶有校驗和的分組
  • 而後將該分組經過 udt_send(sndpkt) 發送到信道中
• 執行完上述的兩個動做後，發送端的狀態變遷爲「等待接收接收端的 ACK 或 NAK 分組」。即轉變爲右側狀態，接下來根據接收端的響應不一樣會有不一樣的變遷方案：
  • 若是收到了一個 ACK 分組（rdt_rcv(rcvpkt) && isACK(rcvpkt)），那麼發送方知道最近一個分組已經被正確接收，所以協議返回左邊狀態，繼續等待下一次由較高層傳下來的數據發送請求
  • 若是收到了一個 NAK 分組（rdt_rcv(rcvpkt) && isNAK(rcvpkt)），那麼發送端知道接收端接收到的分組是受損的，因此調用 udt_send(sndpkt) 從新發送該分組，而後狀態不變，繼續等待接收接收端的 ACK 或 NAK 分組。

　　在上述協議中，當發送方處於等待ACK或NAK狀態時，它不能從上層得到更多數據。這樣子的協議被稱爲停等協議 (stop-and-wait)。

• rdt 2.0 的接收端仍然只有一個狀態。狀態變遷取決於收到的分組是否受損，有兩種方式：
  • 若是收到的分組受損，即 rdt_rcv(rcvpkt) && corrupt(rcvpkt)，則返回 NAK 分組
  • 若是收到的分組無缺，即 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)，則返回 ACK 分組
• 處理完後仍然返回自身這個狀態，繼續等待下一次從底層接收分組並處理。

　　3.經具備比特差錯的丟包信道的可靠數據傳輸 rdt 3.0

　　在現實的網絡環境中，除了比特受損外，底層信道還會丟包；有不少可能的方法能夠解決丟包問題，這裏咱們讓發送方負責檢測和恢復丟包工做。

　　假定發送端傳輸一個數據分組，該分組發生丟失 或者 接收端對該分組的 ACK 發生了丟失。在這兩種狀況下，發送端都收不到應當到來的接收端的響應。因此，若是發送端願意等待足夠長的時間以肯定該分組缺失已丟失，則它只須要重傳該數據分組便可。

　　從發送端的觀點來看，重傳是一個萬能靈藥。爲了實現基於時間的重傳機制，須要一個倒數計時器 (countdown timer)，在一個給定的時間量過時以後，可中斷髮送方。發送方須要作到：1）每次發送一個分組（包括第一次分組和重傳分組）時，就啓動一個定時器；2）相應定時器中斷；3）終止定時器。

　　下圖是rdt 3.0的發送方FSM，該協議運行在可能發生出錯和丟失的信道上。

 

 

　　rdt 2.2 協議中的接收端有限狀態機描述圖仍然適用於 rdt 3.0 協議，下面我仍然用文字來簡要描述一下上圖中的發送端發送分組流程：

• 首先由較高層觸發 rdt_send(data) 事件，經過 sndpkt = make_pkt(0, data, checksum) 產生一個序號爲 0，包含待發送數據且帶有校驗和的分組，接着經過 udt_send(sndpkt) 將其發送到信道中並啓動定時器，而後狀態變遷爲「等待接收接收端的 ACK 0」
• 當發送端在「等待接收接收端的 ACK 0」的時候：
  • 若是收到了受損的分組（即 corrupt(rcvpkt)）或者收到了 ACK 1（即 isACK(rcvpkt, 1)，也就是收到了本身發送的上一個分組的 ACK），則直接忽略
  • 若是定時器時間到，則由 udt_send(sndpkt) 從新發送該分組並從新啓動定時器
  • 若是收到了無缺的分組且 ACK 爲 0，那麼發送端知道接收端已經成功接收了剛纔發送的序號爲 0 的分組，直接中止定時器，此時發送端狀態變遷到等待較高層傳下來的數據發送請求
• 注意在繼續等待從較高層傳下來的數據發送請求的過程當中，若是收到了任何分組數據包，都直接忽略，由於它們必定是冗餘的

　　3.4.2 流水線可靠數據傳輸協議

　　停等協議可能會限制底層網絡硬件所提供的能力

　　解決方法是：不使用中止等待方式，運行發送方發送多個分組而無需等待確認。因爲許多從發送方向接收方輸送的分組能夠被當作是填充到一條流水線中，所以這種技術被稱爲流水線 (pipelining)。固然，流水線會增長協議的複雜度：

• 　必須增長序號範圍

　　由於信道中的分組要有一個惟一的序號，會有多個分組在信道中未被確認。

• 協議的發送方和接收方必須緩存多個分組

　　發送方至少應該緩存已經發送卻尚未被確認的分組。接受方也許應該緩存已經正確接收的分組。

• 所需的序號範圍和對緩存大小的要求取決於協議如何處理丟失、損壞及延時大的分組

　　解決流水線差錯錯誤的兩種基本思路：回退N步和選擇重傳。

　　3.4.3 回退N步

  　　GBN 協議被稱爲滑動窗口協議 (silding-window protocol)

　　3.4.4 選擇重傳

 　　選擇重傳協議讓發送方僅重傳那些它懷疑在接收方出錯的分組，避免了不須要的重傳。

 

參考:

http://www.javashuo.com/article/p-yuhpatdu-gx.html

http://www.javashuo.com/article/p-paehuxac-kw.html

https://www.cnblogs.com/huahuahu/p/liu-shui-xian-ke-kao-shu-ju-chuan-shu-xie-yi.html