數(shù)據(jù)通信與計算機網(wǎng)絡(luò)清華n6傳輸層

1、第23講 傳輸層之二傳輸控制與UDP1. 流量控制與緩沖 TL的流控涉及TS用戶、傳輸實體和網(wǎng)絡(luò)服務(wù)相互作用得到B的允許(對等流控)得到其傳輸實體的允許(接口流控) A必須等待，直到： TL流控的復(fù)雜性一. 傳輸控制傳輸實體a傳輸實體b接口接口傳輸層網(wǎng)絡(luò)層傳輸用戶A傳輸用戶B發(fā)送TS用戶接收TS用戶傳輸協(xié)議SendSegment Indication ACK sendACK sendConfirm Response ACK send傳輸實體間的傳輸延遲通常比實際傳輸時間長而且變化不定接口流控對等流控 基于可靠網(wǎng)絡(luò)服務(wù)的流控什么也不做溢出緩沖區(qū)的段都遭丟棄。后壓機制拒絕從網(wǎng)絡(luò)服務(wù)接受進(jìn)一步段。固

2、定滑動窗口協(xié)議數(shù)據(jù)單元采用順序編號窗口尺寸固定利用確認(rèn)滑動窗口在某個時刻，發(fā)送傳輸實體有一些已輸出的段尚未得到確認(rèn)。預(yù)留途徑在長延遲環(huán)境中會限制傳輸連接的吞吐量。接收者通過授予未擁有的空間信用卡而潛在地提高吞吐量如發(fā)送者快于接收者某些段將遭丟棄迫使重發(fā)信用卡模式經(jīng)過連接建立過程，發(fā)送和接收序號取得同步。每當(dāng)發(fā)送段前移發(fā)送窗口的尾部；每當(dāng)獲得信用卡前移發(fā)送窗口前沿；數(shù)據(jù)發(fā)送并已確認(rèn)數(shù)據(jù)發(fā)送但未確認(rèn)允許的數(shù)據(jù)傳輸未用和不可用的序號發(fā)送序號分為四部分：012345670123012345670123012345670123012345670123012345670123012345670123012

3、345670123012345670123012345670123傳輸實體A傳輸實體BSN0SN1SN2SN3SN4SN5SN6A可發(fā)7個段A滑動發(fā)送窗口B準(zhǔn)備接收7個段B確認(rèn)3個段，準(zhǔn)備再接收額外一個段ACK3, CDT=5A根據(jù)信用卡調(diào)整發(fā)送窗口A耗盡信用卡SN7ACK0, CDT=7初始序號最后收到的ACK最后發(fā)送的數(shù)據(jù)段窗口邊界發(fā)送的數(shù)據(jù)確認(rèn)的數(shù)據(jù)未確認(rèn)的數(shù)據(jù)可發(fā)送的數(shù)據(jù)初始序號最后收到的數(shù)據(jù)段最后發(fā)送的ACK窗口邊界收到的數(shù)據(jù)收到&確認(rèn)的數(shù)據(jù)未確認(rèn)的數(shù)據(jù)可接收的數(shù)據(jù)(a)發(fā)送序號空間(b)接收序號空間基于不可靠網(wǎng)絡(luò)服務(wù)的流控有效性傳輸實體發(fā)送形為(ACKN, CREDIT M)的控制

4、段ACK N ：確認(rèn)所有直到N的數(shù)據(jù)段；CREDIT M：允許傳輸從N1NM的段；為了增加或減少信用卡為X B可發(fā)出(ACK N,CREDIT X)為了確認(rèn)一個新段而不增加信用卡 B可發(fā)出(ACK N+1,CREDIT M-1)死鎖系統(tǒng)A系統(tǒng)BACKn, CDT=0臨時關(guān)閉連接ACKn, CDT=m授予A信用卡丟失等待B的授予等待A的傳輸采用窗口計時器為每個ACK/CREDIT段提供確認(rèn)死鎖2. 多路復(fù)用應(yīng)用多路復(fù)用FTPWeb TelnetTelnet 傳輸層復(fù)用概述Web FTPTelnetTelnet復(fù)用一般定義向上多路復(fù)用TLNL向下多路復(fù)用實現(xiàn)技術(shù)源、目標(biāo)端口的應(yīng)用如何設(shè)置端口號源

