計算機網(wǎng)絡-3

1、 運輸層1第3章 運輸層Transport Layer 計算機網(wǎng)絡：自頂向下方法 (原書第四版)陳鳴譯，機械工業(yè)出版社，2010年Computer Networking: A Top Down Approach , 4rd edition. Jim Kurose, Keith RossAddison-Wesley, July 2008. 運輸層2第3章:運輸層目標: r理解運輸層服務依據(jù)的原理:m復用/分解m可靠數(shù)據(jù)傳輸m流量控制m擁塞控制r學習因特網(wǎng)中的運輸層協(xié)議：mUDP: 無連接傳輸mTCP: 面向連接傳輸mTCP 擁塞控制 運輸層3第3章 要點r3.1 運輸層服務r3.2 復用與分解r

2、3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控制的原則r3.7 TCP擁塞控制m機制mTCP吞吐量mTCP公平性m時延模型 運輸層43.1運輸服務和協(xié)議r為運行在不同主機上的應用進程之間提供邏輯通信r應用層使用其邏輯功能，不需考慮物理設施P124r運輸協(xié)議運行在端系統(tǒng)中m發(fā)送方：將應用報文劃分為段，傳向網(wǎng)絡層m接收方：將段重新裝配為報文，傳向應用層r路由器？運行在網(wǎng)絡層P124r可供應用程序使用的運輸協(xié)議不止一個m因特網(wǎng)：TCP和UDP應用層運輸層

3、網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層邏輯端到端傳輸 運輸層53.1.1運輸層 vs. 網(wǎng)絡層r網(wǎng)絡層: 主機間的邏輯通信r運輸層: 進程間的邏輯通信m依賴并強化網(wǎng)絡層服務家庭類比:12個孩子向12個孩子發(fā)信r進程 = 孩子r應用報文= 信封中的信r主機 = 家庭r運輸協(xié)議 = Ann和Billr網(wǎng)絡層協(xié)議= 郵政服務 運輸層6因特網(wǎng)運輸層協(xié)議P126r可靠的、按序的交付 (TCP)m擁塞控制m流量控制m連接建立r不可靠、不按序交付: UDPm“盡力而為”IP的不提供

4、不必要服務的擴展r網(wǎng)絡層IP協(xié)議：為主機之間提供盡力而為的交付服務，不可靠的r網(wǎng)絡層的主機之間的交付擴展為運輸層主機進程之間的交互：多路復用與多路分解應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層應用層運輸層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層網(wǎng)絡層數(shù)據(jù)鏈路層物理層邏輯端到端傳輸 運輸層7第3章 要點r3.1 運輸層服務r3.2 復用與分解r3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控

5、制的原則r3.7 TCP擁塞控制m機制mTCP吞吐量mTCP公平性m時延模型 運輸層83.2 Internet 層的復用與分解運輸層運輸層網(wǎng)絡層WEBFTPTELNETTELNET如何實現(xiàn)交付給不同的應用層進程？ 運輸層93.2 復用/分解(類比家庭收信/發(fā)信)= 進程= 套接字 將接收到的報文段分解交付 給正確的套接字在接收主機分解：從多個套接字收集數(shù)據(jù)，用首部封裝數(shù)據(jù)(以后用于分解 )生成報文段，傳遞到網(wǎng)絡層在發(fā)送主機復用:應用層運輸層網(wǎng)絡層鏈路層物理層P1應用層運輸層網(wǎng)絡層鏈路層物理層應用層運輸層network鏈路層物理層P2P3P4P1主機1主機2主機3端口r套接字有唯一標識符r每個報

6、文段用端口號指示要交付的套接字r端口號：16bitr0-65535r周知端口號（默認保留）：0-1023 運輸層10 運輸層113.2分解工作過程r主機接收IP數(shù)據(jù)報m每個數(shù)據(jù)報有源IP地址, 目標IP地址m每個數(shù)據(jù)報承載1個運輸層的段m每個段具有源、目的端口號 源端口 #目的端口 #32 bits應用數(shù)據(jù)(報文)其他首部字段TCP/UDP 段格式 運輸層123.2分解工作過程r主機上的每個套接字被分配一個端口號，當報文段到達主機時，運輸層檢查報文段中的目的端口號，并將其定向到相應的套接字。套接字完成數(shù)據(jù)到應用程序的交互。源端口 #目的端口 #32 bits應用數(shù)據(jù)(報文)其他首部字段TCP/

