Transport Layer 3-1

第三章 傳輸層我們的目標 了解傳輸層服務背後的

原則 多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

學習有關網際網路上的傳輸層協定 UDP 非預接式傳輸 TCP 連線導向的傳輸 TCP 壅塞控制

Transport Layer 3-2

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-3

傳輸層服務以及協定 提供不同主機上執行應用

程式之間的邏輯通訊 在終端系統間執行的傳輸

協定 傳送端 將應用程式的

訊息分割成資料分段傳送到網路層

接收端 將資料分段重組成訊息傳給應用層

應用層可用的傳輸協定超過一個 網際網路 TCP 以及

UDP

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-4

傳輸 vs 網路層 網路層 主機之間的邏

輯通訊 傳輸層 行程之間的邏

輯通訊 依賴 增強 網路層服務

家庭的比方 12 個小孩傳送信件給 12

個小孩 行程 = 小孩 應用程式訊息 = 信封

中的信 主機 = 房子 傳輸協定 = Ann 以及

Bill 網路層協定 = 郵政服

務

Transport Layer 3-5

網際網路傳輸層協定 可靠的 有序的遞送

(TCP) 壅塞控制 流量控制 連線建立

不可靠的 無序的遞送 UDP ldquo 盡全力rdquo的 IP 的精簡延

伸 不提供的服務

延遲保證 頻寬保證

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-6

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-2

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-3

傳輸層服務以及協定 提供不同主機上執行應用

程式之間的邏輯通訊 在終端系統間執行的傳輸

協定 傳送端 將應用程式的

訊息分割成資料分段傳送到網路層

接收端 將資料分段重組成訊息傳給應用層

應用層可用的傳輸協定超過一個 網際網路 TCP 以及

UDP

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-4

傳輸 vs 網路層 網路層 主機之間的邏

輯通訊 傳輸層 行程之間的邏

輯通訊 依賴 增強 網路層服務

家庭的比方 12 個小孩傳送信件給 12

個小孩 行程 = 小孩 應用程式訊息 = 信封

中的信 主機 = 房子 傳輸協定 = Ann 以及

Bill 網路層協定 = 郵政服

務

Transport Layer 3-5

網際網路傳輸層協定 可靠的 有序的遞送

(TCP) 壅塞控制 流量控制 連線建立

不可靠的 無序的遞送 UDP ldquo 盡全力rdquo的 IP 的精簡延

伸 不提供的服務

延遲保證 頻寬保證

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-6

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-3

傳輸層服務以及協定 提供不同主機上執行應用

程式之間的邏輯通訊 在終端系統間執行的傳輸

協定 傳送端 將應用程式的

訊息分割成資料分段傳送到網路層

接收端 將資料分段重組成訊息傳給應用層

應用層可用的傳輸協定超過一個 網際網路 TCP 以及

UDP

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-4

傳輸 vs 網路層 網路層 主機之間的邏

輯通訊 傳輸層 行程之間的邏

輯通訊 依賴 增強 網路層服務

家庭的比方 12 個小孩傳送信件給 12

個小孩 行程 = 小孩 應用程式訊息 = 信封

中的信 主機 = 房子 傳輸協定 = Ann 以及

Bill 網路層協定 = 郵政服

務

Transport Layer 3-5

網際網路傳輸層協定 可靠的 有序的遞送

(TCP) 壅塞控制 流量控制 連線建立

不可靠的 無序的遞送 UDP ldquo 盡全力rdquo的 IP 的精簡延

伸 不提供的服務

延遲保證 頻寬保證

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-6

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-4

傳輸 vs 網路層 網路層 主機之間的邏

輯通訊 傳輸層 行程之間的邏

輯通訊 依賴 增強 網路層服務

家庭的比方 12 個小孩傳送信件給 12

個小孩 行程 = 小孩 應用程式訊息 = 信封

中的信 主機 = 房子 傳輸協定 = Ann 以及

Bill 網路層協定 = 郵政服

務

Transport Layer 3-5

網際網路傳輸層協定 可靠的 有序的遞送

(TCP) 壅塞控制 流量控制 連線建立

不可靠的 無序的遞送 UDP ldquo 盡全力rdquo的 IP 的精簡延

伸 不提供的服務

延遲保證 頻寬保證

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-6

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-5

網際網路傳輸層協定 可靠的 有序的遞送

(TCP) 壅塞控制 流量控制 連線建立

不可靠的 無序的遞送 UDP ldquo 盡全力rdquo的 IP 的精簡延

伸 不提供的服務

延遲保證 頻寬保證

應用層傳輸層網路層

資料連結層實體層

應用層傳輸層網路層

資料連結層實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層

網路層資料連結層

實體層網路層資料連結層

實體層

終端

系統

對終

端系

統的

邏輯

傳輸

Transport Layer 3-6

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-6

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-7

多工 解多工

應用層

傳輸層

網路層

資料連結層

實體層

P1 應用層

傳輸層

網路層

資料連結層

實體層

應用層

傳輸層

網路層

資料連結層

實體層

P2P3 P4P1

主機 1 主機 2 主機 3

= 行程= socket

將收到的資料分段傳送給正確的 socket

接收端主機的解多工 收集多個 socket 的資料用標頭 ( 稍後將用在解多工 ) 將每個資料片段封裝成資料分段

傳送端主機的多工

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-8

解多工如何運作 主機收到 IP 資料段

每一個資料段都擁有來源端 IP位址以及目的端 IP 位址

