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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24. 3: Transport Layer 3a-
rdt3.0 sender

25. 3: Transport Layer 3a-
rdt3.0 in action

26. 3: Transport Layer 3a-
rdt3.0 in action

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

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

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

30. 3: Transport Layer 3a-
GBN: sender extended FSM

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

32. 3: Transport Layer 3a-
GBN in
action

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

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

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

36. 3: Transport Layer 3a-
Selective repeat in action

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

38. 3: Transport Layer 3a-
TCP: 概觀 RFCs: 793, 1122, 1323, 2018, 2581
全雙工資料 :
同一個連線的雙向資料流
MSS: 最大分節大小 ( 最
大 segment size)
連線導向 :
handshaking ( 交換控制訊
息 ) 在資料交換前初始化
傳送端 , 接收端 獎態
流量控制 :
傳送端 不會把 接收端 的
緩衝區 灌滿
點對點 :
一個 傳送端 , 一個 接收端
可靠的，順序的 位元組
序列 :
無 “ message boundaries”
pipelined:
TCP 壅塞和流量控制決定
window size
送 & 收 緩衝區 s
s o c k e t
d o o r
T C P
s e n d b u f f e r
T C P
r e c e iv e b u f f e r
s o c k e t
d o o r
s e g m e n t
a p p lic a t io n
w r it e s d a ta
a p p lic a t io n
r e a d s d a t a

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

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

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

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

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

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

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

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

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

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

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

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

51. 3: Transport Layer 3a-
TCP 連線管理 (cont)
TCP 客戶端
生命週期
TCP 伺服器
生命週期

52. 3: Transport Layer 3a-
Principles of 壅塞 控制
壅塞 :
非正式說法 : “ 太多來源端傳送太多資料或太快以致
於網路無法處理”
不同於流量控制 !
表現形式 :
遺失封包 ( 路由器的緩衝區滿溢 )
有長 delays ( 在路由器緩衝區的 queuing)
一個前十名的問題 !

53. 3: Transport Layer 3a-
Causes/costs of 壅塞 : 場景 1
兩個傳送端 , 兩個
接收端
一個路由器 , 無限
緩衝區
無重傳
當壅塞時有大
delay
最大可達的產量
（ throughput
）

54. 3: Transport Layer 3a-
壅塞的起因 / 花費 : 場景 2
一個路由器 , 有限的緩衝區
傳送端重傳遺失的封包

55. 3: Transport Layer 3a-
Chapter 3: Summary
在傳輸層服務背後的原則 :
多工 / 解多工
可靠的資料傳輸
流量控制
擁塞控制
在 Internet 上的例子與實作
UDP
TCP
下一步 :
離開網路的 “邊緣”
( 應用 傳輸層 )
進入網路的 “核心”