7、UDP 段格式 運輸層133.2.1無連接分解P130r生成具有端口號的套接字:DatagramSocket mySocket1 = new DatagramSocket(99111);DatagramSocket mySocket2 = new DatagramSocket(99222);rUDP套接字由二元組標識 :r當主機接收UDP段時:m在段中檢查目的地端口號m將UDP段定向到具有該端口號的套接字過程：發(fā)送方創(chuàng)建運輸層報文段，包括數(shù)據(jù)、源端口號，目的端口號，和其它值，傳遞到網(wǎng)絡層封裝為IP數(shù)據(jù)報，盡力而為交付給接收方。接收方檢查目的端口號，并將該報文段傳遞給端口號所標識的套接字。r具有

8、不同源IP+PORT，但具有相同IP+PORT的數(shù)據(jù)將交給相同的套接字？ 運輸層143.2.1無連接分解(續(xù))DatagramSocket serverSocket = new DatagramSocket(6428);客戶機客戶機IP:BP2客戶機 IP: AP1P1P3服務器IP: CSP: 6428DP: 9157SP: 9157DP: 6428SP: 6428DP: 5775SP: 5775DP: 6428SP提供了“返回地址” 運輸層153.2.2面向連接分解P130rTCP套接字由四元組標識: m源IP地址m源端口號m目的IP地址m目的端口號r接收主機使用這四個值來將段定向到適當?shù)?/p>

9、套接字r具有不同源IP+PORT，但具有相同IP+PORT的數(shù)據(jù)將交給相同的套接字？ 運輸層163.2.2面向連接分解 (續(xù))客戶機IP:BP1客戶機 IP: AP1P2P4服務器IP: CP5P6P3SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80D-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: B 運輸層173.2.2面向連接分解-服務器P131r服務器主機可能支持許多并行的TCP套接字：m每個套接字由其自己的四元組標識rWeb服務器對每個連接的客戶機分配不同的套接字m非持久HTTP將為每個請求分配不同的套接字 運輸層183.2

10、.2面向連接分解: 多線程Web服務器P132客戶機IP:BP1客戶機 IP: AP1P2P4服務器IP: CP5P6P3SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80D-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: BP2線程進程 運輸層19第3章 要點r3.1 運輸層服務r3.2 復用與分解r3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控制的原則r3.7 TCP擁塞控制m機制mTC

11、P吞吐量mTCP公平性m時延模型 運輸層203.3UDPr完成哪些工作？m多路復用/多路分解m輕量級的差錯檢測r工作過程？發(fā)送方-接收方m在UDP發(fā)送方和接收方之間無握手m每個UDP段的處理獨立于其他段rDNS?P133r“沒有不必要的,” “基本要素” 互聯(lián)網(wǎng)傳輸協(xié)議r“盡力而為”服務，UDP段可能：m丟包m對應用程序交付失序 運輸層213.3UDP: 用戶數(shù)據(jù)報協(xié)議 RFC 768為何要有 UDP協(xié)議?r直接通過應用層控制要發(fā)送的數(shù)據(jù)和發(fā)送時間r無需創(chuàng)建連接(它將增加時延)r簡單：在發(fā)送方、接收方無連接狀態(tài)r段首部長度小r無擁塞控制: UDP能夠盡可能快地傳輸r圖3-6流行的應用層協(xié)議與運

12、輸層協(xié)議 運輸層223.3.1UDP報文段r常用于流式多媒體應用m丟包容忍m速率敏感r其他UDP應用mDNSmSNMPr經(jīng)UDP的可靠傳輸 : 在應用層增加可靠性m應用程序使用特定的差錯恢復！源端口#目的端口#32 bits應用數(shù)據(jù)(報文)UDP 段格式長度檢查和UDP段的長度，包括首部，以字節(jié)計 運輸層233.3.2UDP檢驗和發(fā)送方:r將段內(nèi)容處理為16比特整數(shù)序列r檢驗和: 段內(nèi)容的加法(反碼和)r發(fā)送方將檢驗和放入UDP檢驗和字段接收方:r計算接收的段的檢驗和r核對計算的檢驗和是否等于檢驗和字段的值:mNO 檢測到差錯mYES 無差錯檢測到。雖然如此，還可能有差錯嗎？詳情見后目的: 在

13、傳輸?shù)亩沃袡z測“差錯” (如比特翻轉(zhuǎn)) 運輸層24互聯(lián)網(wǎng)檢查和例子sumchecksumwraparoundreceiver1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 11 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 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 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 1r注意m當數(shù)字作加法時，最高位進比特位的進位需要加到結(jié)果中r例子: 兩個16-bi

