第三章: 傳輸層

Transcription

1 第三章 : 傳輸層 我們的目標 : 了解傳輸層服務背後的原則 : 多工 / 解多工 可靠的資料傳輸 流量控制 壅塞控制 學習有關網際網路上的傳輸層協定 : UDP: 非預接式傳輸 TCP: 連線導向的傳輸 TCP 壅塞控制 Transport Layer 3-1

2 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-2

3 傳輸層服務以及協定 提供不同主機上執行應用程式之間的邏輯通訊 在終端系統間執行的傳輸協定 傳送端 : 將應用程式的訊息分割成資料分段, 傳送到網路層 接收端 : 將資料分段重組成訊息, 傳給應用層 應用層可用的傳輸協定超過一個 網際網路 : TCP 以及 UDP 應用層傳輸層網路層資料連結層實體層 終端系統對終端系統的邏輯傳輸 網路層資料連結層實體層 網路層資料連結層實體層 網路層資料連結層實體層 網路層資料連結層實體層 網路層資料連結層實體層 應用層傳輸層網路層資料連結層實體層 Transport Layer 3-3

4 傳輸 vs. 網路層 網路層 : 主機之間的邏輯通訊 傳輸層 : 行程之間的邏輯通訊 依賴, 增強, 網路層服務 家庭的比方 : 12 個小孩傳送信件給 12 個小孩 行程 = 小孩 應用程式訊息 = 信封中的信 主機 = 房子 傳輸協定 = Ann 以及 Bill 網路層協定 = 郵政服務 Transport Layer 3-4

5 網際網路傳輸層協定 可靠的, 有序的遞送 (TCP) 壅塞控制 流量控制 連線建立 不可靠的, 無序的遞送 : UDP 盡全力 的 IP 的精簡延伸 不提供的服務 : 延遲保證 頻寬保證 應用層傳輸層網路層資料連結層實體層 終端系統對終端系統的邏輯傳輸 網路層資料連結層實體層 網路層資料連結層實體層 網路層資料連結層實體層 網路層資料連結層實體層 網路層資料連結層實體層 應用層傳輸層網路層資料連結層實體層 Transport Layer 3-5

6 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-6

7 多工 / 解多工 接收端主機的解多工 : 將收到的資料分段傳送給正確的 socket = socket = 行程 傳送端主機的多工 : 收集多個 socket 的資料, 用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段 應用層 P3 P1 P1 應用層 P2 P4 應用層 傳輸層 傳輸層 傳輸層 網路層 網路層 網路層 資料連結層 資料連結層 資料連結層 實體層 實體層 主機 1 主機 2 主機 3 實體層 Transport Layer 3-7

8 解多工如何運作 主機收到 IP 資料段 每一個資料段都擁有來源端 IP 位址以及目的端 IP 位址 每一個資料段載送 1 個傳輸層資料分段 每一個資料分段都擁有來源端以及目的端埠號 主機使用 IP 位址以及埠號將資料分段送到正確的 socket 32 位元 來源端埠號 # 目的端埠號 # 其它標頭欄位 應用程式資料 ( 訊息 ) TCP/UDP 資料分段格式 Transport Layer 3-8

9 非預接式的解多工 以埠號產生 socket: DatagramSocket mysocket1 = new DatagramSocket(99111); DatagramSocket mysocket2 = new DatagramSocket(99222); 以兩組資料識別 UDP socket : ( 目的 IP 位址, 目的埠號 ) 當主機收到 UDP 資料分段時 : 確認資料分段中的來源端埠號 以此埠號將 UDP 資料分段傳送到 socket 具有不同來源端 IP 位址的 IP 資料段和 / 或來源端埠號會被送到同一個 socket Transport Layer 3-9

10 非預接式的解多工 ( 續 ) DatagramSocket serversocket = new DatagramSocket(6428); P2 P3 P1P1 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 SP: 5775 用戶端 IP: A DP: 6428 伺服端 IP: C DP: 6428 用戶端 IP:B SP 提供 回傳位址 Transport Layer 3-10

11 連線導向的解多工 TCP socket 以四組資料加以識別 : 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號 接收端主機使用全部的四個數值將資料分段送到適當的 socket 伺服端主機可能同時支援許多 TCP sockets: 每個 socket 以它自己的四組資料加以識別 Web 伺服器針對連結到它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一次的請求都有不同的 socket Transport Layer 3-11

12 連線導向的解多工 ( 續 ) P1 P4 P5 P6 P2 P1P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 用戶端 IP: A DP: 80 S-IP: A D-IP:C 伺服端 IP: C DP: 80 S-IP: B D-IP:C 用戶端 IP:B Transport Layer 3-12

13 連線導向的解多工 : 執行緒的 Web 伺服器 P1 P4 P2 P1P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 用戶端 IP: A DP: 80 S-IP: A D-IP:C 伺服端 IP: C DP: 80 S-IP: B D-IP:C 用戶端 IP:B Transport Layer 3-13

14 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-14