5、port = x目的port = 23源 port = 23目的port = xTelnet 如何區(qū)分選用相同端口號的客戶CTelnet ServerIP=A, SP=x, DP=23IP=A, SP=y, DP=23IP=B, SP=x, DP=23三元組：源IP地址、源端口號、目的端口號 A B3. 其他問題網(wǎng)絡(luò)崩潰采用放棄計時器采用RST段重置連接主機崩潰STPDU0TPDU1發(fā)送一文件停等協(xié)議崩潰恢復(fù) C客戶端的兩種狀態(tài)S0狀態(tài) 所有TPDU已確認(rèn)S1狀態(tài) 最后TPDU未確認(rèn)協(xié)議不能正確恢復(fù)的情況TPDUiACKi崩潰S0狀態(tài)應(yīng)用程序？應(yīng)用程序TPDUiACKi？S1狀態(tài)導(dǎo)致丟失導(dǎo)致重

6、復(fù)崩潰客戶機策略服務(wù)器策略總是重發(fā)從不重發(fā)當(dāng)S0時重發(fā)當(dāng)S1時重發(fā)AC(W)AWCC(AW)C(WA)WACWC(A)正確重復(fù)正確正確正確正確正確正確正確正確正確正確正確重復(fù)重復(fù)重復(fù)重復(fù)重復(fù)丟失丟失丟失丟失丟失丟失先確認(rèn)，后寫入先寫入，后確認(rèn)客戶與服務(wù)器采用方案的組合情況有序傳送按段編號 按字節(jié)量編號重傳策略段在傳輸過程中遭破壞段丟失，沒有到達(dá)目的地導(dǎo)致重傳的事件肯定確認(rèn)接收者必須確認(rèn)每個成功接收的段。重傳計時器固定長計時器無法響應(yīng)變化的網(wǎng)絡(luò)情況自適應(yīng)模式對等實體并不立即確認(rèn);發(fā)送者無從知曉收到的ACK是初始傳輸還是重傳段的確認(rèn);網(wǎng)絡(luò)情況瞬間變化;觀察到的平均延遲值是否可信賴？傳輸實體 A傳輸

7、實體 BSN1SN2SN0SN1SN3SN4SN5SN6SN7SN0ACK3ACK3ACK4ACK5ACK6ACK7ACK0超時，重發(fā)SN0超時，重發(fā)SN1SN0已廢SN0到達(dá)重復(fù)檢測接收端假設(shè)它的確認(rèn)已丟失必須對重復(fù)段確認(rèn)序號空間必須足夠大二. 案例學(xué)習(xí)：UDP協(xié)議網(wǎng)絡(luò)層能夠提供在主機之間傳送數(shù)據(jù)報的能力目的地址等同于一個主機，沒有對接收數(shù)據(jù)報的用戶或應(yīng)用程序進(jìn)行更細(xì)致的標(biāo)識。傳輸層能夠識別主機上的多個目的地址允許多個應(yīng)用程序在同一臺主機上工作并獨立地進(jìn)行數(shù)據(jù)報的轉(zhuǎn)發(fā)。通信的最終目的地不是進(jìn)程通信的最終目的地是協(xié)議端口進(jìn)程的生成和消失都是動態(tài)的接收進(jìn)程的改換對發(fā)送方透明由接收方的功能來識別目

8、的地每臺機器是一些抽象的訪問目的協(xié)議端口(protocol port)OS提供對端口的同步接入能力在接入端口的時候停止計算的運行IGMPIPICMPTCPUDPOSPFRIPBGPDNSTFTPBOOTPSNMPrloginFTPtelnetSMTP各端口都有緩沖區(qū)協(xié)議軟件模塊將到達(dá)某個端口的分組排成隊列發(fā)送方要知道目的機的IP地址和對應(yīng)的協(xié)議端口號1. 客戶-服務(wù)器模型S 重復(fù)型服務(wù)等待一個客戶請求的到來處理客戶請求發(fā)送響應(yīng)給客戶此時服務(wù)器不能為其他客戶提供服務(wù)并發(fā)型服務(wù)等待一個客戶請求的到來啟動一個新的服務(wù)器處理這個客戶請求新服務(wù)器對客戶的全部請求進(jìn)行處理。處理結(jié)束后終止該服務(wù)器。TCP服

9、務(wù)器是并發(fā)的；UDP服務(wù)器是重復(fù)的；每個客戶都有自己對應(yīng)的服務(wù)器2. UDP概述UDP提供了不可靠的無連接傳輸服務(wù)。它使用IP攜帶報文，但增加了對給定主機上多個目標(biāo)進(jìn)行區(qū)別的能力。 特點 沒有確認(rèn)機制 不對報文排序 沒有超時機制 沒有反饋機制控制流量報文丟棄、重復(fù)和亂序使用UDP的應(yīng)用程序要承擔(dān)可靠性方面的全部工作3. UDP報文格式UDP源端口UDP目的端口UDP報文長度UDP校驗和數(shù)據(jù) UDP源端口 UDP目的端口4B4B可選(0)用于分用操作 UDP長度包含UDP頭和數(shù)據(jù)的字節(jié)數(shù) UDP校驗和可選(0)減少在可靠性高的LAN上的實現(xiàn)開銷4. UDP的偽頭與校驗和UDP的校驗和覆蓋了UDP