14、t整數(shù)相加 運輸層25第3章 要點r3.1 運輸層服務r3.2 復用與分解r3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控制的原則r3.7 TCP擁塞控制m機制mTCP吞吐量mTCP公平性m時延模型 運輸層26Principles of Reliable data transferr在應用層、運輸層、數(shù)據(jù)鏈路層非常重要m是網(wǎng)絡主題中的最重要的10個之一!r不可靠信道的特點決定了可靠數(shù)據(jù)傳輸 協(xié)議 (rdt) 的復雜性 運輸層27Principles

15、 of Reliable data transferr在應用層、運輸層、數(shù)據(jù)鏈路層非常重要m是網(wǎng)絡主題中的最重要的10個之一!r不可靠信道的特點決定了可靠數(shù)據(jù)傳輸 協(xié)議 (rdt) 的復雜性 運輸層28Principles of Reliable data transferr在應用層、運輸層、數(shù)據(jù)鏈路層非常重要m是網(wǎng)絡主題中的最重要的10個之一!r不可靠信道的特點決定了可靠數(shù)據(jù)傳輸 協(xié)議 (rdt) 的復雜性 運輸層29可靠數(shù)據(jù)傳輸: 基本概念發(fā)送方接收方rdt_send(): called from above, (e.g., by app.). Passed data to deliver

16、 to receiver upper layerudt_send(): called by rdt,to transfer packet over unreliable channel to receiverrdt_rcv(): called when packet arrives on rcv-side of channeldeliver_data(): called by rdt to deliver data to upper 運輸層30可靠數(shù)據(jù)傳輸: 基本概念我們將:r逐步加強發(fā)送方，接收方的可靠數(shù)據(jù)傳輸協(xié)議 (rdt) 側(cè)m僅考慮單向數(shù)據(jù)傳輸m但控制信息是雙流動的r使用有限狀態(tài)機 (

17、FSM)來定義發(fā)送方和接收方狀態(tài)1狀態(tài)2引起狀態(tài)變遷的事件狀態(tài)變遷所采取的行動狀態(tài): 當位于這個“狀態(tài)時”，下個狀態(tài)惟一地由下個事件決定事件動作 運輸層31第3章 要點r3.1 運輸層服務r3.2 復用與分解r3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控制的原則r3.7 TCP擁塞控制m機制mTCP吞吐量mTCP公平性m時延模型3.4 可靠數(shù)據(jù)傳輸服務模型 運輸層32可靠數(shù)據(jù)傳輸？無損壞、無丟失、有序P136 運輸層333.4.1 Rdt1.0:

18、 經(jīng)可靠信道的可靠傳輸r底層信道非?？煽縨無比特差錯m無分組丟失r單獨的發(fā)送方、接收方的FSM(P138):m發(fā)送方將數(shù)據(jù)發(fā)向底層信道m(xù)接收方從底層信道讀取數(shù)據(jù)Wait for call from abovepacket = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)Wait for call from belowrdt_rcv(packet)發(fā)送方接收方 運輸層3 Rdt1.0: 經(jīng)可靠信道的可靠傳輸r由于底層信道完全可靠，傳輸層中接收方不需要提供任何反

19、饋信息給發(fā)送方，因為不會發(fā)生任何差錯！而且，在rdt1.0中，假定接收方接收數(shù)據(jù)的速率和發(fā)送方發(fā)送數(shù)據(jù)的速率一樣快。因此，接收方?jīng)]有必要請求發(fā)送方放慢發(fā)送速度。Wait for call from abovepacket = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)Wait for call from belowrdt_rcv(packet)發(fā)送方接收方 運輸層3 Rdt2.0: 具有比特差錯的信道r底層信道可能翻轉(zhuǎn)分級中的某些位m校驗和可以檢測位錯誤r

20、the question: 如何從錯誤中恢復（語音通話）:m肯定確認acknowledgements (ACKs): receiver explicitly tells sender that pkt received OKm否定確認negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errorsmAQR自動重傳請求協(xié)議：發(fā)送方在收到NAK時重傳分組。r在 rdt2.0中新的機制中新的機制 (beyond rdt1.0):merror detection差錯檢測m接收方反饋: contr

21、ol msgs (ACK,NAK) 從接收方-發(fā)送方m重傳 運輸層3 rdt2.0: FSM規(guī)格參數(shù) 等待來自上面的調(diào)用sndpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_r

22、cv(rcvpkt) & corrupt(rcvpkt) 等待ACK 或NAK 等待來自下面的調(diào)用發(fā)送方接收方rdt_send(data)L發(fā)送方發(fā)送一個分組，然后等待接收方響應停止等待 運輸層37rdt2.0: 無差錯時的操作 等待來自上面的調(diào)用sndpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(

23、sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt) 等待 ACK 或NAK 等待來自下面的調(diào)用rdt_send(data)L發(fā)送方發(fā)送一個分組，然后等待接收方響應停止等待 運輸層38rdt2.0: 有差錯時的情況 等待來自上面的調(diào)用sndpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorr

24、upt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)等待ACK 或NAK 等待來自下面的調(diào)用rdt_send(data)L發(fā)送方發(fā)送一個分組，然后等待接收方響應停止等待 運輸層3 rdt2.0有重大的缺陷!如果ACK/NAK受損，將會出現(xiàn)何種情況？r發(fā)送方無法知道接收方是否正確接收了上一次發(fā)送的分組數(shù)據(jù)！應該怎樣糾正ACK或NAK分組中的差錯？處理受損方法？處理受

25、損方法？r口述消息的問話。接收方的ok，發(fā)送方不確定，問你說什么？然而你說什么產(chǎn)生差錯，接收方無法判斷下一步動作。r增加校驗和比特。r重傳當前數(shù)據(jù)分組。重傳可能導致冗余，接收方不知道這次的分組是重傳還是新數(shù)據(jù)，因為接收方不知道發(fā)送方有沒有收到自己的ACK 運輸層40 rdt2.0有重大的缺陷!如果ACK/NAK受損，將會出現(xiàn)何種情況？r發(fā)送方不知道在接收方發(fā)生 了什么情況！r不能只是重傳：重傳可能導致冗余處理冗余: r發(fā)送方對每個分組增加序列號r如果ACK/NAK受損，發(fā)送方重傳當前的分組r接收方丟棄(不再向上交付)冗余分組 運輸層41rdt2.1: 發(fā)送方, 處理受損的ACK/

26、NAK等待來自上層的調(diào)用0sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)等待 ACK 或 NAK 0udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) udt_send(sndpkt)rdt_

27、rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) 等待來自上層的調(diào)用1等待 ACK 或NAK 1LL 運輸層42rdt2.1: 接收方,處理受損的ACK/NAK等待來自下層的調(diào)用0sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq0(rcvpkt)rdt_rcv(rcvpkt) & notcorrupt(rcv

28、pkt) & has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)等待來自下層的調(diào)用1rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq0(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt =

29、 make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq1(rcvpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt) 運輸層43rdt2.1: 討論發(fā)送方:r序號seq # 加入分組中r兩個序號seq. #s (0,1) 將夠用r必須檢查收到的ACK/NAK是否受損 r狀態(tài)增

30、加一倍m狀態(tài)必須“記住”是否“當前的”分組具有0或1序號接收方:r必須檢查接收到的分組是否是冗余的m狀態(tài)指示0或1是否是所期待的分組序號seq #r注意: 接收方不能知道是否它的最后的ACK/NAK在發(fā)送方已經(jīng)接收OK 運輸層44如果接收方收到無序信號時發(fā)送NAK？習題6，P191 運輸層45rdt2.2: 一種無NAK的協(xié)議r與rdt2.1一樣的功能，僅使用ACKr代替NAK,接收方對最后正確接收的分組發(fā)送ACKm接收方必須明確地指明被確認分組的序號r在發(fā)送方冗余的ACK導致如同NAK相同的動作：重傳當前分組解決無序分組的問題，使用應答序號 運輸層46rdt2.2: 發(fā)送方, 接收方片段等待

31、來自上層的調(diào)用0sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) | isACK(rcvpkt,1) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0) 等待ACK0發(fā)送方FSM片段等待來自下層的調(diào)用0rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt) extract(rcvpkt,data)

32、deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt) | has_seq1(rcvpkt)udt_send(sndpkt)接收方FSM片段Lrdt2.2 發(fā)送方 運輸層47rdt2.2 接收方 運輸層48 運輸層4 rdt3.0: 具有差錯和丟包的信道新假設: 下面的信道也能丟失分組(數(shù)據(jù)或ACK)m檢查和、序號、重傳將是有幫助的，但不充分發(fā)送方發(fā)送數(shù)據(jù)后，數(shù)據(jù)丟失或者接收方對該分組的ACK發(fā)生了丟失，該怎么辦？方法: 發(fā)送方等待AC

33、K一段“合理的”時間r如在這段時間沒有收到ACK則重傳r如果分組(或ACK)只是延遲(沒有丟失)：m重傳將是冗余的，但序號的使用已經(jīng)處理了該情況m接收方必須定義被確認的分組序號r需要倒計時定時器 運輸層50rdt3.0發(fā)送方sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timerrdt_send(data)等待 ACK0rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,1) )等待來自上面的調(diào)用1sndpkt = make_pkt(1, data, checksum)udt_

34、send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0) rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,0) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,1) stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcv

35、pkt) 等待來自上面的調(diào)用0等待 ACK1Lrdt_rcv(rcvpkt)LLL錯誤失序超時重發(fā) 運輸層51rdt3.0 運行情況無丟包時的運行 分組丟失發(fā)送方發(fā)送方接收方接收方 運輸層52rdt3.0運行情況ACK丟失 過早超時 發(fā)送方發(fā)送方接收方接收方 運輸層53rdt3.0的性能rrdt3.0能夠工作，但性能不太好r例子: 假設東海岸與西海岸通信： 經(jīng)1 Gbps鏈路, 15 ms端到端傳播時延, 1KB分組:Ttransmit=8kb/pkt10*9 b/sec= 8 usmU sender: 利用率 發(fā)送方用于發(fā)送時間的比率m每30 msec 1KB 分組 - 經(jīng)1 Gbps 鏈路

36、有267kb/sec 吞吐量m網(wǎng)絡協(xié)議限制了物理資源的使用! U sender = .008 30.008 = 0.00027 L / R RTT + L / R = L (packet length in bits)R (transmission rate, bps)= 運輸層54rdt3.0: 停等協(xié)議的運行傳輸分組的第一個比特, t = 0發(fā)送方接收方RTT 傳輸分組的最后一個比特, t = L / R分組第一個比特到達傳輸最后一個比特到達,發(fā)送ACKACK 到達，發(fā)送下一個分組, t = RTT + L / R U sender = .008 30.008 = 0.00027 L /

37、R RTT + L / R = 運輸層553.4.2 流水線協(xié)議: 增加利用率傳輸?shù)谝粋€分組比特傳輸?shù)谝粋€分組比特, t = 0發(fā)送者接收者RTT 傳輸最后一個比特傳輸最后一個比特, t = L / R第一個分組比特到達第一個分組比特到達分組最后一個比特到達分組最后一個比特到達,發(fā)送發(fā)送 ACKACK 到達到達, 發(fā)送下一個分組發(fā)送下一個分組, t = RTT + L / R第二個分組最后比特到達第二個分組最后比特到達,發(fā)送發(fā)送ACK第三個分組最后比特到達第三個分組最后比特到達,發(fā)送發(fā)送ACK U sender = .024 30.008 = 0.0008 microseconds 3 * L

38、 / R RTT + L / R = 利用率增加利用率增加3倍倍! 運輸層563.4.2 流水線協(xié)議流水線: 發(fā)送方允許發(fā)送多個、“傳輸中的”,還沒有應答的報文段m序號的范圍必須增加m發(fā)送方和/或接收方設有緩沖r流水線協(xié)議的兩種形式: 回退回退N幀法（幀法（go-Back-N）, 選擇性重傳（選擇性重傳（S-R）, 運輸層573.4.3 Go-Back-N發(fā)送方發(fā)送方（基序號（基序號&下一個序號下一個序號P147）r在分組首部需要K比特序號，2k=Nr“窗口”最大為N, 允許N個連續(xù)的沒有應答分組Base(基序號)：最早的未確認分組的序號Nextseqnum(下一個序號):下一個待發(fā)送分組的序

39、號3.4.3 Go-Back-N發(fā)送方 運輸層58r發(fā)送前，檢查窗口是否已滿。r累積確認ACK(n): 確認所有（包括序號n）的分組 - “累計ACK”r對每個傳輸中的分組的用同一個計時器，是最早的已發(fā)送但未被確認的分組所使用的定時器。ltimeout(n):若超時，重傳窗口中已發(fā)送但未被確認的分組 運輸層59GBN: 發(fā)送方擴展的 FSM等待等待start_timerudt_send(sndpktbase)udt_send(sndpktbase+1)udt_send(sndpktnextseqnum-1)timeoutrdt_send(data) if (nextseqnum base+N)

40、 sndpktnextseqnum = make_pkt(nextseqnum,data,chksum) udt_send(sndpktnextseqnum) if (base = nextseqnum) start_timer nextseqnum+ else refuse_data(data)base = getacknum(rcvpkt)+1If (base = nextseqnum) stop_timer else start_timerrdt_rcv(rcvpkt) & notcorrupt(rcvpkt) base=1nextseqnum=1rdt_rcv(rcvpkt) & co