15 UDP: User Datagram Protocol [RFC 768] 實際的 精簡的網際網路傳輸協定 盡全力 的服務, UDP 資料分段可能 : 遺失 不按順序傳送給應用程式 非預接式服務 在 UDP 傳送端和接收單之間沒有交握程序 每一個 UDP 資料分段的處理和其它資料分段是獨立的 為什麼會使用 UDP? 不需建立連線 ( 會增加延遲 ) 簡單 : 在傳送端和接收端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 : UDP 可以僅可能地快速傳送資料 Transport Layer 3-15

16 UDP: 更多 通常用在串流的多媒體應用程式 可以容忍遺失 易受速率影響 其他使用 UDP 的有 DNS SNMP 使用 UDP 的可靠傳輸 : 在應用層加入可靠性的機制 應用層指定的錯誤復原! 長度, 以位元組為單位的 UDP 資料分段, 包含標頭 來源端埠號 長度 32 位元 應用程式資料 ( 訊息 ) 目的端埠號 檢查和 UDP 資料分段的結構 Transport Layer 3-16

17 UDP 檢查和 目標 : 偵測傳送的資料分段中的 錯誤 ( 例如, 被翻轉的位元 ) 傳送端 : 將資料分段的內容視為一列 16 位元的整數 檢查和 : 資料分段內容的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位 接收端 : 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和檢查和欄位中的相等 : NO 偵測到錯誤 YES 沒有偵測到錯誤 但是仍然可能有錯誤? 後面有更多介紹. Transport Layer 3-17

18 網際網路的檢查和範例 注意 當數字加總時, 最高位元的進位必須被加回結果中 範例 : 加總兩個 16 位元的整數 繞回去 總數檢查和 Transport Layer 3-18

19 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-19

20 可靠資料傳輸的原理 在應用層 傳輸層 資料連結層中都是很重要的 可以列在網路問題中的前十大清單! 不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性 Transport Layer 3-20

21 可靠資料傳輸的原理 在應用層 傳輸層 資料連結層中都是很重要的 可以列在網路問題中的前十大清單! 不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性 Transport Layer 3-21

22 可靠資料傳輸的原理 在應用層 傳輸層 資料連結層中都是很重要的 可以列在網路問題中的前十大清單! 不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性 Transport Layer 3-22

23 可靠的資料傳輸 : 開始 rdt_send(): 被上層呼叫, ( 例如應用層 ). 將資料傳遞給接收端的上層協定 deliver_data(): 被 rdt 呼叫, 將資料傳送到上層 send side receive side udt_send(): 被 rdt 呼叫, 經由不可靠的通道將封包傳送給接收端 rdt_rcv(): 當封包抵達接收端的通道時被呼叫 Transport Layer 3-23

24 可靠的資料傳輸 : 開始 我們將會 : 漸進式地建立傳送端, 接收端的可靠資料傳輸協定 (rdt) 只探討單向的資料傳輸 但是控制資訊會在雙向流動! 使用有限狀態機 (FSM) 指定傳送端, 接收端 導致狀態轉換的事件狀態轉換時所採取的動作 狀態 : 在這個 狀態 時, 下一個狀態將唯一地被下一個事件所決定 狀態 1 事件動作 狀態 2 Transport Layer 3-24

25 Rdt1.0: 使用可靠通道的可靠傳輸 底層的通道是完全可靠的 沒有位元錯誤 沒有資料遺失 傳送端和接收端擁有各自的 FSM: 傳送端將資料送入底層的通道 接收端從底層的通道接收資料 等待上層傳來的呼叫 rdt_send(data) packet = make_pkt(data) udt_send(packet) 等待下層傳來的呼叫 rdt_rcv(packet) extract (packet,data) deliver_data(data) 傳送端 接收端 Transport Layer 3-25

26 Rdt2.0: 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉 偵測位元錯誤的檢查和 問題 : 如何回復錯誤 : 確認 (ACKs): 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs): 接收端明確地告訴傳送端封包的傳送有問題 當收到 NAK 時, 傳送端會重傳封包 rdt2.0 的新機制 ( 超出 rdt1.0): 錯誤偵測 接收端回饋 : 控制訊息 (ACK,NAK) 接收端 -> 傳送端 Transport Layer 3-26

27 rdt2.0: FSM 說明 rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) 等到從上層傳來的呼叫 rdt_rcv(rcvpkt) && isack(rcvpkt) Λ 傳送端 等待 ACK 或者 NAK 訊息 rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) 接收端 rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) 等待從下層傳來的呼叫 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Transport Layer 3-27

28 rdt2.0: 沒有錯誤時的運作 rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) 等到從上層傳來的呼叫 rdt_rcv(rcvpkt) && isack(rcvpkt) Λ 等待 ACK 或者 NAK 訊息 rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) 等待從下層傳來的呼叫 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Transport Layer 3-28

29 rdt2.0: 發生錯誤的情況 rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) 等到從上層傳來的呼叫 rdt_rcv(rcvpkt) && isack(rcvpkt) Λ 等待 ACK 或者 NAK 訊息 rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) 等待從下層傳來的呼叫 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Transport Layer 3-29

