第三章传输层.pptVIP

第三章: 傳輸層 章節目標： 了解傳輸層所提供的服務之背後原理： 多工傳輸/分工傳輸 可靠的資料傳輸 流量控制 擁塞控制 在網際網路上舉例說明以及實做 章節概要： 傳輸層的服務 多工傳輸/分工傳輸 無連接傳輸模式： UDP 可靠的資料傳輸原理 連接導向傳輸： TCP 可靠的資料傳輸 流量控制 連接管理 擁塞控制原理 TCP 擁塞控制 傳輸服務及協定 提供在不同的主機上執行的應用程序一種邏輯式的通訊方式 傳輸層是在每個末端主機上運行 傳輸層 vs 網路層服務： 網路層： 資料是在主機與主機間做傳輸 傳輸層： 資料是在程序與程序間作傳輸 必須依賴網路層服務 傳輸層通訊協定 網際網路傳輸服務： 可靠的, 按照順序的單撥(unicast) 傳輸 ：TCP 擁塞 流量控制 連線設定 不可靠的 (最省力式 “best -effort”), 不按照順序的單撥或多撥(multicast) 傳輸：UDP 不可用的服務： 即時服務 頻寬保證 可靠的多撥 多工傳輸/分工傳輸 回想： 資料段 – 在傳輸層實體間作交換的資料單元 aka TPDU: 傳輸層資料單元 多工傳輸/分工傳輸 多工傳輸/分工傳輸： 以傳送者、接收者的連接埠號、IP位置為基準 每個資料段中，傳送者、接收者的連接埠號 回想：特定的應用軟體具有廣為了解的埠號 多工傳輸/分工傳輸：範例 UDP: 用戶資料訊息協定 [RFC 768] “no frills,” “bare bones” 網路傳輸協定 “最省力式” 服務, UDP 資料段可能形式為： 易遺失的 傳送不按照順序排列的資料段給應用程式 非連線導向式： UDP傳送者與接收者之間沒有互相交換控制訊息 每個 UDP 資料段自己獨立地操作 為什麼會有UDP ? 無需建立連線 (建立連線可能會增加delay) 簡單： 沒有連線狀態記錄在傳送者與接收者上 資料段標頭欄很小 沒有擁塞控制： UDP 可以如同疾風般地快速散撥資料段 UDP: 更多資訊 通常用於多媒體資料串流應用程式上 能容忍資料段遺失 對速率相當敏感 其他 UDP 的使用 (為什麼要用UDP?): DNS 網域名稱系統 SNMP 簡易網路管理協定 在UDP上做可靠傳輸： 在應用層增加可靠度 特殊應用程式錯誤回復! UDP 加總檢查 傳送者： 將資料段中的內容看成連續的16位元整數 加總檢查：將資料段中內容相加 (1’s complement sum) 傳送者將加總檢查值放入UDP加總檢查欄中 接收者： 計算收到資料段的加總檢查 查看是否算出來的值跟加總檢查欄中的值相同： NO – 偵測到錯誤 YES – 沒有偵測到錯誤. 但是可能仍然有錯誤? 接下來繼續討論 …. 可靠資料傳輸原理 在應用、傳輸、連結層具有很大的重要性 前十大重要的網路論題! 不可靠的頻道之特性, 將會決定可靠資料傳輸協定(rdt)的複雜度。 可靠資料傳輸：開端 可靠資料傳輸：開端 我們將會： 漸增地開發傳送端與接收端的可靠資料傳輸協定(rdt) 考慮只有單向的資料傳輸 但是控制資訊將會雙向傳送! 利用有限狀態機(FSM)來詳細說明傳送端與接收端 Rdt1.0: 在可靠頻道上作可靠傳輸 底層的頻道絕對可靠 沒有位元錯誤 沒有封包遺失 分開討論傳送端與接收端的有限狀態機 : 傳送端將資料送入底層的頻道 接收端從底層的頻道讀取資料 Rdt2.0: 利用錯誤位元的頻道 底層的頻道可能會使封包中的位元發生錯誤 回想： UDP 加總檢查去偵測錯誤位元 問題: 如何從錯誤中回復: 認可 (ACKs): 接收端會明確地告訴傳送端封包已接收完成 否定認可 (NAKs): 接收端會明確地的告訴傳送端封包有錯誤 在接收到否定認可之後，傳送端會重新傳送封包 人類的劇本也是有認可跟否定認可嗎? rdt2.0 的新機制(beyond rdt1.0): 錯誤偵測 接收端回饋: 控制訊息 (認可,否定認可) 接放端-傳送端 rdt2.0: 詳述有限狀態機 rdt2.0:運作中的情形 (沒有錯誤發生) rdt2.0: 運作中的情形(有錯誤發生) rdt2.0 有一個潛在的缺點! 假如 ACK/NAK發生毀損會發生什麼? 傳送端並不知道接收端發生什麼情況! 不是僅僅重送: 可能造成重覆 What to do? 傳送端 認可/否定 接收端的 ACK/NAK? 如果傳送端的ACK/NAK遺失該怎麼辦? 重送, 但是可能造成正確被接收的封包再一次重送！ 處理重複的封包： 傳送端加入 順序編號 到每一個封包 假如ACK/NAK毀損，則傳送端重傳現在的封包 接收端丟棄 (doesn’t deliver up) 重覆的封包 rdt2.1: sender, handles garbled