41、rrupt(rcvpkt) L三個事件：1、上層的調(diào)用2、收到ACK3、超時事件GBN: 發(fā)送方擴展的 FSM 運輸層60r發(fā)送條件：base+ nextseqnum 沒有接收緩沖區(qū)!m重新確認具有按序的分組rdt_rcv(rcvpkt) & notcurrupt(rcvpkt) & hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum+udt_send(sn

42、dpkt)defaultexpectedseqnum=1Sndpkt=make_pkt(expectedseqnum ,ACK,chksum)L等等待待 運輸層62GBN 操作發(fā)送方接收方 運輸層633.4.4選擇性重傳（Selective Repeat）GBN改善了信道效率，但仍然有不必要重傳問題由于單個分組差錯可能引起GBN的大量重傳-只重傳丟失或錯誤的單個分組r接收方分別確認所有正確接收的報文段m需要緩存分組, 以便最后按序交付給上層r發(fā)送方只需要重傳沒有收到ACK的分組m發(fā)送方定時器對每個沒有確認的分組計時r發(fā)送窗口mN個連續(xù)的序號m也需要限制已發(fā)送但尚未應答分組的序號 運輸層643.

43、4.4選擇性重傳上層傳來數(shù)據(jù)上層傳來數(shù)據(jù) :r如果數(shù)據(jù)序號在發(fā)送窗口內(nèi)，則打包發(fā)送，否則將數(shù)據(jù)緩存或返還給上層timeout(n):r每個分組擁有自己的定時器，重傳分組k時， 重啟其計時器ACK(n) ：在在sendbase,sendbase+N:r標記分組 n 已經(jīng)收到r如果n 是最小未收到應答的分組，向前滑動窗口base指針到下一個未確認序號發(fā)送方分組分組n在在 rcvbase, rcvbase+N-1r發(fā)送 ACK(n)r失序: 緩存r按序: 交付 (也交付所有緩存的按序分組),向前滑動窗口到下一個未收到報文段的序號分組分組n在在rcvbase-N,rcvbase-1r即使已正確接收過該

44、分組，但還是需要再次發(fā)送ACK(n)其他其他: r忽略 接收方 運輸層65選擇性重傳: 發(fā)送方, 接收方窗口a. 發(fā)送方看到的序號b. 接收方看到的序號已經(jīng)確認可用，還未發(fā)送發(fā)送，還未確認不可用可接受（窗口內(nèi)） 失序(已緩存)但未被確認 可接受（窗口內(nèi)）期待，還未收到 不可用 窗口長度N窗口長度N 運輸層66選擇重傳的操作 運輸層67選擇重傳: 困難的問題例子:r序號: 0, 1, 2, 3r窗口長度 = 3r接收方：在(a)和(b)兩種情況下接收方?jīng)]有發(fā)現(xiàn)差別!r在 (a)中不正確地將冗余分組當作新分組，但在(b)中，對于接收方而言，收到分組和（a）中是不同的，是一個新的分組問題: 序號長度

45、與窗口長度有什么關(guān)系?回答：窗口長度小于等于序號空間的一半 運輸層68Window SizerIf the sequence number is m bits,r Go-back-NmSending window=2m-1r Selective repeatmReceiving window=Sending window=2m-1 運輸層69可靠數(shù)據(jù)傳輸機制及用途總結(jié)機制用途和說明檢驗和用于檢測在一個傳輸分組中的比特錯誤。定時器用于檢測超時/重傳一個分組，可能因為該分組（或其ACK）在信道中丟失了。由于當一個分組被時延但未丟失（過早超時），或當一個分組已被接收方收到但從接收方到發(fā)送方的ACK丟

46、失時，可能產(chǎn)生超時事件，所以接收方可能會收到一個分組的多個冗余拷貝。序號用于為發(fā)送的數(shù)據(jù)分組進行按序編號。所接收分組的序號間的空隙可使接收方檢測出丟失的分組。具有相同序號的分組可使接收方檢測出一個分組的冗余拷貝。確認接收方用于告訴發(fā)送方一個分組或一組分組已被正確地接收到了。確認報文通常攜帶著被確認的分組或多個分組的序號。確認可以是逐個的或累積的，這取決于協(xié)議。否定確認接收方用于告訴發(fā)送方某個分組未被正確地接收。否定確認報文通常攜帶著未被正確接收的分組的序號。窗口、流水線發(fā)送方也許被限制僅發(fā)送那些序號落在一個指定范圍內(nèi)的分組。通過允許一次發(fā)送多個分組但未被確認，發(fā)送方的利用率可在停等操作模式的基

47、礎上得到增加。我們很快將會看到，窗口長度可根據(jù)接收方接收和緩存報文的能力或網(wǎng)絡中的擁塞程度，或兩者情況來進行設置。 運輸層70第3章 要點r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控制的原則r3.7 TCP擁塞控制m機制mTCP吞吐量mTCP公平性m時延模型r3.1 運輸層服務r3.2 復用與分解r3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議 運輸層713.5 TCP概述 RFCs: 793, 1122, 1323, 2018, 2581r全雙工數(shù)據(jù)全雙工數(shù)據(jù):m同一連接上的雙向數(shù)據(jù)流mM

