《第三章传输层.ppt》由会员分享，可在线阅读，更多相关《第三章传输层.ppt（55页珍藏版）》请在三一办公上搜索。
1、3:Transport Layer,3a-1,第三章:傳輸層,章節目標：了解傳輸層所提供的服務之背後原理：多工傳輸/分工傳輸可靠的資料傳輸流量控制擁塞控制在網際網路上舉例說明以及實做,章節概要：傳輸層的服務多工傳輸/分工傳輸無連接傳輸模式：UDP可靠的資料傳輸原理連接導向傳輸：TCP可靠的資料傳輸流量控制連接管理擁塞控制原理TCP 擁塞控制,3:Transport Layer,3a-2,傳輸服務及協定,提供在不同的主機上執行的應用程序一種邏輯式的通訊方式傳輸層是在每個末端主機上運行傳輸層 vs 網路層服務：網路層：資料是在主機與主機間做傳輸傳輸層：資料是在程序與程序間作傳輸 必須依賴網路層服務
2、,3:Transport Layer,3a-3,傳輸層通訊協定,網際網路傳輸服務：可靠的,按照順序的單撥(unicast)傳輸：TCP擁塞 流量控制連線設定不可靠的(最省力式“best-effort”),不按照順序的單撥或多撥(multicast)傳輸：UDP不可用的服務：即時服務頻寬保證可靠的多撥,3:Transport Layer,3a-4,P2,多工傳輸/分工傳輸,回想：資料段 在傳輸層實體間作交換的資料單元aka TPDU:傳輸層資料單元,接收者,H,t,分工傳輸：傳送收到的資料段到正確的應用層程序中,segment,資料段,M,P1,P3,P4,資料段標頭,應用層資料,3:Trans
3、port Layer,3a-5,多工傳輸/分工傳輸,多工傳輸/分工傳輸：以傳送者、接收者的連接埠號、IP位置為基準每個資料段中，傳送者、接收者的連接埠號回想：特定的應用軟體具有廣為了解的埠號,從不同的應用程序中收集資料，由標頭將資料包住(之後將用於分工傳輸),來源端埠號,目的地端埠號,32 bits,應用程式資料(訊息),其他標頭區域,TCP/UDP 資料段格式,3:Transport Layer,3a-6,多工傳輸/分工傳輸：範例,主機 A,伺服器 B,使用的埠:簡易遠端登入應用程式,網路客戶端主機 A,網路伺服器 B,網路客戶端主機 C,使用的埠:網路伺服器,3:Transport Lay
4、er,3a-7,UDP:用戶資料訊息協定 RFC 768,“no frills,”“bare bones”網路傳輸協定“最省力式”服務,UDP 資料段可能形式為：易遺失的傳送不按照順序排列的資料段給應用程式非連線導向式：UDP傳送者與接收者之間沒有互相交換控制訊息每個 UDP 資料段自己獨立地操作,為什麼會有UDP?無需建立連線(建立連線可能會增加delay)簡單：沒有連線狀態記錄在傳送者與接收者上資料段標頭欄很小沒有擁塞控制：UDP 可以如同疾風般地快速散撥資料段,3:Transport Layer,3a-8,UDP:更多資訊,通常用於多媒體資料串流應用程式上能容忍資料段遺失對速率相當敏感其
5、他 UDP 的使用(為什麼要用UDP?):DNS 網域名稱系統SNMP 簡易網路管理協定在UDP上做可靠傳輸：在應用層增加可靠度特殊應用程式錯誤回復!,來源端埠號,目的地端埠號,32 bits,應用程式資料(訊息),UDP 資料段格式,長度,加總檢查,長度,在UDP資料段中是以位元組計算,包含標頭欄,3:Transport Layer,3a-9,UDP 加總檢查,傳送者：將資料段中的內容看成連續的16位元整數加總檢查：將資料段中內容相加(1s complement sum)傳送者將加總檢查值放入UDP加總檢查欄中,接收者：計算收到資料段的加總檢查查看是否算出來的值跟加總檢查欄中的值相同：NO
6、偵測到錯誤YES 沒有偵測到錯誤.但是可能仍然有錯誤?接下來繼續討論.,目標：偵測傳送後的資料段中的”錯誤”(e.g.,錯誤位元),3:Transport Layer,3a-10,可靠資料傳輸原理,在應用、傳輸、連結層具有很大的重要性前十大重要的網路論題!,不可靠的頻道之特性,將會決定可靠資料傳輸協定(rdt)的複雜度。,3:Transport Layer,3a-11,可靠資料傳輸：開端,傳送端,接收端,3:Transport Layer,3a-12,可靠資料傳輸：開端,我們將會：漸增地開發傳送端與接收端的可靠資料傳輸協定(rdt)考慮只有單向的資料傳輸但是控制資訊將會雙向傳送!利用有限狀態機
7、(FSM)來詳細說明傳送端與接收端,造成狀態轉變的事件,狀態轉變時所要做的動作,狀態:當身處於這個”狀態”時,接下來將進入哪個狀態只能由下一個發生事件來決定,3:Transport Layer,3a-13,Rdt1.0:在可靠頻道上作可靠傳輸,底層的頻道絕對可靠沒有位元錯誤沒有封包遺失分開討論傳送端與接收端的有限狀態機:傳送端將資料送入底層的頻道接收端從底層的頻道讀取資料,3:Transport Layer,3a-14,Rdt2.0:利用錯誤位元的頻道,底層的頻道可能會使封包中的位元發生錯誤回想：UDP 加總檢查去偵測錯誤位元問題:如何從錯誤中回復:認可(ACKs):接收端會明確地告訴傳送端封
8、包已接收完成否定認可(NAKs):接收端會明確地的告訴傳送端封包有錯誤在接收到否定認可之後，傳送端會重新傳送封包人類的劇本也是有認可跟否定認可嗎?rdt2.0 的新機制(beyond rdt1.0):錯誤偵測接收端回饋:控制訊息(認可,否定認可)接放端-傳送端,3:Transport Layer,3a-15,rdt2.0:詳述有限狀態機,傳送端的有限狀態機,接收端的有限狀態機,3:Transport Layer,3a-16,rdt2.0:運作中的情形(沒有錯誤發生),傳送端的有限狀態機,接收端的有限狀態機,3:Transport Layer,3a-17,rdt2.0:運作中的情形(有錯誤發生)
9、,傳送端的有限狀態機,接收端的有限狀態機,3:Transport Layer,3a-18,rdt2.0 有一個潛在的缺點!,假如 ACK/NAK發生毀損會發生什麼?傳送端並不知道接收端發生什麼情況!不是僅僅重送:可能造成重覆What to do?傳送端 認可/否定 接收端的 ACK/NAK?如果傳送端的ACK/NAK遺失該怎麼辦?重送,但是可能造成正確被接收的封包再一次重送！,處理重複的封包：傳送端加入 順序編號 到每一個封包 假如ACK/NAK毀損，則傳送端重傳現在的封包接收端丟棄(doesnt deliver up)重覆的封包,傳送端送出一個封包，然後等待接收端的回應,3:Transpor
10、t Layer,3a-19,rdt2.1:sender,handles garbled ACK/NAKs,3:Transport Layer,3a-20,rdt2.1:receiver,handles garbled ACK/NAKs,3:Transport Layer,3a-21,rdt2.1:討論,傳送端:在封包中加入順序號碼兩個順序號碼(0,1)足夠嗎？為什麼?必需確定是否收到的錯誤的ACK/NAK狀態數目的兩倍狀態必需”記住”現在”的順序號碼是0還是1,接收端:必需確定是否收到重覆的封包狀態會指示預期的順序號碼是0或是1注意:接收端不知道它上次發送的ACK/NAK是否成功的送達傳送端,
11、3:Transport Layer,3a-22,rdt2.2:a NAK-free protocol,某些函式如 rdt2.1只使用NAKs 接收端傳送ACK表示成功收到最後一個封包，而不用 接收端必需清楚的將表示所回覆的封包順序號碼傳送端收到重覆的ACK會做出和收到NAK相同的反應:重送現在的封包,senderFSM,!,3:Transport Layer,3a-23,rdt3.0:有錯誤和遺失的頻道,新的假設:基礎的頻道也可能遺失封包(資料或是ACKs)加總比對方法,順序號碼,ACKs,重新傳送，都有幫助，但並不足夠Q:如何處理遺失?傳送端等待，直到有些資料或是ACK遺失再傳新傳送缺點?,
12、方法:send傳送端等待ACK，持續一段”合理”的時間如果在這段時間內都沒有收到ACK，則開始重傳 如果封包(或ACK)只是延遲了(不是遺失了):重傳會造成重覆的封包，但是利用順序號碼已經可以處理這個問題接受端必需註明ACK是在回應哪個順序號碼的封包需要有倒數計時器,3:Transport Layer,3a-24,rdt3.0 sender,3:Transport Layer,3a-25,rdt3.0 in action,3:Transport Layer,3a-26,rdt3.0 in action,3:Transport Layer,3a-27,Performance of rdt3.0,
13、rdt3.0 可行，但效果不張例子:頻寬1 Gbps,點對點傳輸延遲15 ms,封包大小1KB:,每微秒送個1KB大小的封包msec-則在頻寬為1 Gbps 的連結上的吞吐量為33kB/秒 網路的通訊協訂限制了物理層的資源!,3:Transport Layer,3a-28,加入管線觀念的協定,管線觀念:send傳送端允許多個”正在傳送中”但還末被回覆ACK的封包必需增加順序號碼的範圍暫存在傳送端或是接收端,兩種使用管線觀念的協定:go-Back-N,selective repeat,3:Transport Layer,3a-29,Go-Back-N,傳送端:在封包的標頭內包含了個位元的順序號碼
14、“視窗”內最多允許有連續N 個尚末被回覆ack的封包,ACK(n):回覆的ACKs所加註的順序號碼最多到n-“累計的 ACK”可能收到重覆的ACKs(端看傳送端)為那些正在傳送中的封包設置一個計時器超時(n):retransmit重傳順序號碼為n的封包及視窗內所有順序號碼大於n 的封包,3:Transport Layer,3a-30,GBN:sender extended FSM,3:Transport Layer,3a-31,GBN:receiver extended FSM,簡單的接收端:ACK-only:總是回覆現在依照順序成功收到的封包裡，順序號碼最大的封包可能產生重覆的ACKs只需要
15、記住預期的順序號碼失序的封包:丟棄(不需要暫存)-不需要接收端去暫存!只需要回覆有照順序中最大號碼的封包,3:Transport Layer,3a-32,GBN inaction,3:Transport Layer,3a-33,Selective Repeat,接收端分別對所以正確接收的封包一一回覆為了要能將封包照順序的傳送給上層，需要暫存封包傳送端只要重送沒有收到回覆的封包傳送端會幫每個還未收到ACK得封包計時傳送端的視窗N 個連續的順序號碼再一次限制最多可以有多少沒有收到ACK的封包可以傳送,3:Transport Layer,3a-34,Selective repeat:sender,r
16、eceiver windows,3:Transport Layer,3a-35,Selective repeat,來自上層的資料如果有可用的順序號碼，則將封包發送出去超時(n):重新傳送封包 n,並將計時器重新啟動ACK(n)in sendbase,sendbase+N:標記封包 n收到了如果n小於最小一個還未收到回覆的封包號碼，則將視窗的下限值增加到下一個還未覆的順序號碼,封包的順序號碼落在 rcvbase,rcvbase+N-1send ACK(n)失序的:暫存起來照順序的:傳送(暫存起來中也有照順序的封包也傳送出去),調整視窗到下一個還沒收到的封包封包的順序號碼落在rcvbase-N,r
17、cvbase-1ACK(n)其他:忽略,3:Transport Layer,3a-36,Selective repeat in action,3:Transport Layer,3a-37,Selective repeat:dilemma,Example:seq#s:0,1,2,3window size=3兩種情景下 接收端 感覺不出差異!in(a)不正確地傳送同一份資料做為新的Q:seq#和 window size 有什麼樣的關係?,3:Transport Layer,3a-38,TCP:概觀 RFCs:793,1122,1323,2018,2581,全雙工資料:同一個連線的雙向資料流MSS
18、:最大分節大小(最大 segment size)連線導向:handshaking(交換控制訊息)在資料交換前初始化 傳送端,接收端 獎態流量控制:傳送端 不會把 接收端 的 緩衝區 灌滿,點對點:一個 傳送端,一個 接收端 可靠的，順序的 位元組 序列:無“message boundaries”pipelined:TCP 壅塞和流量控制決定 window size送&收 緩衝區s,3:Transport Layer,3a-39,TCP 節區架構,URG:urgent 資料(一般來說不會用到),ACK:ACK#valid,PSH:push 資料 now(一般來說不會用到),RST,SYN,FIN
19、:連線建立(建立、解除命令),接收端 想要收的 位元組 數量,以資料的 位元組 數計算(不是節區!),Internetchecksum(as in UDP),3:Transport Layer,3a-40,TCP seq.#s and ACKs,Seq.#s:節區資料裡首位元的位元組流數目ACKs:另一邊預期的下一個位元組的 seq#累進的 ACKQ:接收端 如何處理順序顛到的節區呢?A:TCP 規格書未明載由實作者決定,主機 A,主機 B,Seq=42,ACK=79,資料=C,Seq=79,ACK=43,資料=C,Seq=43,ACK=80,使用者輸入C,主機收到回應的 ACKs C,主機收
20、到 ACKsC,回應 C,簡易的 telnet 場景,3:Transport Layer,3a-41,TCP:可靠的資料傳輸,精簡化 傳送端,假設,waitfor event,等待事件,事件:應用程式接收資料,事件:計時器等待 segment with seq#y逾時,事件:收到 ACK#y 的 ACK,建位，送出 segment,重送 segment,ACK 處理,單向資料傳送無流量和壅塞控制,3:Transport Layer,3a-42,TCP:可靠的資料傳輸,00 傳送base=initial_sequence number 01 nextseqnum=initial_sequence
21、 number 0203 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
22、 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 ACKe
23、d segment*/20 increment number of duplicate ACKs 接收d for y 21 if(number of duplicate ACKS 接收d for y=3)22/*TCP fast retransmit*/23 re傳送 segment with sequence number y 24 restart 時間r for segment y 25 26/*end of loop forever*/,精簡化的TCP傳送端,3:Transport Layer,3a-43,TCP ACK 產生 RFC 1122,RFC 2581,事件依序排列的 segm
24、ent 來到,無 gaps,其它的都已經 ACKed依序排列的 segment 來到,無 gaps,一個延遲的 ACK 未決亂序的 segment 來到,比預期大的 seq.#偵測到 gap 部分或完全充滿 gap 的 segment 來到,TCP 接收端動作延遲 ACK.等待下一個 segment 至多 500ms.如果沒有下一個segment,送出 ACK立即送出單一的累進 ACK送出複製的 ACK,表示下一個預期的位元組的 seq.#如果 segment 在 gap 較底端開始，立即 ACK,3:Transport Layer,3a-44,TCP:重傳 場景s,主機 A,Seq=100,
25、20 位元組 資料,ACK=100,Seq=92 逾時,過早 逾時,累進的 ACKs,主機 B,Seq=92,8 位元組 資料,ACK=120,Seq=92,8 位元組 資料,Seq=100 逾時,ACK=120,3:Transport Layer,3a-45,TCP 流量控制,接收端:明確地通知 傳送端空的緩衝區 大小(動態地改變)TCP segment 裡的RcvWindow欄傳送端:保持傳送的總數,未 ACK 的資料 少於最近接收的 RcvWindow,傳送端不會因為傳送太多、太快而超過接收端的緩衝區,接收端緩衝區,RcvBuffer=大小或 TCP 接收的緩衝區RcvWindow=空的
26、緩衝區總數,3:Transport Layer,3a-46,TCP Round Trip 時間 and 逾時,Q:如何設定 TCP 逾時 值?較 RTT 值大注意:RTT 會變太短:過早逾時不必要重傳太長:對於 segment 遺失反應較慢,Q:如何估計 RTT?SampleRTT:接受 ACK 之前從 segment 傳輸所測量到的時間忽略重傳,累進地 ACK segmentsSampleRTT 會變,希望估計的 RTT“較平穩”使用一些最近的測量值,而不只是目前的 SampleRTT,3:Transport Layer,3a-47,TCP Round Trip Time 及逾時,Estim
27、atedRTT=(1-x)*EstimatedRTT+x*SampleRTT,Exponential weighted moving averageinfluence 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|,3:Transp
28、ort Layer,3a-48,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#
29、Step 2:伺服端系統接收 SYN,回應 SYNACK 控制 segmentACKs 接收 SYN配置緩衝區指明伺服器-接收端起始的 seq.#,3:Transport Layer,3a-49,TCP 連線管理(cont.),Closing a 連線:客戶端關閉連線:ClientSocket.Close();Step 1:客戶端系統傳送 TCP FIN segment 到伺服器 Step 2:伺服器 接收 FIN,回應 ACK.關閉連線,傳送 FIN.,3:Transport Layer,3a-50,TCP 連線管理(cont.),Step 3:客戶端,接收 FIN,回應 ACK.進入“時間
30、等待”為接收到的 FINs 回應 ACKStep 4:伺服器,接收 ACK.連線關閉.Note:稍做修改即可處理同時產生的FINs,客戶端,FIN,伺服器,ACK,ACK,FIN,關閉,關閉,關閉,時間等待,關閉,3:Transport Layer,3a-51,TCP 連線管理(cont),TCP 客戶端生命週期,TCP 伺服器生命週期,3:Transport Layer,3a-52,Principles of 壅塞 控制,壅塞:非正式說法:“太多來源端傳送太多資料或太快以致於網路無法處理”不同於流量控制!表現形式:遺失封包(路由器的緩衝區滿溢)有長 delays(在路由器緩衝區的 queui
31、ng)一個前十名的問題!,3:Transport Layer,3a-53,Causes/costs of 壅塞:場景 1,兩個傳送端,兩個接收端一個路由器,無限緩衝區無重傳,當壅塞時有大 delay最大可達的產量（throughput）,3:Transport Layer,3a-54,壅塞的起因/花費:場景 2,一個路由器,有限的緩衝區傳送端重傳遺失的封包,3:Transport Layer,3a-55,Chapter 3:Summary,在傳輸層服務背後的原則:多工/解多工可靠的資料傳輸流量控制擁塞控制在Internet上的例子與實作UDPTCP,下一步:離開網路的“邊緣”(應用 傳輸層)進入網路的“核心”,