每一個資料段載送 1 個傳輸層資料分段

每一個資料分段都擁有來源端以及目的端埠號

主機使用 IP 位址以及埠號將資料分段送到正確的 socket

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

其它標頭欄位

TCPUDP 資料分段格式

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-9

非預接式的解多工 以埠號產生 socketDatagramSocket mySocket1 = new

DatagramSocket(99111)

DatagramSocket mySocket2 = new DatagramSocket(99222)

以兩組資料識別 UDP socket

( 目的 IP 位址 目的埠號 )

當主機收到 UDP 資料分段時 確認資料分段中的來源端埠

號 以此埠號將 UDP 資料分段

傳送到 socket

具有不同來源端 IP 位址的 IP 資料段 和 或 來源端埠號會被送到同一個 socket

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-10

非預接式的解多工 (續 )

DatagramSocket serverSocket = new DatagramSocket(6428)

用戶端IPB

P2

用戶端 IP A

P1P1P3

伺服端IP C

SP 6428

DP 9157

SP 9157

DP 6428

SP 6428

DP 5775

SP 5775

DP 6428

SP 提供 ldquo回傳位址rdquo

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-11

連線導向的解多工 TCP socket 以四組資料

加以識別 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號

接收端主機使用全部的四個數值將資料分段送到適當的 socket

伺服端主機可能同時支援許多 TCP sockets 每個 socket 以它自己的四

組資料加以識別 Web 伺服器針對連結到

它的每一個用戶端都有不同的 socket 非永久性 HTTP 針對每一

次的請求都有不同的 socket

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-12

連線導向的解多工 (續 )

用戶端IPB

P1

用戶端 IP A

P1P2P4

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P5 P6 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-13

連線導向的解多工 執行緒的Web 伺服器

用戶端IPB

P1

用戶端 IP A

P1P2

伺服端IP C

SP 9157

DP 80

SP 9157

DP 80

P4 P3

D-IPCS-IP A

D-IPC

S-IP B

SP 5775

DP 80

D-IPCS-IP B

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-14

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-15

UDP User Datagram Protocol [RFC 768]

實際的精簡的網際網路傳輸協定

ldquo盡全力rdquo 的服務 UDP 資料分段可能 遺失 不按順序傳送給應用程式

非預接式服務 在 UDP 傳送端和接收單

之間沒有交握程序 每一個 UDP 資料分段的

處理和其它資料分段是獨立的

為什麼會使用 UDP 不需建立連線 ( 會增加

延遲 ) 簡單 在傳送端和接收

端不需維持連線狀態 較小的封包標頭 沒有壅塞控制 UDP 可

以僅可能地快速傳送資料

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-16

UDP 更多 通常用在串流的多媒體

應用程式 可以容忍遺失 易受速率影響

其他使用 UDP 的有 DNS SNMP

使用 UDP 的可靠傳輸 在應用層加入可靠性的機制 應用層指定的錯誤復原

來源端埠號 目的端埠號

32 位元

應用程式資料( 訊息 )

UDP 資料分段的結構

長度 檢查和長度 以位元組

為單位的 UDP資料分段

包含標頭

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-17

UDP 檢查和

傳送端 將資料分段的內容視為

一列 16 位元的整數 檢查和 資料分段內容

的加法 (1 的補數和 ) 傳送端將檢查和的值放入 UDP 的檢查和欄位

接收端 計算收到的資料分段的檢查和 確認計算出來的檢查和是否和

檢查和欄位中的相等 NO ndash 偵測到錯誤 YES ndash 沒有偵測到錯誤但

是仍然可能有錯誤 後面有更多介紹hellip

目標 偵測傳送的資料分段中的 ldquo錯誤rdquo (例如 被翻轉的位元 )

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-18

網際網路的檢查和範例 注意

當數字加總時最高位元的進位必須被加回結果中 範例 加總兩個 16 位元的整數

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

繞回去

總數檢查和

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-19

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-20

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 的複雜性

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-21

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-22

可靠資料傳輸的原理 在應用層傳輸層資料連結層中都是很重要的 可以列在網路問題中的前十大清單

不可靠通道的特性決定了可靠資料傳輸協定 (rdt) 複雜性

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-23

可靠的資料傳輸 開始

sendside

receiveside

rdt_send() 被上層呼叫 (例如應用層 ) 將資料傳遞給接收端的上層

協定

udt_send() 被 rdt呼叫 經由不可靠的通道將封包傳送給

接收端

rdt_rcv() 當封包抵達接收端的通道時被呼叫

deliver_data() 被 rdt 呼叫將資料傳送到上層

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-24

可靠的資料傳輸 開始我們將會 漸進式地建立傳送端接收端的可靠資料傳輸協定

(rdt) 只探討單向的資料傳輸

但是控制資訊會在雙向流動

使用有限狀態機 (FSM) 指定傳送端 接收端

狀態1

狀態2

導致狀態轉換的事件狀態轉換時所採取的動作

狀態 在這個rdquo狀態rdquo時下一個狀態將唯一地被下一個事件所決定 事件

動作

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-25

Rdt10 使用可靠通道的可靠傳輸 底層的通道是完全可靠的

沒有位元錯誤 沒有資料遺失

傳送端和接收端擁有各自的 FSM 傳送端將資料送入底層的通道 接收端從底層的通道接收資料

等待上層傳來的呼叫 packet = make_pkt(data)

udt_send(packet)

rdt_send(data)

extract (packetdata)deliver_data(data)

