winter
Uploaded by
55 SLIDES
850 VUES
550LIKES

第三章 : 傳輸層

DESCRIPTION

章節目標： 了解傳輸層所提供的服務之背後原理： 多工傳輸 / 分工傳輸 可靠的資料傳輸 流量控制 擁塞控制 在網際網路上舉例說明以及實做. 章節概要： 傳輸層的服務 多工傳輸 / 分工傳輸 無連接傳輸模式： UDP 可靠的資料傳輸原理 連接導向傳輸： TCP 可靠的資料傳輸 流量控制 連接管理 擁塞控制原理 TCP 擁塞控制. 第三章 : 傳輸層. 提供在不同的主機上執行的應用程序一種 邏輯式的通訊方式 傳輸層是在每個末端主機上運行 傳輸層 vs 網路層服務： 網路層： 資料是在主機與主機間做傳輸

1 / 55

Télécharger la présentation

第三章 : 傳輸層

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 章節目標： 了解傳輸層所提供的服務之背後原理： 多工傳輸/分工傳輸 可靠的資料傳輸 流量控制 擁塞控制 在網際網路上舉例說明以及實做 章節概要： 傳輸層的服務 多工傳輸/分工傳輸 無連接傳輸模式： UDP 可靠的資料傳輸原理 連接導向傳輸： TCP 可靠的資料傳輸 流量控制 連接管理 擁塞控制原理 TCP 擁塞控制 第三章: 傳輸層 3: Transport Layer

  2. 提供在不同的主機上執行的應用程序一種邏輯式的通訊方式提供在不同的主機上執行的應用程序一種邏輯式的通訊方式 傳輸層是在每個末端主機上運行 傳輸層 vs 網路層服務： 網路層：資料是在主機與主機間做傳輸 傳輸層：資料是在程序與程序間作傳輸 必須依賴網路層服務 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport 傳輸服務及協定 3: Transport Layer

  3. 網際網路傳輸服務： 可靠的, 按照順序的單撥(unicast) 傳輸：TCP 擁塞 流量控制 連線設定 不可靠的 (最省力式 “best -effort”), 不按照順序的單撥或多撥(multicast) 傳輸：UDP 不可用的服務： 即時服務 頻寬保證 可靠的多撥 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport 傳輸層通訊協定 3: Transport Layer

  4. 回想：資料段– 在傳輸層實體間作交換的資料單元 aka TPDU: 傳輸層資料單元 M M M M application transport network application transport network application transport network H n 多工傳輸/分工傳輸 分工傳輸：傳送收到的資料段 到正確的應用層程序中 接收者 P3 P4 應用層資料 資料段 標頭 P1 P2 資料段 H t M segment 3: Transport Layer

  5. 多工傳輸/分工傳輸： 以傳送者、接收者的連接埠號、IP位置為基準 每個資料段中，傳送者、接收者的連接埠號 回想：特定的應用軟體具有廣為了解的埠號 多工傳輸： 多工傳輸/分工傳輸 從不同的應用程序中收集資料 ，由標頭將資料包住 (之後將 用於分工傳輸) 32 bits 來源端埠號 目的地端埠號 其他標頭區域 應用程式 資料 (訊息) TCP/UDP 資料段格式 3: Transport Layer

  6. 來源 IP: C 目的地 IP: B 來源埠: x 目的地埠: 80 來源 IP: C 目的地 IP: B 來源埠: y 目的地埠: 80 來源 IP: A 目的地 IP: B 來源埠: x 目的地埠: 80 來源埠: x 目的地埠: 23 來源埠:23 目的地埠: x 多工傳輸/分工傳輸：範例 網路客戶端主機 C 伺服器 B 主機 A 使用的埠: 簡易遠端登入應用程式 網路 伺服器 B 網路客戶端主機 A 使用的埠: 網路伺服器 3: Transport Layer

  7. “no frills,” “bare bones” 網路傳輸協定 “最省力式” 服務, UDP 資料段可能形式為： 易遺失的 傳送不按照順序排列的資料段給應用程式 非連線導向式： UDP傳送者與接收者之間沒有互相交換控制訊息 每個 UDP 資料段自己獨立地操作 為什麼會有UDP ? 無需建立連線 (建立連線可能會增加delay) 簡單：沒有連線狀態記錄在傳送者與接收者上 資料段標頭欄很小 沒有擁塞控制： UDP 可以如同疾風般地快速散撥資料段 UDP: 用戶資料訊息協定[RFC 768] 3: Transport Layer

  8. 通常用於多媒體資料串流應用程式上 能容忍資料段遺失 對速率相當敏感 其他 UDP 的使用 (為什麼要用UDP?): DNS 網域名稱系統 SNMP 簡易網路管理協定 在UDP上做可靠傳輸：在應用層增加可靠度 特殊應用程式錯誤回復! UDP:更多資訊 32 bits 來源端埠號 目的地端埠號 長度,在UDP 資料段中是 以位元組計 算 ,包含 標頭欄 加總檢查 長度 應用程式 資料 (訊息) UDP 資料段格式 3: Transport Layer

  9. 傳送者： 將資料段中的內容看成連續的16位元整數 加總檢查：將資料段中內容相加 (1’s complement sum) 傳送者將加總檢查值放入UDP加總檢查欄中 接收者： 計算收到資料段的加總檢查 查看是否算出來的值跟加總檢查欄中的值相同： NO – 偵測到錯誤 YES – 沒有偵測到錯誤. 但是可能仍然有錯誤? 接下來繼續討論 …. UDP 加總檢查 目標：偵測傳送後的資料段中的”錯誤” (e.g., 錯誤位元) 3: Transport Layer

  10. 在應用、傳輸、連結層具有很大的重要性 前十大重要的網路論題! 不可靠的頻道之特性, 將會決定可靠資料傳輸協定(rdt)的複雜度。 可靠資料傳輸原理 3: Transport Layer

  11. rdt_send():由上層呼叫, (e.g., 由應用層). 使資料通過並傳送到接收端的上層 deliver_data():由rdt呼叫來傳送資料給上層 udt_send():由rdt呼叫, 利用不可靠的頻道傳送封包給接收端 rdt_rcv():當封包到達接收端的頻道時被呼叫 可靠資料傳輸：開端 傳送端 接收端 3: Transport Layer

  12. 我們將會： 漸增地開發傳送端與接收端的可靠資料傳輸協定(rdt) 考慮只有單向的資料傳輸 但是控制資訊將會雙向傳送! 利用有限狀態機(FSM)來詳細說明傳送端與接收端 事件 狀態 1 狀態 2 動作 可靠資料傳輸：開端 造成狀態轉變的事件 狀態轉變時所要做的動作 狀態:當身處於這個 ”狀態”時, 接下來將進入哪個狀態只能由下一個發生事件來決定 3: Transport Layer

  13. 底層的頻道絕對可靠 沒有位元錯誤 沒有封包遺失 分開討論傳送端與接收端的有限狀態機 : 傳送端將資料送入底層的頻道 接收端從底層的頻道讀取資料 Rdt1.0: 在可靠頻道上作可靠傳輸 3: Transport Layer

  14. 底層的頻道可能會使封包中的位元發生錯誤 回想： UDP 加總檢查去偵測錯誤位元 問題: 如何從錯誤中回復: 認可 (ACKs):接收端會明確地告訴傳送端封包已接收完成 否定認可 (NAKs):接收端會明確地的告訴傳送端封包有錯誤 在接收到否定認可之後，傳送端會重新傳送封包 人類的劇本也是有認可跟否定認可嗎? rdt2.0的新機制(beyond rdt1.0): 錯誤偵測 接收端回饋: 控制訊息 (認可,否定認可) 接放端->傳送端 Rdt2.0: 利用錯誤位元的頻道 3: Transport Layer

  15. rdt2.0: 詳述有限狀態機 傳送端的有限狀態機 接收端的有限狀態機 3: Transport Layer

  16. rdt2.0:運作中的情形 (沒有錯誤發生) 傳送端的有限狀態機 接收端的有限狀態機 3: Transport Layer

  17. rdt2.0: 運作中的情形(有錯誤發生) 傳送端的有限狀態機 接收端的有限狀態機 3: Transport Layer

  18. 假如 ACK/NAK發生毀損會發生什麼? 傳送端並不知道接收端發生什麼情況! 不是僅僅重送: 可能造成重覆 What to do? 傳送端 認可/否定 接收端的 ACK/NAK? 如果傳送端的ACK/NAK遺失該怎麼辦? 重送, 但是可能造成正確被接收的封包再一次重送！ 處理重複的封包： 傳送端加入 順序編號到每一個封包 假如ACK/NAK毀損，則傳送端重傳現在的封包 接收端丟棄 (doesn’t deliver up) 重覆的封包 停下並等待 rdt2.0 有一個潛在的缺點! 傳送端送出一個封包，然後 等待接收端的回應 3: Transport Layer

  19. rdt2.1: sender, handles garbled ACK/NAKs 3: Transport Layer

  20. rdt2.1: receiver, handles garbled ACK/NAKs 3: Transport Layer

  21. 傳送端: 在封包中加入順序號碼 兩個順序號碼(0,1)足夠嗎？為什麼? 必需確定是否收到的錯誤的ACK/NAK 狀態數目的兩倍 狀態必需”記住””現在”的順序號碼是0還是1 接收端: 必需確定是否收到重覆的封包 狀態會指示預期的順序號碼是0或是1 注意: 接收端不知道它上次發送的ACK/NAK是否成功的送達傳送端 rdt2.1: 討論 3: Transport Layer

  22. 某些函式如 rdt2.1只使用NAKs 接收端傳送ACK表示成功收到最後一個封包，而不用 接收端必需清楚的將表示所回覆的封包順序號碼 傳送端收到重覆的ACK會做出和收到NAK相同的反應: 重送現在的封包 rdt2.2: a NAK-free protocol sender FSM ! 3: Transport Layer

  23. 新的假設:基礎的頻道也可能遺失封包(資料或是ACKs)新的假設:基礎的頻道也可能遺失封包(資料或是ACKs) 加總比對方法, 順序號碼, ACKs, 重新傳送，都有幫助，但並不足夠 Q:如何處理遺失? 傳送端等待，直到有些資料或是ACK遺失再傳新傳送 缺點? 方法: send傳送端等待ACK，持續一段”合理”的時間 如果在這段時間內都沒有收到ACK，則開始重傳 如果封包 (或ACK) 只是延遲了 (不是遺失了): 重傳會造成重覆的封包，但是利用順序號碼已經可以處理這個問題 接受端必需註明ACK是在回應哪個順序號碼的封包 需要有倒數計時器 rdt3.0: 有錯誤和遺失的頻道 3: Transport Layer

  24. rdt3.0 sender 3: Transport Layer

  25. rdt3.0 in action 3: Transport Layer

  26. rdt3.0 in action 3: Transport Layer

  27. rdt3.0 可行，但效果不張 例子: 頻寬1 Gbps, 點對點傳輸延遲15 ms, 封包大小1KB: 傳送端真的在傳送 資料所佔的比例 = = 0.00015 效能= U = 8kb/pkt T = 8 microsec = 8 microsec transmit 10**9 b/sec 30.016 msec Performance of rdt3.0 • 每微秒送３０個1KB大小的封包msec -> 則在頻寬為1 Gbps 的連結上的吞吐量為33kB/秒 • 網路的通訊協訂限制了物理層的資源! 3: Transport Layer

  28. 管線觀念: send傳送端允許多個”正在傳送中”但還末被回覆ACK的封包 必需增加順序號碼的範圍 暫存在傳送端或是接收端 兩種使用管線觀念的協定: go-Back-N, selective repeat 加入管線觀念的協定 3: Transport Layer

  29. 傳送端: 在封包的標頭內包含了ｋ個位元的順序號碼 “視窗” 內最多允許有連續N 個尚末被回覆ack的封包 Go-Back-N • ACK(n): 回覆的ACKs所加註的順序號碼最多到n - “累計的 ACK” • 可能收到重覆的ACKs (端看傳送端) • 為那些正在傳送中的封包設置一個計時器 • 超時(n): retransmit重傳順序號碼為n的封包及視窗內所有順序號碼大於n 的封包 3: Transport Layer

  30. GBN: sender extended FSM 3: Transport Layer

  31. 簡單的接收端: ACK-only: 總是回覆現在依照順序成功收到的封包裡，順序號碼最大的封包 可能產生重覆的ACKs 只需要記住預期的順序號碼 失序的封包: 丟棄 (不需要暫存) -> 不需要接收端去暫存! 只需要回覆有照順序中最大號碼的封包 GBN: receiver extended FSM 3: Transport Layer

  32. GBN inaction 3: Transport Layer

  33. 接收端分別對所以正確接收的封包一一回覆 為了要能將封包照順序的傳送給上層，需要暫存封包 傳送端只要重送沒有收到回覆的封包 傳送端會幫每個還未收到ACK得封包計時 傳送端的視窗 N 個連續的順序號碼 再一次限制最多可以有多少沒有收到ACK的封包可以傳送 Selective Repeat 3: Transport Layer

  34. Selective repeat: sender, receiver windows 3: Transport Layer

  35. 來自上層的資料 如果有可用的順序號碼，則將封包發送出去 超時(n): 重新傳送封包 n,並將計時器重新啟動 ACK(n) in [sendbase,sendbase+N]: 標記封包 n收到了 如果n小於最小一個還未收到回覆的封包號碼，則將視窗的下限值增加到下一個還未覆的順序號碼 接收端 傳送端 Selective repeat 封包的順序號碼落在[rcvbase, rcvbase+N-1] • send ACK(n) • 失序的: 暫存起來 • 照順序的: 傳送 (暫存起來中也有照順序的封包也傳送出去), 調整視窗到下一個還沒收到的封包 封包的順序號碼落在[rcvbase-N,rcvbase-1] • ACK(n) 其他: • 忽略 3: Transport Layer

  36. Selective repeat in action 3: Transport Layer

  37. Example: seq #’s: 0, 1, 2, 3 window size=3 兩種情景下 接收端 感覺不出差異! in (a) 不正確地傳送同一份資料做為新的 Q: seq # 和 window size 有什麼樣的關係? Selective repeat: dilemma 3: Transport Layer

  38. 全雙工資料: 同一個連線的雙向資料流 MSS: 最大分節大小(最大 segment size) 連線導向: handshaking (交換控制訊息) 在資料交換前初始化 傳送端, 接收端 獎態 流量控制: 傳送端 不會把接收端 的 緩衝區 灌滿 點對點: 一個 傳送端, 一個 接收端 可靠的，順序的 位元組 序列: 無 “message boundaries” pipelined: TCP 壅塞和流量控制決定 window size 送 & 收 緩衝區s TCP: 概觀RFCs: 793, 1122, 1323, 2018, 2581 3: Transport Layer

  39. 32 bits source port # dest port # sequence number acknowledgement number head len not used rcvr window size U A P R S F checksum ptr urgent 資料 Options (variable length) application 資料 (variable length) TCP 節區架構 URG: urgent 資料 (一般來說不會用到) 以資料的 位元組 數計算 (不是節區!) ACK: ACK # valid PSH: push 資料 now (一般來說不會用到) 接收端 想要收的 位元組 數量 RST, SYN, FIN: 連線建立 (建立、解除命令) Internet checksum (as in UDP) 3: Transport Layer

  40. Seq. #’s: 節區資料裡首位元的位元組流數目 ACKs: 另一邊預期的下一個位元組的 seq # 累進的 ACK Q:接收端 如何處理順序顛到的節區呢? A: TCP 規格書未明載–由實作者決定 時間 TCP seq. #’s and ACKs 主機 B 主機 A 使用者輸入 ‘C’ Seq=42, ACK=79, 資料 = ‘C’ 主機收到 ACKs ‘C’, 回應 ‘C’ Seq=79, ACK=43, 資料 = ‘C’ 主機收到回應的 ACKs ‘C’ Seq=43, ACK=80 簡易的 telnet 場景 3: Transport Layer

  41. TCP: 可靠的資料傳輸 事件:應用程式接收資料 精簡化 傳送端, 假設 • 單向資料傳送 • 無流量和壅塞控制 建位，送出 segment wait for event 事件:計時器等待 segment with seq # y 逾時 等待事件 重送 segment 事件:收到 ACK # y 的 ACK ACK 處理 3: Transport Layer

  42. TCP: 可靠的資料傳輸 00傳送base = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event:資料 接收d from application above 06 create TCP segment with sequence number nextseqnum 07 start 時間r for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(資料) 10 event:時間r 逾時 for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new 逾時 interval for segment y 13 restart 時間r for sequence number y 14 event: ACK 接收d, with ACK field value of y 15 if (y > 傳送base) { /* 累進的 ACK of all 資料 up to y */ 16 cancel all 時間rs for segments with sequence numbers < y 17 傳送base = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs 接收d for y 21 if (number of duplicate ACKS 接收d for y == 3) { 22 /* TCP fast retransmit */ 23 re傳送 segment with sequence number y 24 restart 時間r for segment y 25 } 26 } /* end of loop forever */ 精簡化的 TCP 傳送端 3: Transport Layer

  43. TCP ACK 產生[RFC 1122, RFC 2581] TCP 接收端動作 延遲 ACK. 等待下一個 segment 至多 500ms. 如果沒有下一個 segment,　送出　 ACK 立即送出單一的累進 ACK 送出複製的 ACK, 表示下一個預期的位元組 的 seq. # 如果 segment 在 gap 較底端 開始，立即 ACK 事件 依序排列的 segment 來到, 無 gaps, 其它的都已經 ACKed 依序排列的 segment 來到, 無 gaps, 一個延遲的 ACK 未決 亂序的 segment 來到, 比預期大的 seq. # 偵測到 gap 部分或完全充滿 gap 的 segment 來到 3: Transport Layer

  44. 主機 A 主機 B Seq=92, 8 位元組 資料 ACK=100 逾時 X loss Seq=92, 8 位元組 資料 ACK=100 時間 時間 遺失 ACK 場景 TCP: 重傳 場景s 主機 A 主機 B Seq=92, 8 位元組 資料 Seq=100, 20 位元組 資料 Seq=92 逾時 ACK=100 ACK=120 Seq=100 逾時 Seq=92, 8 位元組 資料 ACK=120 過早 逾時, 累進的 ACKs 3: Transport Layer

  45. 接收端:明確地通知 　 傳送端空的緩衝區 大小 (動態地改變) TCP segment 裡的RcvWindow　欄 傳送端:保持傳送的總數, 未 ACK 的資料 少於最近接收的RcvWindow 流量控制 TCP 流量控制 傳送端不會因為 傳送太多、太快而超過 接收端的緩衝區 RcvBuffer= 大小或 TCP 接收的緩衝區 RcvWindow = 空的緩衝區總數 接收端緩衝區 3: Transport Layer

  46. Q:如何設定 TCP 逾時 值? 較 RTT 值大 注意: RTT 會變 太短: 過早逾時 不必要重傳 太長: 對於 segment 遺失反應較慢 Q:如何估計 RTT? SampleRTT:接受 ACK 之前從 segment 傳輸所測量到的時間 忽略重傳, 累進地 ACK segments SampleRTT會變, 希望估計的 RTT “較平穩” 使用一些最近的測量值, 而不只是目前的SampleRTT TCP Round Trip 時間 and 逾時 3: Transport Layer

  47. 設定逾時時間 EstimtedRTT加上 “safety margin” EstimatedRTT 大的改變 ->較大的 safety margin TCP Round Trip Time 及逾時 EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT • Exponential weighted moving average • influence of given sample decreases exponentially fast • 典型的 x 值: 0.1 逾時 = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT| 3: Transport Layer

  48. Recall:TCP 傳送端, 接收端在交換資料 segments 前建立 “連線” 初始化 TCP 變數: seq. #s 緩衝區, 流量控制資訊 (e.g. RcvWindow) 客戶端:連線初始者 Socket ClientSocket = new Socket(“hostname","port number"); 伺服器:由客戶端聯絡 Socket ConnectionSocket = welcomeSocket.accept(); Three way handshake: Step 1:客戶端系統傳送 TCP SYN 控制 segment to 伺服器 指明起始的 seq # Step 2:伺服端系統接收 SYN, 回應 SYNACK 控制 segment ACKs 接收 SYN 配置緩衝區 指明伺服器-> 接收端起始的 seq. # TCP 連線管理 3: Transport Layer

  49. Closing a 連線: 客戶端關閉連線:ClientSocket.Close(); Step 1:客戶端系統傳送 TCP FIN segment 到伺服器 Step 2:伺服器 接收 FIN, 回應 ACK. 關閉連線, 傳送 FIN. 客戶端 伺服器 關閉 FIN ACK 關閉 FIN ACK 時間等待 關閉 TCP 連線管理 (cont.) 3: Transport Layer

  50. Step 3:客戶端, 接收 FIN, 回應 ACK. 進入 “時間等待” – 為接收到的 FINs 回應 ACK Step 4:伺服器, 接收 ACK. 連線關閉. Note:稍做修改即可處理同時產生的FINs TCP 連線管理 (cont.) 客戶端 伺服器 關閉 FIN ACK 關閉 FIN ACK 時間等待 關閉 關閉 3: Transport Layer

More Related