第三章传输层.ppt
《第三章传输层.ppt》由会员分享,可在线阅读,更多相关《第三章传输层.ppt(55页珍藏版)》请在三一文库上搜索。
1、3: Transport Layer,3a-1,第三章: 傳輸層,章節目標: 了解傳輸層所提供的服務之背後原理: 多工傳輸/分工傳輸 可靠的資料傳輸 流量控制 擁塞控制 在網際網路上舉例說明以及實做,章節概要: 傳輸層的服務 多工傳輸/分工傳輸 無連接傳輸模式: UDP 可靠的資料傳輸原理 連接導向傳輸: TCP 可靠的資料傳輸 流量控制 連接管理 擁塞控制原理 TCP 擁塞控制,3: Transport Layer,3a-2,傳輸服務及協定,提供在不同的主機上執行的應用程序一種邏輯式的通訊方式 傳輸層是在每個末端主機上運行 傳輸層 vs 網路層服務: 網路層: 資料是在主機與主機間做傳輸 傳
2、輸層: 資料是在程序與程序間作傳輸 必須依賴網路層服務,3: Transport Layer,3a-3,傳輸層通訊協定,網際網路傳輸服務: 可靠的, 按照順序的單撥(unicast) 傳輸 :TCP 擁塞 流量控制 連線設定 不可靠的 (最省力式 “best -effort”), 不按照順序的單撥或多撥(multicast) 傳輸:UDP 不可用的服務: 即時服務 頻寬保證 可靠的多撥,3: Transport Layer,3a-4,P2,多工傳輸/分工傳輸,回想: 資料段 在傳輸層實體間作交換的資料單元 aka TPDU: 傳輸層資料單元,接收者,H,t,分工傳輸: 傳送收到的資料段 到正確
3、的應用層程序中,segment,資料段,M,P1,P3,P4,資料段 標頭,應用層資料,3: Transport Layer,3a-5,多工傳輸/分工傳輸,多工傳輸/分工傳輸: 以傳送者、接收者的連接埠號、IP位置為基準 每個資料段中,傳送者、接收者的連接埠號 回想:特定的應用軟體具有廣為了解的埠號,從不同的應用程序中收集資料 ,由標頭將資料包住 (之後將 用於分工傳輸),來源端埠號,目的地端埠號,32 bits,應用程式 資料 (訊息),其他標頭區域,TCP/UDP 資料段格式,3: Transport Layer,3a-6,多工傳輸/分工傳輸:範例,主機 A,伺服器 B,使用的埠: 簡易遠
4、端登入應用程式,網路客戶端主機 A,網路 伺服器 B,網路客戶端主機 C,使用的埠: 網路伺服器,3: Transport Layer,3a-7,UDP: 用戶資料訊息協定 RFC 768,“no frills,” “bare bones” 網路傳輸協定 “最省力式” 服務, UDP 資料段可能形式為: 易遺失的 傳送不按照順序排列的資料段給應用程式 非連線導向式: UDP傳送者與接收者之間沒有互相交換控制訊息 每個 UDP 資料段自己獨立地操作,為什麼會有UDP ? 無需建立連線 (建立連線可能會增加delay) 簡單: 沒有連線狀態記錄在傳送者與接收者上 資料段標頭欄很小 沒有擁塞控制:
5、UDP 可以如同疾風般地快速散撥資料段,3: Transport Layer,3a-8,UDP: 更多資訊,通常用於多媒體資料串流應用程式上 能容忍資料段遺失 對速率相當敏感 其他 UDP 的使用 (為什麼要用UDP?): DNS 網域名稱系統 SNMP 簡易網路管理協定 在UDP上做可靠傳輸: 在應用層增加可靠度 特殊應用程式錯誤回復!,來源端埠號,目的地端埠號,32 bits,應用程式 資料 (訊息),UDP 資料段格式,長度,加總檢查,長度,在UDP 資料段中是 以位元組計 算 ,包含 標頭欄,3: Transport Layer,3a-9,UDP 加總檢查,傳送者: 將資料段中的內容看
6、成連續的16位元整數 加總檢查:將資料段中內容相加 (1s complement sum) 傳送者將加總檢查值放入UDP加總檢查欄中,接收者: 計算收到資料段的加總檢查 查看是否算出來的值跟加總檢查欄中的值相同: NO 偵測到錯誤 YES 沒有偵測到錯誤. 但是可能仍然有錯誤? 接下來繼續討論 .,目標:偵測傳送後的資料段中的”錯誤” (e.g., 錯誤位元),3: Transport Layer,3a-10,可靠資料傳輸原理,在應用、傳輸、連結層具有很大的重要性 前十大重要的網路論題!,不可靠的頻道之特性, 將會決定可靠資料傳輸協定(rdt)的複雜度。,3: Transport Layer,
7、3a-11,可靠資料傳輸:開端,傳送端,接收端,3: Transport Layer,3a-12,可靠資料傳輸:開端,我們將會: 漸增地開發傳送端與接收端的可靠資料傳輸協定(rdt) 考慮只有單向的資料傳輸 但是控制資訊將會雙向傳送! 利用有限狀態機(FSM)來詳細說明傳送端與接收端,造成狀態轉變的事件,狀態轉變時所要做的動作,狀態: 當身處於這個 ”狀態”時, 接下來將進入哪個狀態只能由下一個發生事件來決定,3: Transport Layer,3a-13,Rdt1.0: 在可靠頻道上作可靠傳輸,底層的頻道絕對可靠 沒有位元錯誤 沒有封包遺失 分開討論傳送端與接收端的有限狀態機 : 傳送端將
8、資料送入底層的頻道 接收端從底層的頻道讀取資料,3: Transport Layer,3a-14,Rdt2.0: 利用錯誤位元的頻道,底層的頻道可能會使封包中的位元發生錯誤 回想: UDP 加總檢查去偵測錯誤位元 問題: 如何從錯誤中回復: 認可 (ACKs): 接收端會明確地告訴傳送端封包已接收完成 否定認可 (NAKs): 接收端會明確地的告訴傳送端封包有錯誤 在接收到否定認可之後,傳送端會重新傳送封包 人類的劇本也是有認可跟否定認可嗎? rdt2.0 的新機制(beyond rdt1.0): 錯誤偵測 接收端回饋: 控制訊息 (認可,否定認可) 接放端-傳送端,3: Transport
9、Layer,3a-15,rdt2.0: 詳述有限狀態機,傳送端的有限狀態機,接收端的有限狀態機,3: Transport Layer,3a-16,rdt2.0:運作中的情形 (沒有錯誤發生),傳送端的有限狀態機,接收端的有限狀態機,3: Transport Layer,3a-17,rdt2.0: 運作中的情形(有錯誤發生),傳送端的有限狀態機,接收端的有限狀態機,3: Transport Layer,3a-18,rdt2.0 有一個潛在的缺點!,假如 ACK/NAK發生毀損會發生什麼? 傳送端並不知道接收端發生什麼情況! 不是僅僅重送: 可能造成重覆 What to do? 傳送端 認可/否定
10、 接收端的 ACK/NAK? 如果傳送端的ACK/NAK遺失該怎麼辦? 重送, 但是可能造成正確被接收的封包再一次重送!,處理重複的封包: 傳送端加入 順序編號 到每一個封包 假如ACK/NAK毀損,則傳送端重傳現在的封包 接收端丟棄 (doesnt deliver up) 重覆的封包,傳送端送出一個封包,然後 等待接收端的回應,3: Transport Layer,3a-19,rdt2.1: sender, handles garbled ACK/NAKs,3: Transport Layer,3a-20,rdt2.1: receiver, handles garbled ACK/NAKs,
11、3: Transport Layer,3a-21,rdt2.1: 討論,傳送端: 在封包中加入順序號碼 兩個順序號碼(0,1)足夠嗎?為什麼? 必需確定是否收到的錯誤的ACK/NAK 狀態數目的兩倍 狀態必需”記住”現在”的順序號碼是0還是1,接收端: 必需確定是否收到重覆的封包 狀態會指示預期的順序號碼是0或是1 注意: 接收端不知道它上次發送的ACK/NAK是否成功的送達傳送端,3: Transport Layer,3a-22,rdt2.2: a NAK-free protocol,某些函式如 rdt2.1只使用NAKs 接收端傳送ACK表示成功收到最後一個封包,而不用 接收端必需清楚的將
12、表示所回覆的封包順序號碼 傳送端收到重覆的ACK會做出和收到NAK相同的反應: 重送現在的封包,sender FSM,!,3: Transport Layer,3a-23,rdt3.0: 有錯誤和遺失的頻道,新的假設: 基礎的頻道也可能遺失封包(資料或是ACKs) 加總比對方法, 順序號碼, ACKs, 重新傳送,都有幫助,但並不足夠 Q: 如何處理遺失? 傳送端等待,直到有些資料或是ACK遺失再傳新傳送 缺點?,方法: send傳送端等待ACK,持續一段”合理”的時間 如果在這段時間內都沒有收到ACK,則開始重傳 如果封包 (或ACK) 只是延遲了 (不是遺失了): 重傳會造成重覆的封包,但
13、是利用順序號碼已經可以處理這個問題 接受端必需註明ACK是在回應哪個順序號碼的封包 需要有倒數計時器,3: Transport Layer,3a-24,rdt3.0 sender,3: Transport Layer,3a-25,rdt3.0 in action,3: Transport Layer,3a-26,rdt3.0 in action,3: Transport Layer,3a-27,Performance of rdt3.0,rdt3.0 可行,但效果不張 例子: 頻寬1 Gbps, 點對點傳輸延遲15 ms, 封包大小1KB:,每微秒送個1KB大小的封包msec - 則在頻寬為1
14、 Gbps 的連結上的吞吐量為33kB/秒 網路的通訊協訂限制了物理層的資源!,3: Transport Layer,3a-28,加入管線觀念的協定,管線觀念: send傳送端允許多個”正在傳送中”但還末被回覆ACK的封包 必需增加順序號碼的範圍 暫存在傳送端或是接收端,兩種使用管線觀念的協定: go-Back-N, selective repeat,3: Transport Layer,3a-29,Go-Back-N,傳送端: 在封包的標頭內包含了個位元的順序號碼 “視窗” 內最多允許有連續N 個尚末被回覆ack的封包,ACK(n): 回覆的ACKs所加註的順序號碼最多到n - “累計的 A
15、CK” 可能收到重覆的ACKs (端看傳送端) 為那些正在傳送中的封包設置一個計時器 超時(n): retransmit重傳順序號碼為n的封包及視窗內所有順序號碼大於n 的封包,3: Transport Layer,3a-30,GBN: sender extended FSM,3: Transport Layer,3a-31,GBN: receiver extended FSM,簡單的接收端: ACK-only: 總是回覆現在依照順序成功收到的封包裡,順序號碼最大的封包 可能產生重覆的ACKs 只需要記住預期的順序號碼 失序的封包: 丟棄 (不需要暫存) - 不需要接收端去暫存! 只需要回覆有
16、照順序中最大號碼的封包,3: Transport Layer,3a-32,GBN in action,3: Transport Layer,3a-33,Selective Repeat,接收端分別對所以正確接收的封包一一回覆 為了要能將封包照順序的傳送給上層,需要暫存封包 傳送端只要重送沒有收到回覆的封包 傳送端會幫每個還未收到ACK得封包計時 傳送端的視窗 N 個連續的順序號碼 再一次限制最多可以有多少沒有收到ACK的封包可以傳送,3: Transport Layer,3a-34,Selective repeat: sender, receiver windows,3: Transport
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第三 传输
链接地址:https://www.31doc.com/p-3138679.html