等待下層傳來的呼叫

rdt_rcv(packet)

傳送端 接收端

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-26

Rdt20 可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉

偵測位元錯誤的檢查和 問題 如何回復錯誤

確認 (ACKs) 接收端明確地告訴傳送端封包的傳送 OK 否定確認 (NAKs) 接收端明確地告訴傳送端封包的傳送有問題

當收到 NAK 時傳送端會重傳封包 rdt20 的新機制 ( 超出 rdt10)

錯誤偵測 接收端回饋 控制訊息 (ACKNAK) 接收端 -gt 傳送端

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-27

rdt20 FSM 說明

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫傳送端

接收端rdt_send(data)

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-28

rdt20 沒有錯誤時的運作

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-29

rdt20 發生錯誤的情況

等到從上層傳來的呼叫

snkpkt = make_pkt(data checksum)udt_send(sndpkt)

extract(rcvpktdata)deliver_data(data)udt_send(ACK)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

rdt_rcv(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp isNAK(rcvpkt)

udt_send(NAK)

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

等待 ACK或者 NAK

訊息

等待從下層傳來的呼叫

rdt_send(data)

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-30

rdt20 有一個致命的缺點

假如 ACKNAK 損毀了會如何

傳送端不知道接收端發生了什麼事

沒辦法直接重傳 可能會重複

重複的處理 假如 ACKNAK損壞了傳

送端會重新傳送目前的封包 傳送端會在每個封包加上序

號 接收端或刪掉 ( 不往上傳 )

重複的封包

傳送端傳送一個封包並等待接收端的回應

停止以及等待

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-31

rdt21 傳送端 處理損毀的 ACKNAK

等待從上一層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

等待 ACK或 NAK 訊息 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt)

等待從上一層傳來的呼叫 1

等待 ACK或 NAK 訊息 1

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-32

rdt21 接收端 處理損毀的 ACKNAK

等待從下層傳來的 0

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq0(rcvpkt)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

等待從下層傳來的 1

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq0(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp not corrupt(rcvpkt) ampamp has_seq1(rcvpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt)

sndpkt = make_pkt(ACK chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK chksum)udt_send(sndpkt)

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-33

rdt21 討論

傳送端 在封包加入序號 兩個序號 (01) 就足夠

了為什麼 必須檢查收到的 ACK

NAK 是否損毀 兩倍數量的狀態

狀態必須rdquo記得rdquo ldquo目前的rdquo封包序號為 0 或是 1

接收端 必須確認接收端封包是否重複 狀態表示 0 或 1 是否為所預期的封包序號

注意 接收端無法得知它的最後一個 ACKNAK 是否在傳送端被接收無誤

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-34

rdt22 不採用 NAK 訊息的協定

與 rdt21 同樣的功能但只使用 ACK 不使用 NAK 接收端傳送 ACK 表示最後一個封包接收

正確 接收端必須明確地加上經過確認封包的序號

在傳送端收到重複的 ACK 導致與 NAK 相同的行為 重新傳送目前的封包

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-35

rdt22 傳送端 接收端片段

等待從上層傳來的呼叫 0

sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)

rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) || isACK(rcvpkt1) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

等待ACK0

傳送端 FSM片段

等待從下層傳來的呼叫 0

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp has_seq1(rcvpkt)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(ACK1 chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) ampamp (corrupt(rcvpkt) || has_seq1(rcvpkt))

udt_send(sndpkt)

接收端 FSM片段

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-36

rdt30 使用會發生錯誤及遺失封包的通道

新的假設 底層的頻道也可能遺失封包 ( 資料或 ACK) 檢查和 序號 ACK 重

傳都是有幫助的但是卻不夠

方法 傳送端等待 ACK ldquo合理的rdquo 時間

假如在這段時間內沒有收到 ACK 則重傳

假如封包 ( 或 ACK) 只是延遲了 ( 沒有遺失 ) 重傳會導致重複但是序號

的使用能夠處理這個情況 接收端必須指定確認的封包

序號 需要倒數計時器

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-37

rdt30 傳送端sndpkt = make_pkt(0 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

等待 ACK

訊息 0

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt1) )

等待從上一層傳來的呼叫 1

sndpkt = make_pkt(1 data checksum)udt_send(sndpkt)start_timer

rdt_send(data)

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt0)

rdt_rcv(rcvpkt) ampamp ( corrupt(rcvpkt) ||isACK(rcvpkt0) )

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt) ampamp isACK(rcvpkt1)

stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)

等待從上一層傳來的呼叫 0

等待ACK

訊息 1

rdt_rcv(rcvpkt)

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-38

rdt30 的運作

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-39

rdt30 的運作

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-40

rdt30 的效能

rdt30 能夠運作 但是效能很糟 範例 1 Gbps 的連結 15 毫秒 終端對終端傳遞延遲 1KB 的封包

Ttransmit

= 8kbpkt109 bsec

= 8 毫秒

U sender 使用率 ndash 傳送端將位元傳入通道的時間比例

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

L ( 封包長度位元 )R ( 傳送速率 bps)

=

每 30 毫秒 1KB 封包 -gt 33kBsec 生產量在 1 Gbps 連結上 網路協定限制了實體資源的使用

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-41

rdt30 停止並等待的機制

在 t = 0 時傳送第 1 個封包的第 1 個位元

sender receiver

RTT

在 t = L R 時傳送第 1 個封包的最後 1 個位元

第一個封包的第一個位元到達第一個封包的最後一個位元到達並且送出ACK