10、頭和UDP數(shù)據(jù)，但超出了UDP數(shù)據(jù)報本身的范圍。UDP的校驗和提供了唯一的對數(shù)據(jù)是否原封不動傳送到目的的監(jiān)督手段。IP協(xié)議并不對IP報文中的數(shù)據(jù)部分計算校驗和 UDP的校驗和計算方法按16比特先計算二進(jìn)制反碼再進(jìn)行異或操作得到校驗和UDP數(shù)據(jù)報的長度可以為奇數(shù)字節(jié)當(dāng)校驗和為0時表示發(fā)送端沒有計算校驗和當(dāng)計算出的校驗和為0則用全“1”表示如果接收端計算出校驗和有錯則丟棄數(shù)據(jù)報接收端計算的校驗和應(yīng)為全0 UDP的偽頭UDP源端口UDP目的端口UDP報文長度UDP校驗和數(shù)據(jù)0UDP報文長度32位目的IP地址32位源IP地址協(xié)議號(17)偽頭填充(0)不被發(fā)送偽頭的設(shè)置允許UDP兩次檢查數(shù)據(jù)是否已經(jīng)正

11、確到達(dá)目的地長度字段在校驗和計算中出現(xiàn)了兩次 UDP報文長度不包括偽頭 層次的劃分接收端在驗證正確性時必須把偽頭字段的信息從IP報文的頭中抽取出來，以偽頭的格式進(jìn)行裝配，然后再重新計算校驗和。是否違反分層原則？ UDP層可直接得知目的IP地址而不必從IP層找發(fā)送用戶必須知道目的IP地址。在發(fā)送數(shù)據(jù)時把目的地址告訴UDP。 如果不和IP層交互UDP層是無法得知源IP地址的源IP地址是根據(jù)IP層對路由的選擇而定。源IP地址標(biāo)識了數(shù)據(jù)報傳輸時所經(jīng)過的網(wǎng)絡(luò)接口。5. UDP的封裝UDP數(shù)據(jù)區(qū)UDP頭IP數(shù)據(jù)區(qū)IP頭幀數(shù)據(jù)區(qū)幀頭 IP層只負(fù)責(zé)在互聯(lián)網(wǎng)絡(luò)上的一對主機之間進(jìn)行數(shù)據(jù)傳輸 UDP層只負(fù)責(zé)對一臺主

12、機上復(fù)用的多個端口進(jìn)行區(qū)分IP層的頭指明了源和目的主機地址UDP層的頭指明了主機上的源和目的端口IP數(shù)據(jù)報與分組 IP數(shù)據(jù)報IP層端到端的傳輸單元(在分段之前與重組之后)分組IP層與鏈路層之間傳送的數(shù)據(jù)單元IP頭UDP數(shù)據(jù)區(qū)(1473 字節(jié))UDP頭IP頭1472 字節(jié)UDP頭IP頭IP數(shù)據(jù)報20字節(jié)8字節(jié)1字節(jié)IP分組IP分組傳輸層頭只出現(xiàn)在第一片數(shù)據(jù)中;分組可以是一個完整的數(shù)據(jù)報或數(shù)據(jù)報的一個分片; 最大UDP數(shù)據(jù)報長度 IP數(shù)據(jù)報的最大長度65535個字節(jié)20個字節(jié)的IP頭8個字節(jié)的UDP頭UDP數(shù)據(jù)報中用戶數(shù)據(jù)的最大長度為65507個字節(jié) 制約UDP數(shù)據(jù)報長度的因素應(yīng)用程序可能受程序接

13、口的限制大部分系統(tǒng)省缺提供可讀寫8192個字節(jié)的UDP數(shù)據(jù)報8192是NFS讀寫用戶數(shù)據(jù)報的省缺值受TCP/IP內(nèi)核實現(xiàn)的限制BSD/386 32786個字節(jié)SunOS 4.1.3 32767個字節(jié)Solaris 2.2 65535個字節(jié)用戶數(shù)據(jù)長32758數(shù)據(jù)報截斷IP能夠發(fā)送/接收特定長度的數(shù)據(jù)報并不意味著接收應(yīng)用程序可讀取該長度的數(shù)據(jù)UDP編程接口允許應(yīng)用程序指定每次返回的字節(jié)數(shù)接收到的數(shù)據(jù)報長度大于應(yīng)用程序所能處理的長度時怎么辦？Berkeley版socket API取決于編程接口和實現(xiàn)對數(shù)據(jù)報進(jìn)行截斷并丟棄任何多余的數(shù)據(jù)SVR4的socket API是否通知應(yīng)用程序則取決于版本不截斷