30 rdt2.0 有一個致命的缺點! 假如 ACK/NAK 損毀了會如何? 傳送端不知道接收端發生了什麼事! 沒辦法直接重傳 : 可能會重複 重複的處理 : 假如 ACK/NAK 損壞了, 傳送端會重新傳送目前的封包 傳送端會在每個封包加上序號 接收端或刪掉 ( 不往上傳 ) 重複的封包 停止以及等待傳送端傳送一個封包, 並等待接收端的回應 Transport Layer 3-30

31 rdt2.1: 傳送端, 處理損毀的 ACK/NAK rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) 等待從上一層傳來的呼叫 0 等待 ACK 或 NAK 訊息 1 rdt_send(data) 等待 ACK 或 NAK 訊息 0 等待從上一層傳來的呼叫 1 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Λ Transport Layer 3-31

32 rdt2.1: 接收端, 處理損毀的 ACK/NAK rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) 等待從下層傳來的 0 等待從下層傳來的 1 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Transport Layer 3-32

33 rdt2.1: 討論 傳送端 : 在封包加入序號 兩個序號 (0,1) 就足夠了 為什麼? 必須檢查收到的 ACK/NAK 是否損毀 兩倍數量的狀態 狀態必須 記得 目前的 封包序號為 0 或是 1 接收端 : 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號 注意 : 接收端無法得知它的最後一個 ACK/NAK 是否在傳送端被接收無誤 Transport Layer 3-33

34 rdt2.2: 不採用 NAK 訊息的協定 與 rdt2.1 同樣的功能, 但只使用 ACK 不使用 NAK, 接收端傳送 ACK 表示最後一個封包接收正確 接收端必須明確地加上經過確認封包的序號 在傳送端收到重複的 ACK 導致與 NAK 相同的行為 : 重新傳送目前的封包 Transport Layer 3-34

35 rdt2.2: 傳送端, 接收端片段 rdt_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) 等待從上層傳來的呼叫 0 等待從下層傳來的呼 傳送端 FSM 片段 接收端 FSM 片段 等待 ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Λ 叫 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) udt_send(sndpkt) Transport Layer 3-35

36 rdt3.0: 使用會發生錯誤及遺失封包的通道 新的假設 : 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和, 序號, ACK, 重傳都是有幫助的, 但是卻不夠 方法 : 傳送端等待 ACK 合理的 時間 假如在這段時間內沒有收到 ACK, 則重傳 假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ): 重傳會導致重複, 但是序號的使用能夠處理這個情況 接收端必須指定確認的封包序號 需要倒數計時器 Transport Layer 3-36

37 rdt3.0 傳送端 rdt_rcv(rcvpkt) Λ 等待從上一層傳來的呼叫 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) Λ 等待 ACK 訊息 1 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer 等待 ACK 訊息 0 等待從上一層傳來的呼叫 1 rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) Λ timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt) Λ Transport Layer 3-37

38 rdt3.0 的運作 Transport Layer 3-38

39 rdt3.0 的運作 Transport Layer 3-39

40 rdt3.0 的效能 rdt3.0 能夠運作, 但是效能很糟 範例 : 1 Gbps 的連結, 15 毫秒終端對終端傳遞延遲, 1KB 的封包 : T transmit = L ( 封包長度位元 ) R ( 傳送速率, bps) = 8kb/pkt 10**9 b/sec = 8 毫秒 U sender : 使用率 傳送端將位元傳入通道的時間比例 U sender = L / R RTT + L / R = = 每 30 毫秒 1KB 封包 -> 33kB/sec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用! Transport Layer 3-40

41 rdt3.0: 停止並等待的機制 在 t = 0 時, 傳送第 1 個封包的第 1 個位元 在 t = L / R 時, 傳送第 1 個封包的最後 1 個位元 sender receiver RTT 第一個封包的第一個位元到達 第一個封包的最後一個位元到達, 並且送出 ACK 在 t = RTT + L / R 時,ACK 到達, 然後送出下 1 個封包 U sender = L / R RTT + L / R = = Transport Layer 3-41

42 管線化協定 管線化 : 傳送端允許多個, 飛行中的, 還沒有被確認的封包 序號的範圍必須增加 傳送端和 / 或接收端需要暫存器 兩種管線化協定的一般性型態 : 回送 N, 選擇性重複 Transport Layer 3-42

43 管線化 : 增加使用率 傳送端 接收端 在 t = 0 時, 傳送第 1 個封包的第 1 個位元 在 t = L/R 時, 傳送第 1 個封包的最後一個位元 RTT 第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達, 送出 ACK 第 2 個封包的最後 1 個位元到達, 送出 ACK 第 3 個封包的最後 1 個位元到達, 送出 ACK ACK arrives, send next packet, t = RTT + L / R 增加 3 倍的使用率! U sender = 3 * L / R RTT + L / R = = Transport Layer 3-43

44 回送 N 傳送端 : 封包標頭的 k- 位元序號 大小最多為 N 的 視窗, 允許連續的未被確認的封包 ACK(n): 確認小於或等於序號 n 的所有封包 - 累積式確認 可能會收到重複的確認 ( 見接收端 ) 某個傳送中的封包都使用一個計時器 timeout(n): 重傳封包 n 以及在視窗中序號高於 n 的全部封包 Transport Layer 3-44