在 t = RTT + L R 時 ACK 到達然後送出下 1 個封包

U sender

= 008

30008 = 000027

microseconds

L R

RTT + L R =

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-42

管線化協定管線化 傳送端允許多個 ldquo飛行中的rdquo 還沒有被確

認的封包 序號的範圍必須增加 傳送端 和 或 接收端需要暫存器

兩種管線化協定的一般性型態 回送 N 選擇性重複

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-43

管線化 增加使用率在 t = 0 時傳送第 1 個封包的第 1 個位元

傳送端 接收端

RTT

在 t = LR 時傳送第 1 個封包的最後一個位元

第 1 個封包的第 1 個位元到達第 1 個封包的最後 1 個位元到達送出 ACK

ACK arrives send next packet t = RTT + L R

第 2 個封包的最後 1 個位元到達送出 ACK

第 3 個封包的最後 1 個位元到達送出 ACK

U sender

= 024

30008 = 00008

microseconds

3 L R

RTT + L R =

增加 3 倍的使用率

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-44

回送 N

傳送端 封包標頭的 k- 位元序號 大小最多為 N的ldquo視窗rdquo 允許連續的未被確認的封包

ACK(n) 確認小於或等於序號 n 的所有封包 - ldquo累積式確認rdquo 可能會收到重複的確認 (見接收端 )

某個傳送中的封包都使用一個計時器 timeout(n) 重傳封包 n 以及在視窗中序號高於 n 的全部封包

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-45

GBN 傳送端的擴充 FSM

等待 start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])hellipudt_send(sndpkt[nextseqnum-1])

timeout

rdt_send(data)

if (nextseqnum lt base+N) sndpkt[nextseqnum] = make_pkt(nextseqnumdatachksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ else refuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer

rdt_rcv(rcvpkt) ampamp notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) ampamp corrupt(rcvpkt)

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-46

GBN 接收端的擴充 FSM

只使用 ACK 只為接收順序正確的封包傳送 ACK 可能會產生重複的 ACK 只需要記住 expectedseqnum

順序不正確的封包 刪除 ( 不會暫存 ) -gt 接收端沒有暫存器 重新回應最高的順序正確封包

等待

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) ampamp notcurrupt(rcvpkt) ampamp hasseqnum(rcvpktexpectedseqnum)

extract(rcvpktdata)deliver_data(data)sndpkt = make_pkt(expectedseqnumACKchksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnumACKchksum)

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-47

GBN 的運作

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-48

選擇性重複 接收端分別確認所有正確接收的封包

依需要暫存封包 最終會依序傳送到上一層 傳送端只重傳沒有收到 ACK 的封包

傳送端針對每一個未確認的封包需要一個計時器 傳送端視窗

N 個連續的序號 再次用來限制傳送出去的 未確認的封包序號

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-49

選擇性重複 傳送端 接收端視窗

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-50

選擇性重複

來自上層的資料 假如下一個可用的序號在視窗內則傳送封包

timeout(n) 重送封包 n 重新啟動計時

器ACK(n) 在

[sendbasesendbase+N]中

將封包 n 標示為已收到的 假如 n 為未確認的封包中最

小的將視窗的 base 往前移到下一個未回應的序號

傳送端封包 n 在 [rcvbase

rcvbase+N-1] 中 傳送 ACK(n) 不正確的順序 暫存區 正確順序 遞送 (也遞送暫存區內順序錯誤的封包 ) 將視窗前進到下一個未接收的封包

封包 n 在 [rcvbase-Nrcvbase-1] 中

ACK(n)

否則 忽略該封包

接收端

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-51

選擇性重複的運作

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-52

選擇性重複 困難

範例 序號 0 1 2 3 視窗大小 =3

接收端無法分辨兩種情況的差別

不正確地重新傳送重複的資料如同 (a)

問題 序號大小和視窗大小間的關係為何

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-53

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-54

TCP 綜觀 RFCs 793 1122 1323 2018 2581

全雙工資料傳輸 同一個連結中雙向的資

料流 MSS 最大資料分段大小

連線導向 交握程序 ( 控制訊息的交換 ) 在資料開始交換之前設定傳送端和接收端的狀態

流量控制 傳送端不會超過接收端

點對點 一個傳送端 一個接收端

可靠的 有順序的位元組串流 沒有 ldquo訊息界線rdquo

管線化 TCP 壅塞控制和流量控制設定視窗大小

傳送端和接收端暫存器

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-55

TCP 資料分段結構

來源端埠號 接收端埠號

32 位元

應用程式資料( 不固定長度 )

序號確認號碼

接收端的視窗緊急資料指標網際網路檢查和

FSRPAU標頭長度

未使用的

選用欄位 ( 不固定長度 )

URG 緊急資料 ( 通常不會使用 )

ACK 確認有效

PSH 馬上將資料送出( 通常不會使用 )

RST SYN FIN連線建立

(設定 中斷指令 )

接收端願意接收的位元組數

以資料位元組計算 ( 非資料分段 )

網際網路檢查和( 如同 UDP)

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-56

TCP 序號與確認序號

資料分段中第一個位元的位元組串流 ldquo編號rdquo

確認 另一端期待的下一個

位元組序號 累積式確認

問題 接收端如何處理順序不正確的資料分段 答 TCP 規格中未限制取決於程式開發者

主機 A 主機 B

Seq=42 ACK=79 data = lsquoCrsquo

Seq=79 ACK=43 data = lsquoCrsquo