14、數(shù)據(jù)，超出部分的數(shù)據(jù)在后面的讀取中返回TLI API不丟棄數(shù)據(jù)但返回一個標(biāo)志6. UDP的復(fù)用、分用和端口UDP接收多個應(yīng)用程序送來的數(shù)據(jù)報，把它們送給IP層去傳輸；同時接收IP層送來的UDP數(shù)據(jù)報，把它們送給對應(yīng)的應(yīng)用程序。UDP基于端口的分用端口1端口2端口3IP層UDP與應(yīng)用程序之間的復(fù)用和分用都要通過端口機制來實現(xiàn)每個應(yīng)用程序在發(fā)送數(shù)據(jù)報之前必須與OS協(xié)商以取得協(xié)議端口和相應(yīng)的端口號隊列實現(xiàn)方法發(fā)送數(shù)據(jù)報時創(chuàng)建一個內(nèi)部隊列接收數(shù)據(jù)報檢查當(dāng)前端口發(fā)送ICMP端口不可達(dá)放入隊列等待應(yīng)用程序訪問7. 保留的UDP端口端口號的指派方式集中式管理動態(tài)綁定“統(tǒng)一指派”“知名端口”一個集中管理機構(gòu)負(fù)

15、責(zé)對端口的指派和發(fā)布。所有軟件在設(shè)計時都要遵守這些指派的規(guī)定。當(dāng)一個應(yīng)用程序需要使用端口時，網(wǎng)絡(luò)軟件便指派一個端口。TCP/IP采納了一種混合方式對端口地址進(jìn)行管理：對某些端口進(jìn)行指派；但對本地站點和應(yīng)用程序留下了很大的端口取值范圍。十進(jìn)制數(shù) Internet關(guān)鍵字 UNIX關(guān)鍵字 描述0753676869111161162-ECHODOMAINBOOTPSBOOTPCTFTPSUNRPC-echonameserverbootpsbootpctftpsunrpcsnmpsnmp-trap保留回應(yīng)域名服務(wù)器引導(dǎo)協(xié)議服務(wù)器引導(dǎo)協(xié)議客戶機簡單文件傳送SUN遠(yuǎn)程過程調(diào)用SNMP網(wǎng)絡(luò)監(jiān)控程序SNMP陷阱

16、 常用的UDP端口8. UDP服務(wù)器的設(shè)計服務(wù)器啟動后處于休眠狀態(tài)，等待客戶請求的到來。當(dāng)客戶數(shù)據(jù)報到達(dá)時，服務(wù)器蘇醒過來處理數(shù)據(jù)報中可能的客戶請求消息。 客戶IP地址及端口號當(dāng)一個應(yīng)用程序接收到UDP數(shù)據(jù)報時，OS必須告訴它是誰發(fā)送了這份消息。允許一個UDP服務(wù)器對多個客戶進(jìn)行處理 目的IP地址某些應(yīng)用程序要求知道數(shù)據(jù)報發(fā)給誰。OS從接收到的UDP數(shù)據(jù)報中將目的IP地址交給應(yīng)用程序?！癐P_RECVDSTADDR”選項BSD/386,4.4BSD支持SVR4,SunOS4.x,Solaris2.x不支持 UDP輸入隊列單個服務(wù)器進(jìn)程對單個UDP端口（服務(wù)器上的知名端口）上的所有客戶請求進(jìn)行處

17、理。每個UDP端口有一個有限大小的輸入隊列來自不同客戶的請求將由UDP自動排隊排隊溢出可造成內(nèi)核中UDP模塊丟失數(shù)據(jù)報接收到的UDP數(shù)據(jù)報以接收順序交給應(yīng)用程序應(yīng)用程序并不知道其輸入隊列何時溢出沒有反饋機制通知客戶其數(shù)據(jù)報被丟棄UDP輸出隊列是FIFOS 539限制本地IP地址使用通配符UDP服務(wù)器在創(chuàng)建UDP端口時可指定或不指定本地IP地址。本地接口接收所有目的地為本地的數(shù)據(jù)報.指定一個本地IP地址如果指定端口地址為SLIP，則所有從以太網(wǎng)發(fā)給服務(wù)器的數(shù)據(jù)報都將返回一個ICMP端口不可達(dá)報文。服務(wù)器本地地址的綁定導(dǎo)致拒絕接收UDP數(shù)據(jù)報如果為端口指定了特定的IP地址，那么在匹配目的地址時始終