45 GBN: 傳送端的擴充 FSM rdt_send(data) Λ base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) if (nextseqnum < base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) 等待 timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer Transport Layer 3-45

46 GBN: 接收端的擴充 FSM Λ default udt_send(sndpkt) 等待 expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ack,chksum) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ack,chksum) udt_send(sndpkt) expectedseqnum++ 只使用 ACK: 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum 順序不正確的封包 : 刪除 ( 不會暫存 ) -> 接收端沒有暫存器! 重新回應最高的順序正確封包 Transport Layer 3-46

47 GBN 的運作 Transport Layer 3-47

48 選擇性重複 接收端分別確認所有正確接收的封包 依需要暫存封包, 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包 傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗 N 個連續的序號 再次, 用來限制傳送出去的, 未確認的封包序號 Transport Layer 3-48

49 選擇性重複 : 傳送端, 接收端視窗 Transport Layer 3-49

50 選擇性重複 傳送端來自上層的資料 : 假如下一個可用的序號在視窗內, 則傳送封包 timeout(n): 重送封包 n, 重新啟動計時器 ACK(n) 在 [sendbase,sendbase+n] 中 : 將封包 n 標示為已收到的 假如 n 為未確認的封包中最小的, 將視窗的 base 往前移到下一個未回應的序號 接收端封包 n 在 [rcvbase, rcvbase+n-1] 中 傳送 ACK(n) 不正確的順序 : 暫存區 正確順序 : 遞送 ( 也遞送暫存區內順序錯誤的封包 ), 將視窗前進到下一個未接收的封包 封包 n 在 [rcvbase-n,rcvbase-1] 中 ACK(n) 否則 : 忽略該封包 Transport Layer 3-50

51 選擇性重複的運作 Transport Layer 3-51

52 選擇性重複 : 困難 範例 : 序號 : 0, 1, 2, 3 視窗大小 =3 接收端無法分辨兩種情況的差別! 不正確地重新傳送重複的資料, 如同 (a) 問題 : 序號大小和視窗大小間的關係為何? Transport Layer 3-52

53 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-53

54 TCP: 綜觀 RFCs: 793, 1122, 1323, 2018, 2581 點對點 : 一個傳送端, 一個接收端 可靠的, 有順序的位元組串流 : 沒有 訊息界線 管線化 : TCP 壅塞控制和流量控制設定視窗大小 傳送端和接收端暫存器 全雙工資料傳輸 : 同一個連結中, 雙向的資料流 MSS: 最大資料分段大小 連線導向 : 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前, 設定傳送端和接收端的狀態 流量控制 : 傳送端不會超過接收端 Transport Layer 3-54

55 TCP 資料分段結構 URG: 緊急資料 ( 通常不會使用 ) ACK: 確認有效 PSH: 馬上將資料送出 ( 通常不會使用 ) RST, SYN, FIN: 連線建立 ( 設定, 中斷指令 ) 網際網路檢查和 ( 如同 UDP) 標頭長度 來源端埠號 未使用的 網際網路檢查和 32 位元 序號 確認號碼 UAP R S F 應用程式資料 ( 不固定長度 ) 接收端埠號 接收端的視窗 緊急資料指標 選用欄位 ( 不固定長度 ) 以資料位元組計算 ( 非資料分段!) 接收端願意接收的位元組數 Transport Layer 3-55

56 TCP 序號與確認 序號 : 資料分段中, 第一個位元的位元組串流 編號 確認 : 另一端期待的下一個位元組序號 累積式確認問題 : 接收端如何處理順序不正確的資料分段 答 : TCP 規格中未限制, 取決於程式開發者 使用者鍵入字元 C 主機送出收到回應字元 C 的 ACK 訊息 主機 A 主機 B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 簡單的 telnet 範例 主機送出收到 C 的 ACK 訊息, 然後回應字元 C 時序 Transport Layer 3-56

57 TCP 來回傳遞時間以及逾時 問 : 如何設定 TCP 的逾時值? 比 RTT 長 但是 RTT 是不固定的 太短 : 過早逾時 不需要重新傳送 太長 : 太晚對資料分段遺失作出反應 問 : 如何估計來回傳遞時間 ( RTT)? 樣本 RTT: 測量資料分段傳送出去到收到確認所需的時間 忽略重傳 樣本 RTT 會有所變動, 我們想要讓預估的 RTT 更平滑 將好幾個最近的測量值做平均, 而非目前的樣本 RTT Transport Layer 3-57

58 TCP 來回傳遞時間以及逾時 EstimatedRTT = (1- α)*estimatedrtt + α*samplertt 指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 : α = Transport Layer 3-58

59 範例 RTT 估計 : RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) time (seconnds) SampleRTT Estimated RTT Transport Layer 3-59

60 TCP 來回傳遞時間以及逾時 設定逾時間隔 EstimtedRTT 加上 安全邊界 EstimatedRTT 的變動很大 -> 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距 : DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT ( 通常, β = 0.25) 接著設定逾時間隔 : TimeoutInterval = EstimatedRTT + 4*DevRTT Transport Layer 3-60