Seq=43 ACK=80

使用者鍵入字元

lsquoCrsquo

主機送出收到回應字元

lsquoCrsquo的 ACK 訊息

主機送出收到lsquoCrsquo的 ACK 訊息然

後回應字元 lsquo Crsquo

時序簡單的 telnet 範例

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-57

TCP 來回傳遞時間以及逾時問 如何設定 TCP

的逾時值 比 RTT 長

但是 RTT 是不固定的

太短 過早逾時 不需要重新傳送

太長 太晚對資料分段遺失作出反應

問 如何估計來回傳遞時間 ( RTT) 樣本 RTT 測量資料分段傳送出去

到收到確認所需的時間 忽略重傳

樣本 RTT 會有所變動我們想要讓預估的 RTT ldquo 更平滑rdquo 將好幾個最近的測量值做平均而非目前的樣本 RTT

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-58

TCP 來回傳遞時間以及逾時EstimatedRTT = (1- )EstimatedRTT + SampleRTT

指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值 = 0125

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-59

範例 RTT 估計 RTT gaiacsumassedu to fantasiaeurecomfr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-60

TCP 來回傳遞時間以及逾時設定逾時間隔 EstimtedRTT 加上 ldquo安全邊界rdquo

EstimatedRTT 的變動很大 -gt 大的安全邊界 首先估計 SampleRTT 與 EstimatedRTT 的差距

TimeoutInterval = EstimatedRTT + 4DevRTT

DevRTT = (1-)DevRTT + |SampleRTT-EstimatedRTT|

( 通常 = 025)

接著設定逾時間隔

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-61

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-62

TCP 可靠的資料傳輸 TCP 在 IP 的不可靠服

務上建立 rdt 服務 管線化的分段 累積式確認 TCP 使用單一的重新傳

送計時器

重新傳送的觸發 逾時事件 重複的 ack

一開始先考慮簡化的TCP 傳送端 忽略重複的 ack 忽略流量控制壅塞控制

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-63

TCP 傳送端事件 從應用程式收到資料 產生含有序號的資料分

段 序號是資料分段中第

一個資料位元組的位元組串流編號

假如計時器尚未執行啟動計時器 ( 將計時器想成與最久的未確認資料分段有關 )

逾時時間 TimeOutInterval

逾時 傳新傳送導致逾時的資

料分段 重新啟動計時器 收到 Ack 假如確認為之前未確認

的資料分段 更新已確認的狀態 假如還有未確認的資料分

段重新啟動計時器

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-64

TCP 傳送端( 簡化 )

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 gt SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer

end of loop forever

註解 bull SendBase-1 最後 一個累積式確認 位元組範例 bull SendBase-1 = 71y= 73 接收端想要 73+ y gt SendBase 因此新資料被確認

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-65

TCP 重新傳送的情況主機 A

Seq=100 20 bytes data

ACK=100

時序過早逾時

主機 B

Seq=92 8 bytes data

ACK=120

Seq=92 8 bytes data

序號

=92 逾

時間隔

ACK=120

主機 A

Seq=92 8 bytes data

ACK=100

loss逾時

的間隔

ACK 遺失的情況

主機 B

X

Seq=92 8 bytes data

ACK=100

時序

序號

=92 逾

時間隔

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-66

TCP 重新傳送的情況 ( 更多 )主機 A

Seq=92 8 bytes data

ACK=100

loss

逾時

間隔

累積式 ACK 的情況

主機 B

X

Seq=100 20 bytes data

ACK=120

time

SendBase= 120

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-67

TCP ACK 的產生 [RFC 1122 RFC 2581]

接收端的事件

內含預設序號的資料分段按照順序到達所有在預期序號之前的資料都已經確認

內含預期序號的資料分段按照順序到達另一個依序到達的資料分段正在等待 ACK 傳送

未依照順序且序號超過預期序號的資料分段到達偵測到序號中斷的情況

資料分段的到達可以部分或完全填滿已接收資料的中斷

TCP 接收端的動作

延後出發 ACK等待另一個應依順序到達的資料分段等待最多 500毫秒若下一個依序資料分段未在此時間間隔內到達則送出 ACK

立刻送出單一的累積式 ACK 確認這兩個依照序號到達的資料分段

立刻送出重複的 ACK 指出下一個預期到達為組的序號 (就是序號中斷範圍中的較低序號 )

即刻送出 ACK 如果資料從中斷的較低序號端開始填滿

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-68

快速重新傳送 逾時間隔通常相對地太長 在重傳遺失的封包前會有很長的延遲

經由重複的 ACK偵測到資料分段的遺失 傳送端經常連續傳送許多

資料分段 假如資料分段遺失了可

能會有許多大量的重複ACK

假如傳送端接收到 3 個ACK 它會假設已確認之後的資料已經遺失了 快速重新傳送 在計時器逾期之前會先傳送資料分段

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-69