48、SS: 最大報文段長度mMTU:最大傳輸單元r面向連接面向連接: m在進行數(shù)據(jù)交換前，初始化發(fā)送方與接收方狀態(tài)，進行握手(交換控制信息),r點到點點到點:m一個發(fā)送方, 一個接收方m連接狀態(tài)與端系統(tǒng)有關(guān)，不為路由器所知 r三次握手三次握手r發(fā)送和接收緩存發(fā)送和接收緩存r最大傳輸單元：最大傳輸單元：MTUr最大報文段長：最大報文段長：MSS 運輸層723.5 TCP概述 RFCs: 793, 1122, 1323, 2018, 2581r流量控制流量控制:m發(fā)送方不能淹沒接收方r擁塞控制擁塞控制:m抑止發(fā)送方速率來防止過分占用網(wǎng)絡資源r可靠、有序的字節(jié)流可靠、有序的字節(jié)流:m沒有 “報文邊界”r

49、流水線流水線:mTCP擁塞和流量控制設置滑動窗口協(xié)議socketdoorTCPsend bufferTCPreceive buffersocketdoorsegmentapplicationwrites dataapplicationreads data 運輸層733.5.2TCP 報文段結(jié)構(gòu)源端口 #目的端口 #32 bits應用層數(shù)據(jù) (變長)序號確認號接收窗口緊急數(shù)據(jù)指針檢查和FSRPAU首部長度未用選項 (變長)URG: 緊急數(shù)據(jù) (一般不用)ACK: ACK 序號有效PSH: 立即提交數(shù)據(jù)(一般不用)RST, SYN, FIN:連接建立(建立和拆連)接收方允許的字節(jié)數(shù)對數(shù)據(jù)字節(jié)計數(shù)(

50、并非對報文段計數(shù)!)因特網(wǎng)檢查和(同 UDP一樣) 運輸層74TCP數(shù)據(jù)段頭及說明數(shù)據(jù)開始可選項（0個或更多個32位字）緊急指針校驗和窗口大小碼位保留段頭長度確認號序號目的端口源端口1 6 3 1840TCP頭頭 端口：每個端口對應一個應用程序端口：每個端口對應一個應用程序 序號：發(fā)送的字節(jié)序號序號：發(fā)送的字節(jié)序號 確認號：接收到的字節(jié)序號確認號：接收到的字節(jié)序號 段頭長度：段頭中包含多少個段頭長度：段頭中包含多少個32位字位字 運輸層75TCP數(shù)據(jù)段頭及說明（續(xù)）r保留：以備擴展之用 r碼位：URG： 緊急指針有效ACK： 確認號有效PSH：請求接收方，數(shù)據(jù)一到，立即送往應用程序RST：復位

51、由于主機崩潰或其他原因而出現(xiàn)的錯誤的連接SYN： 用于建立連接FIN：用于斷開連接r窗口：接收方窗口大小URGACKPSHRSTSYNFIN 運輸層76TCP數(shù)據(jù)段頭及說明（續(xù)）r校驗和：包括報頭、數(shù)據(jù)和偽段頭r緊急指針：當前序號到緊急位置的偏移量r選項字段：用于提供一種增加額外設置的方法，如連接建立時，雙方說明最大的負載能力r數(shù)據(jù)：真正要傳輸?shù)臄?shù)據(jù)0481 6 3 1源IP地址目的IP地址00000000協(xié)議 = 6TCP數(shù)據(jù)段長度 包括在包括在TCP校驗和中的偽頭校驗和中的偽頭 運輸層77常用的選項字段r最大數(shù)據(jù)段長度MSS目的站可接收的最大的數(shù)據(jù)段長度，這個值在0到65535之間，默認值

52、是536字節(jié)r窗口擴大因子n（n 更大的安全余量r首先估算EstimatedRTT與SampleRTT之間差值有多大 : TimeoutInterval = EstimatedRTT + 4*DevRTTDevRTT = (1- )*DevRTT + *|SampleRTT-EstimatedRTT|(典型地, = 0.25) 然后估算超時值然后估算超時值P161: 運輸層85第3章 要點r3.5 面向連接的傳輸: TCPm報文段結(jié)構(gòu)m可靠數(shù)據(jù)傳輸m流量控制m連接管理r3.6 擁塞控制的原則r3.7 TCP擁塞控制m機制mTCP吞吐量mTCP公平性m時延模型r3.1 運輸層服務r3.2 復用與