61 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-61

62 TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳送計時器 重新傳送的觸發 : 逾時事件 重複的 ack 一開始先考慮簡化的 TCP 傳送端 : 忽略重複的 ack 忽略流量控制 壅塞控制 Transport Layer 3-62

63 TCP 傳送端事件 : 從應用程式收到資料 : 產生含有序號的資料分段 序號是資料分段中, 第一個資料位元組的位元組串流編號 假如計時器尚未執行, 啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 ) 逾時時間 : TimeOutInterval 逾時 : 傳新傳送導致逾時的資料分段 重新啟動計時器收到 Ack: 假如確認為之前未確認的資料分段 更新已確認的狀態 假如還有未確認的資料分段, 重新啟動計時器 Transport Layer 3-63

64 NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ TCP 傳送端 ( 簡化 ) 註解 : SendBase-1: 最後一個累積式確認位元組範例 : SendBase-1 = 71; y= 73, 接收端想要 73+ ; y > SendBase, 因此新資料被確認 Transport Layer 3-64

65 TCP: 重新傳送的情況 主機 A Seq=100, 20 bytes data ACK=100 時序 主機 B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data ACK=120 過早逾時 Transport Layer 3-65 序號 =92 逾時間隔 主機 A 主機 B Seq=92, 8 bytes data ACK=100 X loss 逾時的間隔 序號 =92 逾時間隔 Sendbase = 100 SendBase = 120 Seq=92, 8 bytes data ACK=100 SendBase = 100 SendBase = 120 時序 ACK 遺失的情況

66 TCP 重新傳送的情況 ( 更多 ) 主機 A 主機 B Transport Layer 3-66 Seq=92, 8 bytes data ACK=100 X Seq=100, 20 bytes data 逾時間隔 loss ACK=120 SendBase = 120 time 累積式 ACK 的情況

67 TCP ACK 的產生 [RFC 1122, RFC 2581] 接收端的事件 內含預設序號的資料分段按照順序到達 所有在預期序號之前的資料都已經確認 內含預期序號的資料分段按照順序到達 另一個依序到達的資料分段正在等待 ACK 傳送 未依照順序且序號超過預期序號的資料分段到達 偵測到序號中斷的情況 資料分段的到達, 可以部分或完全填滿已接收資料的中斷 TCP 接收端的動作 延後出發 ACK 等待另一個應依順序到達的資料分段, 等待最多 500 毫秒 若下一個依序資料分段未在此時間間隔內到達, 則送出 ACK 立刻送出單一的累積式 ACK, 確認這兩個依照序號到達的資料分段 立刻送出重複的 ACK, 指出下一個預期到達為組的序號 ( 就是序號中斷範圍中的較低序號 ) 即刻送出 ACK, 如果資料從中斷的較低序號端開始填滿 Transport Layer 3-67

68 快速重新傳送 逾時間隔通常相對地太長 : 在重傳遺失的封包前會有很長的延遲 經由重複的 ACK 偵測到資料分段的遺失 傳送端經常連續傳送許多資料分段 假如資料分段遺失了, 可能會有許多大量的重複 ACK 假如傳送端接收到 3 個 ACK, 它會假設已確認之後的資料已經遺失了 : 快速重新傳送 : 在計時器逾期之前, 會先傳送資料分段 Transport Layer 3-68

69 快速重新傳送演算法 : event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } 已確認的資料分段重複確認 快速重新傳送 Transport Layer 3-69

70 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-70

71 TCP 流量控制 TCP 連線的接收端有一個接收緩衝區 : 流量控制傳送端不會傳送太多太快的資料超過接收端的緩衝區 速度調整服務 : 調整傳送端的速度與接收端應用程式能負擔的速度 相符 應用程式的行程也許會以較慢的速度從緩衝區讀取資料 Transport Layer 3-71

72 TCP 流量控制 : 如何運作 ( 假設 TCP 接收端會將順序不正確的資料分段捨棄 ) 緩衝區內的剩餘空間 = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] 接收端將 RcvWindow 值包含在資料分段裡, 以告知剩餘的空間 傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出 Transport Layer 3-72

73 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-73

74 TCP 連線管理 回想 : TCP 傳送端 接收端在交換資料分段之前, 會先建立 連線 將 TCP 變數初始化 : 序號 緩衝區, 流量控制資訊 ( 例如 RcvWindow) 用戶端 : 開始連線者 Socket clientsocket = new Socket("hostname","port number"); 伺服端 : 被用戶端聯繫 Socket connectionsocket = welcomesocket.accept(); 三路交握 : 步驟 1: 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料 步驟 2: 伺服端主機收到 SYN, 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號步驟 3: 用戶端收到 SYNACK, 回應 ACK 資料分段, 可能含有資料 Transport Layer 3-74

75 TCP 連線管理 ( 續 ) 關閉連線 : 用戶端 伺服端 用戶端關閉 socket: clientsocket.close(); 關閉 FIN 步驟 1: 用戶端終端系統傳送 TCP FIN 控制分段到伺服端 ACK FIN 關閉 步驟 2: 伺服端接收到 FIN, 以 ACK 回應 關閉連線, 傳送 FIN timed wait 已關閉 ACK Transport Layer 3-75