event ACK received with ACK field value of y if (y gt 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-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-70

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-71

TCP 流量控制 TCP 連線的接收端有一

個接收緩衝區

速度調整服務 調整傳送端的速度與接收端應用程式能負擔的速度rsquo相符

應用程式的行程也許會以較慢的速度從緩衝區讀取資料

傳送端不會傳送太多太快的資料超過接收端的

緩衝區

流量控制

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-72

TCP 流量控制 如何運作

(假設 TCP 接收端會將順序不正確的資料分段捨棄 )

緩衝區內的剩餘空間= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

接收端將 RcvWindow值包含在資料分段裡以告知剩餘的空間

傳送端限制未確認的資料在 RcvWindow 之下 保證接收端緩衝區不會溢出

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-73

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-74

TCP 連線管理回想 TCP 傳送端接收端在

交換資料分段之前會先建立rdquo連線rdquo

將 TCP 變數初始化 序號 緩衝區流量控制資訊 (例如 RcvWindow)

用戶端 開始連線者 Socket clientSocket = new

Socket(hostnameport

number) 伺服端 被用戶端聯繫 Socket connectionSocket =

welcomeSocketaccept()

三路交握

步驟 1 用戶端主機傳送 TCP SYN 資料分段到伺服器 指定初始的序號 沒有資料

步驟 2 伺服端主機收到 SYN 以 SYNACK 資料分段回應 伺服端配置緩衝區 指定伺服端的初始序號

步驟 3 用戶端收到 SYNACK 回應 ACK 資料分段可能含有資料

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-75

TCP 連線管理 (續 )

關閉連線

用戶端關閉 socket clientSocketclose()

步驟 1 用戶端終端系統傳送 TCP FIN 控制分段到伺服端

步驟 2 伺服端 接收到 FIN以 ACK 回應關閉連線傳送 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-76

TCP 連線管理 (續 )

步驟 3 用戶端 收到 FIN 回應 ACK 訊息 進入 ldquo timed waitrdquo ndash

對接收到的 FIN 做確認的回應

步驟 4 伺服端收到 ACK連線關閉

注意 做一點小修改 可以處理同時的 FIN

用戶端

FIN

伺服端

ACK

ACK

FIN

關閉

關閉

已關閉

tim

ed w

ait

已關閉

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-77

TCP 連線管理 (續 )

TCP 用戶端生命週期

TCP 伺服端生命週期

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-78

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-79

壅塞控制的原則

壅塞 非正式地 ldquo太多的來源端傳送太多的資料對網路來說太快超過能處理的速度rdquo

與流量控制不同 表現形式

封包遺失 ( 路由器緩衝區溢出 ) 長的延遲 ( 在路由器緩衝區佇列中等待 )

前十大的問題

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-80

壅塞的原因和代價 情況 1 兩個傳送端兩個

接收端 一個路由器無限

的緩衝區 沒有重傳機制

當壅塞時會有很長的延遲

最大的可達成流通量

沒有限制的分享輸出連結緩衝器

主機 Ain original data

主機 B

out

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-81

壅塞的原因和代價 情況 2

一個路由器 有限的 緩衝區 傳送端會重新傳送遺失的封包

共享的有限輸出連結緩衝區

主機 A in 原始資料

主機 B

out

lsquoin 原始資料 加上重新傳送的資料

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-82

壅塞的原因和代價 情況 2 總是 (goodput 實際產量 )

ldquo理想的rdquo 重新傳送只在遺失

傳送延遲的封包 (並非遺失 ) 會使的 較大 (大於理想狀況 )在相同的 下

in

out

=

in

out

gt

in

out

壅塞的rdquo代價rdquo 對給定的 ldquo實際產量rdquo (goodput) 會有更多的工作 ( 重新傳輸 ) 不需要的重新傳輸 連結必須負擔多個封包的副本

R2

R2in

ou

t

b

R2

R2in

ou

t

a

R2

R2in

ou

t

c

R4

R3

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-83

壅塞的原因和代價 情況 3 四個傳送端 多次轉接路徑 逾時 重新傳送

inQ 當 和 增加時

會發生什麼情況

in

共享的有限輸出連結緩衝區

主機 Ain 原始資料的傳送速率

主機 B

out

lsquoin 原始資料加上重送資料的傳送速率

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-84

壅塞的原因和代價 情況 3

壅塞的另一個代價 當封包被丟掉時此封包所使用到的任何rdquo上游rdquo傳送容量就被浪費掉了

Host A

Host B

o

u

t

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-85

壅塞控制的方法

端點對端點壅塞控制 網路層並沒有提供明顯的協助

根據中端系統觀察到的遺失及延遲來判斷壅塞

TCP 採用的方法

網路協助的壅塞控制 路由器提供協助給終端系統

以一個位元來表示壅塞 (SNA DECbit TCPIP ECN ATM)

傳送端應該傳送的明確速率

壅塞控制的兩個主要方法

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-86

案例研究 ATM ABR 壅塞控制

ABR 可用的位元速率 ldquo彈性的服務rdquo 假如傳送端路徑 ldquo負載量很低rdquo時 傳送端可以利用可用的

頻寬 假如傳送端路徑壅塞時

傳送端減速到最小的保證速率

RM ( 資源管理 ) 封包單位 傳送端所傳送的配置在資料封

包單位中 RM 封包單位中的位元由交換

器設定 (ldquo 網路協助rdquo ) NI 位元 不增加速率 (輕微

壅塞 ) CI 位元 壅塞指示

RM 封包單位的位元由接收端原封不動地送回給傳送端

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-87

案例研究 ATM ABR 壅塞控制

RM 封包單位中兩個位元組的 ER (明確速率 ) 欄位 壅塞的交換器會降低封包單位中的 ER 值 因此傳送端的傳送速率為路徑上最低可支援速率

資料封包單位中的 EFCI 位元 在壅塞的交換器中設定為 1 假如 RM 封包單位之前的資料封包的 EFCI 都被設定則傳送端會將 CI 位元設定在回傳的 RM 封包單位中

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-88

第三章 傳輸層 31 傳輸層服務 32 多工和解多工 33 非預接式傳輸

UDP 34 可靠資料傳輸的原

理

35 連線導向傳輸 TCP 分段結構 可靠的資料傳輸 流量控制 連線管理

36 壅塞控制的原則 37 TCP 壅塞控制

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-89

TCP 壅塞控制 累積遞增倍數遞減 方法 增加傳送速率 ( 視窗大小 ) 探測可用的頻寬 直到發生遺失

的狀況累積遞增 每個 RTT 將 CongWin 加 1直到發生遺失倍數遞減 在發生遺失之後將 CongWin 減為一半

看到鋸齒形式頻寬的探測

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-90

TCP 壅塞控制 細節 傳送端限制速率 LastByteSent-LastByteAcked

CongWin 大致上

CongWin 是動態的 是察覺的網路壅塞函數

傳送端如何察覺到壅塞狀況

遺失事件 = 逾時或 3個重複的 ack

在遺失事件之後 TCP 傳送端會降低速率 (CongWin)

三個機制 AIMD 緩數啟動 發生逾時事件後的保守態

度

rate = CongWin

RTT Bytessec

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-91

TCP 緩速啟動 當連線一開始時 CongWin = 1 MSS 範例 MSS = 500 位元組

amp RTT = 200 毫秒 初始速率 = 20 kbps

可用的頻寬可能 gtgt MSSRTT 想要快速地增加到可接受的

速率

當連結開始時以指數型式增加速率直到第一個遺失發生

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-92

TCP 緩速啟動 ( 更多 )

當連結開始時以指數型式增加速率直到第一個遺失事件發生 在每次的 RTT 將 CongWin 增為一倍

每次收到 ACK 時會增加 CongWin

總結 開始的速率是緩慢的但會以指數形式快速增加速率

主機 A

第一個資料分段

RTT

主機 B

時間

第二個資料分段

第四個資料分段

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-93

再改良Q 指數形式的增長什麼

時候會轉換為線性的 A 當 CongWin 到達逾

時事件發生前的一半大小

實作 變數 Threshold 在遺失事件發生時

Threshold 會被設為遺失事件發生之前的 CongWin 的 12

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-94

再改良 推論遺失 在三個重複的 ACK 之後

CongWin 減為一半 視窗接下來會線性成長

但是在逾時事件後 CongWin 設為 1 MSS 視窗會以指數增長 到一個門檻接著以線性成長

3 個重複的 ACKs 表示網路有能力傳送某些資料分段 逾時表示較為嚴重的壅塞狀況

哲學

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-95

總結 TCP 壅塞控制

當 CongWin 在 Threshold 之下且傳送端在緩速啟動階段時視窗以指數成長

當 CongWin 在 Threshold 之上且傳送端在壅塞避免階段視窗以線性成長

當 三個重複的 ACK 發生時將 Threshold設定為 CongWin2 且 CongWin 設定為 Threshold

當 逾時 發生時 Threshold 設定為 CongWin2 且 CongWin 設定為 1 MSS

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-96

TCP 傳送端壅塞控制狀態 事件 TCP 傳送端動作 註解

緩速啟動 (SS)

收到下一個時確認資料的 ACK

CongWin = CongWin + MSS 如果 (CongWin gt Threshold) 設定狀態為「壅塞避免」

導致在每個 RTT 時間內CongWin 數值的倍增

壅塞避免 (CA)

收到下一個待確認資料的 ACK

CongWin = CongWin+MSS (MSSCongWin)

累加遞增導致 CongWin在每個 RTT 時間內增加1MSS

SS or CA 偵測到三個重複 ACK 的遺失事件

Threshold = CongWin2 CongWin = Threshold設定狀態為「壅塞避免」

快速回復採用倍數遞減 CongWin 值不會低於1MSS

SS or CA 逾時 Threshold = CongWin2 CongWin = 1 MSS設定狀態為「緩速啟動」

進入緩速啟動

SS or CA 重複 ACK 增加資料分段被確認的重複ACK記數

CongWin及 Threshold 不會改變

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-97

TCP 流通量

TCP 的平均流通量為何以視窗大小以及 RTT值的函數表示 忽略緩慢啟動階段

令 W 為遺失發生時的視窗大小 當視窗大小為W 時流通量為 WRTT 在遺失發生之後視窗馬上降為 W2 流通

量為 W2RTT平均流通量 75 WRTT

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-98

TCP 的未來

範例 1500 位元組資料分段 100 毫秒 RTT 想要達到 10 Gbps 的流通量

需要視窗大小 W = 83333 傳輸的資料分段 以遺失率計算流通量

L = 210-10 哇 我們需要高速環境下的新版 TCP

LRTT

MSS221

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-99

公平性目標 假如有 K 條 TCP 會談連線分享同一個瓶頸點連結的頻寬 R每一個應該有 RK 的平均速率

TCP 連結 1

瓶頸點路由器容量 R

TCP 連結 2

TCP 公平性

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-100

TCP 為什麼公平

兩個互相競爭的會談連線 隨著流通量增加累積遞增會導致 1 的斜率 倍數遞減會使得流通量成比例地遞減

R

R

平等的頻寬分享

連線 1 的流通量

連線2

的流

通量

壅塞避免 累積遞增遺失將視窗以 12 為因子遞減

壅塞避免 累積遞增遺失 將視窗以 12 為因子遞減

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-101

公平性 ( 更多 )

公平性和 UDP 多媒體應用程式通常不

會使用 TCP 不想藉壅塞控制限制速率

使用 UDP 來取代 以固定速率將音訊 視訊

送入網路容忍封包遺失 研究領域 TCP 的友善

性

公平性以及平行的 TCP 連結 無法防止應用程式在兩個主

機間開啟平行的連線 Web 瀏覽器會這樣做 範例 速率 R的連結支援

supporting 9 個程式 新的應用程式要求 1 個 TCP

則得到 R10 的速率 新的應用程式要求 11 個

TCP 則得到 R2 的速率

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-102

延遲模型

問 在傳送一個請求之後需要多久時間才能從Web 伺服器接收到一個物件

忽略壅塞的情況下延遲被下列因素影響

TCP 連線建立 資料傳輸延遲 緩慢啟動

符號 假設 假設在用戶端和伺服端之間有一個

速率為 R 的連結 S MSS ( 位元 ) O 物件大小 ( 位元 ) 不重新傳送 ( 沒有遺失沒有損毀 )

視窗大小 首先 固定的壅塞視窗 W 資料

分段 接著動態的視窗 緩速啟動模型

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-103

固定的壅塞視窗 (1)

第一個情況 WSR gt RTT + SR 在完成視窗的傳輸之前便可接收到第一個資料分段的確認

delay = 2RTT + OR

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-104

固定的壅塞視窗 (2)

第二個情況 WSR lt RTT + SR 在視窗的傳輸完成之後等待確認訊息

delay = 2RTT + OR+ (K-1)[SR + RTT - WSR]

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-105

TCP 延遲模型 緩速啟動 (1)

現在假設視窗依據緩速啟動增長

我們可以證明一個物件的延遲為

R

S

R

SRTTP

R

ORTTLatency P )12(2

其中 P 為 TCP 在伺服器停止的次數

1min KQP

- Q 為物件含有無限數量的資料分段情況下伺服器停止的次數

- K 為涵蓋物件資料的視窗數量

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-106

TCP 延遲模型 緩速啟動 (2)

範例 bull OS = 15 資料分段bull K = 4 視窗bull Q = 2bull P = minK-1Q = 2

伺服器停止 P=2 次

延遲元件 bull 2 RTT 用來做連線建立以及請求bull OR 用來傳輸物件bull 伺服器因緩速啟動而停止的時間

伺服器停止 P = minK-1Q 次

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-107

TCP 延遲模型 緩速啟動 (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

RTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2

1

1

1

停止時間延遲

個視窗之後的停止時間在第 k 2 1

R

SRTT

R

S k

分段到收到確認的時間當伺服器開始傳送資料 RTTR

S

個視窗的時間傳送第kR

Sk 12

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-108

TCP 延遲模型 (4)

)1(log

)1(logmin

12min

222min

222min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Q 物件含有無限數量的資料分段情況下伺服器停止的次數的計算是類似的 (見習題 )

回想 K =涵蓋物件資料的視窗數量

要怎麼計算 K

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-109

HTTP 模型 假設網頁包含

1 基本的 HTML 文件 (大小為 O 位元 ) M 影像檔 (大小為 O 位元 )

非永久性 HTTP 一系列 M+1 TCP 連結 回應時間 = (M+1)OR + (M+1)2RTT + 閒置次數的總合

永久性 HTTP 2 RTT 用來請求及接收基本的 HTML 檔案 1 RTT 用來請求和接收 M 個影像檔 回應時間 = (M+1)OR + 3RTT + 閒置次數的總合

非永久性 HTTP 具有 X 個平行連結 假設 MX 為整數 基本檔案使用 1 TCP 連結 影像使用 MX 組平行連結 回應時間 = (M+1)OR + (MX + 1)2RTT + 閒置次數的總合

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-110

02468

101214161820

28Kbps

100Kbps

1Mbps

10Mbps

非永久性

永久性

平行非永久性

HTTP 回應時間 ( 以秒為單位 )RTT = 100 毫秒 O = 5 Kbytes M=10 以及 X=5

在低的頻寬時連結和回應時間主要受傳輸時間影響

永久性連結只比平行連結多一點進步

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-111

0

10

20

30

40

50

60

70

28Kbps

100Kbps

1 Mbps 10Mbps

非永久性

永久性

平行永久性

HTTP 回應時間 ( 以秒為單位 )

RTT =1 秒 O = 5 Kbytes M=10 and X=5

在 RTT很大時回應時間主要受到 TCP 連線建立以及緩速啟動的延遲影響現在使用永久性連結有很大的進步了特別是在高延遲頻寬的網路

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112

Transport Layer 3-112

第三章 總結 傳輸層服務的原則

多工 解多工 可靠的資料傳輸 流量控制 壅塞控制

網際網路上的例證和實作 UDP TCP

接下來 離開網路 ldquo邊緣rdquo (

應用 傳輸層 ) 進入網路 ldquo核心rdquo

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82
• Slide 83
• Slide 84
• Slide 85
• Slide 86
• Slide 87
• Slide 88
• Slide 89
• Slide 90
• Slide 91
• Slide 92
• Slide 93
• Slide 94
• Slide 95
• Slide 96
• Slide 97
• Slide 98
• Slide 99
• Slide 100
• Slide 101
• Slide 102
• Slide 103
• Slide 104
• Slide 105
• Slide 106
• Slide 107
• Slide 108
• Slide 109
• Slide 110
• Slide 111
• Slide 112