53、分解r3.3 無連接傳輸: UDPr3.4 可靠數(shù)據(jù)傳輸?shù)脑瓌tmrdt1mrdt2mrdt3m流水線協(xié)議 運輸層863.5.4 TCP 可靠數(shù)據(jù)傳輸rTCP在IP不可靠服務的基礎上創(chuàng)建可靠數(shù)據(jù)傳輸服務r流水線發(fā)送報文段r累計確認rTCP使用單個重傳計時器r重傳被下列事件觸發(fā):m超時事件m重復ACKr先考慮簡化的TCP發(fā)送方:m 忽略重復ACKm 忽略流量控制，擁塞控制 運輸層87TCP 發(fā)送方事件1.從應用層接收數(shù)據(jù):r根據(jù)序號創(chuàng)建報文段r序號是報文段中第一個數(shù)據(jù)字節(jié)的數(shù)據(jù)流編號r如果未啟動，啟動計時器 (考慮計時器用于最早的沒有確認的報文段)r超時間隔: TimeOutInterval= E

54、stimatedRTT + 4*DevRTT2.超時:r重傳導致超時的報文段r重新啟動計時器3.收到確認：r如果確認了先前未被確認的報文段 r更新被確認的報文段序號r如果還有未被確認的報文段，重新啟動計時器 運輸層88TCP 發(fā)送方(簡化的) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if

55、 (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 y start timer event: ACK received, with ACK field value of y if (y SendBase) /* 累計確認到Y(jié) */ SendBase = y if (t

56、here are currently not-yet-acknowledged segments) start timer /* end of loop forever */ 注釋: SendBase-1: 上次累計的已確認字節(jié) 運輸層89TCP: 重傳的情況主機 ASeq=100, 20 bytes dataACK=100時間過早超時的情況主機 BSeq=92, 8 bytes dataACK=120Seq=92, 8 bytes dataSeq=92 超時ACK=120主機 ASeq=92, 8 bytes dataACK=100loss超時丟失確認的情況主機 BXSeq=92, 8 by

57、tes dataACK=100時間Seq=92 超時SendBase= 100SendBase= 120SendBase= 120Sendbase= 100 運輸層90TCP 重傳情況(續(xù))主機 ASeq=92, 8 bytes dataACK=100丟包超時累計確認情況主機 BXSeq=100, 20 bytes dataACK=120時間SendBase= 120累積確認避免了第一個報文段的重傳加倍超時間隔 運輸層91r在收到應用層的數(shù)據(jù)傳輸請求和ack后，超時間隔為: TimeOutInterval= EstimatedRTT + 4*DevRTTr若是重傳，重新啟動計時器：TimeOu

58、tInterval=2* TimeOutIntervalm提供了擁塞控制P164快速重傳 運輸層92r由于重傳成倍時間的遞增，會增加端端時延，但發(fā)送方能在超時事件發(fā)生之前通過冗余ACK較好的檢測丟包情況r冗余ACK：發(fā)送方已收到該ACK，即重復收到對發(fā)送的某個報文的確認r接收方：什么情況下發(fā)送冗余ACK? 運輸層93產(chǎn)生TCP ACK的建議 RFC 1122, RFC 2581接收方事件接收方事件所期望序號的報文段按序到達。所有在期望序號及以前的數(shù)據(jù)都已經(jīng)被確認 有期望序號的報文段按序到達。另一個按序報文段等待發(fā)送ACK 比期望序號大的失序報文段到達，檢測出數(shù)據(jù)流中的間隔。 部分或者完全填充已

59、接收到數(shù)據(jù)間隔的報文段到達TCP 接收方行為接收方行為延遲的ACK。對另一個按序報文段的到達最多等待500 ms。如果下一個按序報文段在這個時間間隔內(nèi)沒有到達，則發(fā)送一個ACK 立即發(fā)送單個累積ACK，以確認兩個按序報文段 立即發(fā)送冗余ACK，指明下一個期待字節(jié)的序號（也就是間隔的低端字節(jié)序號） 倘若該報文段起始于間隔的低端，則立即發(fā)送ACK 運輸層94快速重傳r超時間隔常常相對較長:m重傳丟失報文段以前有長時延r通過冗余ACK，檢測丟失的報文段m發(fā)送方經(jīng)常一個接一個的發(fā)送報文段m如果報文段丟失，將會收到很多重復ACKr如果對相同數(shù)據(jù)，發(fā)送方收到3個ACK, 假定被確認的報文段以后的報文段丟失

60、了:m快速重傳: 在定時器超時之前重傳 運輸層95Fast retransmit algorithm:a duplicate ACK for already ACKed segment event: ACK received, with ACK field value of y if (y SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else /*a duplicate ACK for already ACKed segment*/ increment cou