76 TCP 連線管理 ( 續 ) 步驟 3: 用戶端收到 FIN, 回應 ACK 訊息 進入 timed wait 對接收到的 FIN 做確認的回應 步驟 4: 伺服端, 收到 ACK 連線關閉 關閉 用戶端 FIN ACK FIN 伺服端 關閉 注意 : 做一點小修改, 可以處理同時的 FIN timed wait ACK 已關閉 已關閉 Transport Layer 3-76

77 TCP 連線管理 ( 續 ) TCP 伺服端生命週期 TCP 用戶端生命週期 Transport Layer 3-77

78 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-78

79 壅塞控制的原則 壅塞 : 非正式地 : 太多的來源端傳送太多的資料, 對網路來說太快, 超過能處理的速度 與流量控制不同! 表現形式 : 封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 ) 前十大的問題! Transport Layer 3-79

80 壅塞的原因和代價 : 情況 1 兩個傳送端, 兩個接收端 主機 A λ in : original data λ out 一個路由器, 無限的緩衝區 主機 B 沒有限制的分享輸出連結緩衝器 沒有重傳機制 當壅塞時會有很長的延遲 最大的可達成流通量 Transport Layer 3-80

81 壅塞的原因和代價 : 情況 2 一個路由器, 有限的緩衝區 傳送端會重新傳送遺失的封包 主機 A λ in : 原始資料 λ in : 原始資料, 加上重新傳送的資料 λ out 主機 B 共享的有限輸出連結緩衝區 Transport Layer 3-81

82 壅塞的原因和代價 : 情況 2 總是 : λ = λ (goodput, 實際產量 ) in out 理想的 重新傳送, 只在遺失 : λ > λ in out 傳送延遲的封包 ( 並非遺失 ) 會使的 λ 較大 ( 大於理想狀況 ), 在相同 in 的 λ 下 out R/2 R/2 R/2 R/3 λ out λ out λ out R/4 λ in R/2 λ in R/2 λ in R/2 a. b. c. 壅塞的 代價 : 對給定的 實際產量 (goodput), 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 : 連結必須負擔多個封包的副本 Transport Layer 3-82

83 壅塞的原因和代價 : 情況 3 四個傳送端 多次轉接路徑 逾時 / 重新傳送 λ in λ in Q: 當和增加時, 會發生什麼情況? 主機 A λ in : 原始資料的傳送速率 λ in : 原始資料加上重送資料的傳送速率 共享的有限輸出連結緩衝區 λ out 主機 B Transport Layer 3-83

84 壅塞的原因和代價 : 情況 3 H o s t A λ o u t H o s t B 壅塞的另一個代價 : 當封包被丟掉時, 此封包所使用到的任何 上游 傳送容量就被浪費掉了! Transport Layer 3-84

85 壅塞控制的方法 壅塞控制的兩個主要方法 : 端點對端點壅塞控制 : 網路層並沒有提供明顯的協助 根據中端系統觀察到的遺失及延遲來判斷壅塞 TCP 採用的方法 網路協助的壅塞控制 : 路由器提供協助給終端系統 以一個位元來表示壅塞 (SNA, DECbit, TCP/IP ECN, ATM) 傳送端應該傳送的明確速率 Transport Layer 3-85

86 案例研究 : ATM ABR 壅塞控制 ABR: 可用的位元速率 : 彈性的服務 假如傳送端路徑 負載量很低 時 : 傳送端可以利用可用的頻寬 假如傳送端路徑壅塞時 : 傳送端減速到最小的保證速率 RM ( 資源管理 ) 封包單位 : 傳送端所傳送的, 配置在資料封包單位中 RM 封包單位中的位元, 由交換器設定 ( 網路協助 ) NI 位元 : 不增加速率 ( 輕微壅塞 ) CI 位元 : 壅塞指示 RM 封包單位的位元由接收端原封不動地送回給傳送端 Transport Layer 3-86

87 案例研究 : ATM ABR 壅塞控制 RM 封包單位中, 兩個位元組的 ER ( 明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此, 傳送端的傳送速率為路徑上最低可支援速率 資料封包單位中的 EFCI 位元 : 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定, 則傳送端會將 CI 位元設定在回傳的 RM 封包單位中 Transport Layer 3-87

88 第三章 : 傳輸層 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸 : UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸 : TCP 分段結構 可靠的資料傳輸 流量控制 連線管理 3.6 壅塞控制的原則 3.7 TCP 壅塞控制 Transport Layer 3-88

89 TCP 壅塞控制 : 累積遞增 倍數遞 減 方法 : 增加傳送速率 ( 視窗大小 ), 探測可用的頻寬, 直到發生遺失的狀況 累積遞增 : 每個 RTT, 將 CongWin 加 1, 直到發生遺失 倍數遞減 : 在發生遺失之後, 將 CongWin 減為一半 看到鋸齒形式 : 頻寬的探測 Transport Layer 3-89

90 TCP 壅塞控制 : 細節 傳送端限制速率 : LastByteSent-LastByteAcked 大致上, rate = CongWin RTT CongWin Bytes/sec CongWin 是動態的, 是察覺的網路壅塞函數 傳送端如何察覺到壅塞狀況? 遺失事件 = 逾時或 3 個重複的 ack 在遺失事件之後,TCP 傳送端會降低速率 (CongWin) 三個機制 : AIMD 緩數啟動 發生逾時事件後的保守態度 Transport Layer 3-90

91 TCP 緩速啟動 當連線一開始時, CongWin = 1 MSS 範例 : MSS = 500 位元組 & RTT = 200 毫秒 初始速率 = 20 kbps 可用的頻寬可能 >> MSS/RTT 想要快速地增加到可接受的速率 當連結開始時, 以指數型式增加速率, 直到第一個遺失發生 Transport Layer 3-91

92 TCP 緩速啟動 ( 更多 ) 當連結開始時, 以指數型式增加速率, 直到第一個遺失事件發生 : 在每次的 RTT, 將 CongWin 增為一倍 RTT 主機 A 主機 B 第一個資料分段第二個資料分段 每次收到 ACK 時, 會增加 CongWin 總結 : 開始的速率是緩慢的, 但會以指數形式快速增加速率 第四個資料分段 時間 Transport Layer 3-92

93 再改良 Q: 指數形式的增長什麼時候會轉換為線性的? A: 當 CongWin 到達逾時事件發生前的一半大小 實作 : 變數 Threshold 在遺失事件發生時, Threshold 會被設為遺失事件發生之前的 CongWin 的 1/2 Transport Layer 3-93

94 再改良 : 推論遺失 在三個重複的 ACK 之後 : CongWin 減為一半 視窗接下來會線性成長 但是在逾時事件後 : CongWin 設為 1 MSS; 視窗會以指數增長 到一個門檻, 接著以線性成長 哲學 : 3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況 Transport Layer 3-94

95 總結 : TCP 壅塞控制 當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時, 視窗以指數成長 當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段, 視窗以線性成長 當三個重複的 ACK 發生時, 將 Threshold 設定為 CongWin/2 且 CongWin 設定為 Threshold 當逾時發生時, Threshold 設定為 CongWin/2 且 CongWin 設定為 1 MSS Transport Layer 3-95

96 TCP 傳送端壅塞控制 狀態事件 TCP 傳送端動作註解 緩速啟動 (SS) 收到下一個時確認資料的 ACK CongWin = CongWin + MSS, 如果 (CongWin > Threshold) 設定狀態為 壅塞避免 導致在每個 RTT 時間內 CongWin 數值的倍增 壅塞避免 (CA) 收到下一個待確認資料的 ACK CongWin = CongWin+MSS * (MSS/CongWin) 累加遞增, 導致 CongWin 在每個 RTT 時間內增加 1MSS SS or CA 偵測到三個重複 ACK 的遺失事件 Threshold = CongWin/2, CongWin = Threshold, 設定狀態為 壅塞避免 快速回復, 採用倍數遞減 CongWin 值不會低於 1MSS SS or CA 逾時 Threshold = CongWin/2, CongWin = 1 MSS, 設定狀態為 緩速啟動 SS or CA 重複 ACK 增加資料分段被確認的重複 ACK 記數 進入緩速啟動 CongWin 及 Threshold 不會改變 Transport Layer 3-96

97 TCP 流通量 TCP 的平均流通量為何? 以視窗大小以及 RTT 值的函數表示? 忽略緩慢啟動階段 令 W 為遺失發生時的視窗大小 當視窗大小為 W 時, 流通量為 W/RTT 在遺失發生之後, 視窗馬上降為 W/2, 流通量為 W/2RTT 平均流通量 :.75 W/RTT Transport Layer 3-97

98 TCP 的未來 範例 : 1500 位元組資料分段,100 毫秒 RTT, 想要達到 10 Gbps 的流通量 需要視窗大小 W = 83,333 傳輸的資料分段 以遺失率計算流通量 : L = 哇! 1.22 MSS RTT 我們需要高速環境下的新版 TCP! L Transport Layer 3-98

99 TCP 公平性 公平性目標 : 假如有 K 條 TCP 會談連線, 分享同一個瓶頸點連結的頻寬 R, 每一個應該有 R/K 的平均速率 TCP 連結 1 TCP 連結 2 瓶頸點路由器容量 R Transport Layer 3-99

100 TCP 為什麼公平? 兩個互相競爭的會談連線 : 隨著流通量增加, 累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減 R 平等的頻寬分享 連線 2 的流通量 遺失 : 將視窗以 1/2 為因子遞減壅塞避免 : 累積遞增 遺失 : 將視窗以 1/2 為因子遞減壅塞避免 : 累積遞增 連線 1 的流通量 R Transport Layer 3-100

101 公平性 ( 更多 ) 公平性和 UDP 多媒體應用程式通常不會使用 TCP 不想藉壅塞控制限制速率 使用 UDP 來取代 : 以固定速率將音訊 / 視訊送入網路, 容忍封包遺失 研究領域 : TCP 的友善性 公平性以及平行的 TCP 連結 無法防止應用程式在兩個主機間開啟平行的連線 Web 瀏覽器會這樣做 範例 : 速率 R 的連結支援 supporting 9 個程式 ; 新的應用程式要求 1 個 TCP, 則得到 R/10 的速率 新的應用程式要求 11 個 TCP, 則得到 R/2 的速率! Transport Layer 3-101

102 延遲模型 問 : 在傳送一個請求之後, 需要多久時間才能從 Web 伺服器接收到一個物件? 忽略壅塞的情況下, 延遲被下列因素影響 : TCP 連線建立 資料傳輸延遲 緩慢啟動 符號, 假設 : 假設在用戶端和伺服端之間有一個速率為 R 的連結 S: MSS ( 位元 ) O: 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失, 沒有損毀 ) 視窗大小 : 首先 : 固定的壅塞視窗, W 資料分段 接著, 動態的視窗, 緩速啟動模型 Transport Layer 3-102

103 固定的壅塞視窗 (1) 第一個情況 : WS/R > RTT + S/R: 在完成視窗的傳輸之前, 便可接收到第一個資料分段的確認 delay = 2RTT + O/R Transport Layer 3-103

104 固定的壅塞視窗 (2) 第二個情況 : WS/R < RTT + S/R: 在視窗的傳輸完成之後, 等待確認訊息 delay = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Transport Layer 3-104

105 TCP 延遲模型 : 緩速啟動 (1) 現在假設視窗依據緩速啟動增長 我們可以證明一個物件的延遲為 : Latency O S P = 2RTT + + P RTT (2 1) R + R 其中 P 為 TCP 在伺服器停止的次數 : S R P = min{ Q, K 1} - Q 為物件含有無限數量的資料分段情況下, 伺服器停止的次數 -K 為涵蓋物件資料的視窗數量 Transport Layer 3-105

106 TCP 延遲模型 : 緩速啟動 (2) 延遲元件 : 2 RTT 用來做連線建立以及請求 O/R 用來傳輸物件 伺服器因緩速啟動而停止的時間 伺服器停止 : P = min{k-1,q} 次 範例 : O/S = 15 資料分段 K = 4 視窗 Q = 2 P = min{k-1,q} = 2 伺服器停止 P=2 次 Transport Layer 3-106

107 Transport Layer TCP 延遲模型 : 緩速啟動 (3) R S R S RTT P RTT R O R S RTT R S RTT R O RTT R O P k P k P p p 1) (2 ] [ 2 ] 2 [ = = + + = = = 停止時間延遲 2 1 = 在第 k 個視窗之後的停止時間 + + R S RTT R S k = 當伺服器開始傳送資料分段到收到確認的時間 + RTT R S 傳送第 k 個視窗的時間 R S k = 1 2

108 Transport Layer TCP 延遲模型 (4) + = + = = = = 1) ( log 1)} ( log : min{ } 1 2 : min{ } / : min{ } : min{ S O S O k k S O k S O k O S S S k K k k k Λ Λ Q, 物件含有無限數量的資料分段情況下, 伺服器停止的次數, 的計算是類似的 ( 見習題 ) 回想 K = 涵蓋物件資料的視窗數量要怎麼計算 K?

109 HTTP 模型 假設網頁包含 : 1 基本的 HTML 文件 ( 大小為 O 位元 ) M 影像檔 ( 大小為 O 位元 ) 非永久性 HTTP: 一系列 M+1 TCP 連結 回應時間 = (M+1)O/R + (M+1)2RTT + 閒置次數的總合 永久性 HTTP: 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)O/R + 3RTT + 閒置次數的總合 非永久性 HTTP, 具有 X 個平行連結 假設 M/X 為整數 基本檔案使用 1 TCP 連結 影像使用 M/X 組平行連結 回應時間 = (M+1)O/R + (M/X + 1)2RTT + 閒置次數的總合 Transport Layer 3-109

110 HTTP 回應時間 ( 以秒為單位 ) RTT = 100 毫秒, O = 5 Kbytes, M=10 以及 X= Kbps 100 Kbps 1 Mbps 10 Mbps 非永久性 永久性 平行非永久性 在低的頻寬時, 連結和回應時間主要受傳輸時間影響 永久性連結只比平行連結多一點進步 Transport Layer 3-110

111 HTTP 回應時間 ( 以秒為單位 ) RTT =1 秒, O = 5 Kbytes, M=10 and X= 非永久性 永久性 平行永久性 0 28 Kbps 100 Kbps 1 Mbps 10 Mbps 在 RTT 很大時, 回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響 現在使用永久性連結有很大的進步了 : 特別是在高延遲 頻寬的網路 Transport Layer 3-111

112 第三章 : 總結 傳輸層服務的原則 : 多工, 解多工 可靠的資料傳輸 流量控制 壅塞控制 網際網路上的例證和實作 UDP TCP 接下來 : 離開網路 邊緣 ( 應用, 傳輸層 ) 進入網路 核心 Transport Layer 3-112