傳輸層向上層提供哪些服務

傳輸層向上層提供哪些服務第1頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫TransportLayer’staskistoprovidereliable,cost-effectivedatatransportfromthesourcemachinetothedestinationmachine,independentlyofthephysicalnetworkornetworkscurrentlyinuse.Chapter6.TheTransportLayer

第2頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫

MainTopics:1，傳輸層向上層提供哪些服務？2，服務質量(QoS)如何描述？3，傳輸層如何向上層提供服務？4，通過哪些原語向應用層提供服務？6.1TheTransportService第3頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Twotypesoftransportservice○connection-oriented

○connectionless●Whydoweneedtransportlayer?1、Thetransportlayerserviceissimilartothenetworklayerservice.2、Thenetworklayerisonepartofcommunicationsubnet,whoseservicesareprovidedbyISP.Theusershavenorealcontroloverthenetworklayer.6.1TheTransportService第4頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Whydoweneedtransportlayer?3、Theonlypossibilityistoputontopofthenetworklayeranotherlayerthatimprovesthequalityoftheservice.4、Evencommunicationsubnethasprovidedverygoodservices,someusersstilldoreliableworkagain.Forexample,band,etc.6.1TheTransportService第5頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Howtousetransportservice?○Method:serviceaccessprimitives○Site：interface,TSAP●Differencebetweentransportserviceandnetworkservice:○DifferentQoS:networkserviceisn’talwaysreliable.transportlayerprovidereliableservices.○Differentserviceobjectnetworkserviceuser:transportentityTransportserviceuser:application.

6.1.2TransportServicePrimitives第6頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Establishconnections：1、服務器執(zhí)行LISTEN原語，阻塞自己直到客戶請求出現(xiàn)。2、客戶端希望與服務器連接，執(zhí)行CONNECT原語，客戶端的傳輸層發(fā)出連接建立請求的TPDU。TPDU:Themessagessentfromtransportentitytotransportentity.3、服務器的傳輸層收到該TPDU，檢查服務器的阻塞情況。如阻塞，喚醒服務器，回送連接建立的應答TPDU4、客戶端的傳輸層收到該TPDU，客戶程序被喚醒，連接建立。6.1.2TransportServicePrimitives第7頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫服務器y號TSAP應用程序x號TSAPListenCRTSAPconnectACCTSAP6.1.2TransportServicePrimitives第8頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●

Datatransmission：1、任何一方A，執(zhí)行RECEIVE原語，阻塞自己，等待對方發(fā)SEND原語。2、對方B執(zhí)行SEND原語，傳輸實體發(fā)送數據TPDU，A收到，將數據部分交給A，解除阻塞；●

Releaseconnections：1、asymmetric：任何一方A執(zhí)行DISCONNECT原語，發(fā)送拆除連接TPDU，到達B，釋放空間，連接釋放。2、symmetric：一方執(zhí)行DISCONNECT后，不發(fā)送數據但可以接收數據，收到對方的拆除TPDU后，拆除連接。6.1.2TransportServicePrimitives第9頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫服務器y號TSAP應用程序x號TSAPReceiveDATATPDUSend6.1.2TransportServicePrimitives第10頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Figure6-5.ThesocketprimitivesforTCP.6.1.3BerkeleySockets第11頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6.1.3BerkeleySockets第12頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●ComparabilitybetweenTlayerandDLlayer▲一點到另外一點的問題▲差錯控制、PDU順序、流量控制問題等●DifferencebetweenTlayerandDLlayer1、Mainreason：differentrunningenvironmentDL層實體之間:physicallineT層實體之間:communicationsubnet6.2ElementsofTransportProtocols第13頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●DifferencebetweenTlayerandDLlayer2、Addressing：DL層：和相鄰的DL層實體通信(線路的另外一端)，明確T層：和哪個主機的哪個應用通信？3、連接建立與拆除DL層：簡單(線路那一端就是對等層實體，連接建立幀丟失和出錯都可以完美地解決)T層：復雜（子網的分組存儲能力，使得舊的重復的分組導致錯誤的連接建立）4、數據緩存和流量控制DL層：為每一個連接分配的緩存區(qū)是固定的T層：為每一個連接動態(tài)分配緩存區(qū)6.2ElementsofTransportProtocols第14頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●尋址在傳輸層的表現(xiàn)：一個應用程序指定與哪個遠程的應用程序進行連接▲子網上的主機很多，和哪臺主機連接▲主機上的應用很多，和哪個應用連接●尋址的一般技術：采用TSAP▲TCP/IP：TSAP=(NSAP,Port) (IP,Port)▲服務守侯在TSAP(某IP的某個端口上)，等待著客戶(已分配了IP,Port)和它建立連接6.2.1Addressing第15頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●NSAP,TSAP,N(網絡連接)和T(傳輸連接)的關系★2個應用(Host1和Host2)通過1個T連接聯(lián)系起來★1個T連接由2個TSAP決定★2個傳輸實體通過1個N連接連接起來★1個T連接建立在1個N連接之上第16頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫服務器122號TSAP應用程序6號TSAPconnect.request6-122TSAPConnect.indication網絡連接尋址的過程第17頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●一個應用如何知道遠程的服務器的TSAP。方案1：每一種服務都有一個固定的TSAP，并且公之于眾。例如：FTPServer的端口號為21，Telnet的端口為23，HTTPServer的端口為80。問題1：只適用于數量少、固定的服務；問題2：某些服務很少被使用，服務進程整天守侯在固定TSAP,浪費資源。6.2.1Addressing第18頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫方案2:initialconnectionprotocol（初始連接協(xié)議:機器上負載較輕的服務器平時不運行，而是在機器上運行一個processserver，守侯在一個知名TSAP，作為其它服務的代理。如果客戶進程試圖和一些服務連接，如果服務器沒有運行，首先和進程服務器連接，進程服務器啟動相應服務器，完成轉交連接。）問題：對有些服務不能夠倉促創(chuàng)建，則不適合使用該協(xié)議。6.2.1Addressing第19頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫▲方案3：名字服務器(nameserver)或目錄服務器(directoryserver)△nameserver維護它所提供的服務和TSAP的對應關系△用戶首先和nameserver建立連接△用戶詢問指定名字的TSAP，nameserver返回TSAP△用戶拆除與nameserver的連接△用戶和指定TSAP建立連接△類比：電話查詢臺△其它：新的服務需要向名字服務器注冊6.2.1Addressing第20頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●本地傳輸實體知道TSAP，如何知道該TSAP所在的機器(NSAP)★層次型地址(hierarchicaladdress):TSAP中包括NSAP地址例如：TSAP=(NSAP,PORT)★平面性地址(flataddress):需要TSAP到NSAP的映射的服務6.2.1Addressing第21頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫TheInternethastwomainprotocolsinthetransportlayer:1.UDP

connectionlessprotocol2.TCPconnection-orientedprotocol6.4TheInternetTransportProtocols:UDP第22頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Mainfunction:▲Provideconnectionlessdatatransmissionforupperlayer.●Application:

▲很多交互只有一個請求和一個響應，數據庫訪問▲對這些應用建立一個連接效率低●Mainidea:▲User’sdataisencapsulatedintoUDP’Sdatafield.▲PassUDPpackettoIPLayer.▲TransmitUDPpackettoobjecthost.

Passthedataparttodifferentapplicationprocessthroughdifferentportnumber.6.4.1IntroductiontoUDP第23頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫UDP頭格式UDP只在IP的數據報服務之上增加了很少一點的功能，即端口的功能和差錯檢測。6.4.1IntroductiontoUDP第24頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫

雖然UDP用戶數據報只能提供不可靠的交付，但UDP在某些方面有其特殊的優(yōu)點：▲發(fā)送數據之前不需要建立連接▲UDP的主機不需要維持復雜的連接狀態(tài)表?！鳸DP用戶數據報只有8個字節(jié)的首部開銷?！W絡出現(xiàn)的擁塞不會使源主機的發(fā)送速率降低，這對某些實時應用非常重要。6.4.1IntroductiontoUDP第25頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6.4.2RemoteProcedureCall在傳統(tǒng)的編程概念中，過程是由程序員在本地編譯完成，并只能局限在本地運行的一段代碼，也即其主程序和過程之間的運行關系是本地調用關系。因此這種結構在網絡日益發(fā)展的今天已無法適應實際需求。傳統(tǒng)過程調用模式無法充分利用網絡上其他主機的資源（如CPU、Memory等），也無法提高代碼在實體間的共享程度，使得主機資源大量浪費。

第26頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Whenaprocessonmachine1callsaprocedureonmachine2,thecallingprocesson1issuspendedandexecutionofthecalledproceduretakesplaceonRemoteProcedureCall第27頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Informationcanbetransportedfromthecallertothecalleeintheparametersandcancomebackintheprocedureresult.Nomessagepassingisvisibletotheprogrammer.6.4.2RemoteProcedureCall第28頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫ThistechniqueisknownasRPC(RemoteProcedureCall)andhasbecomethebasisformanynetworkingapplications.6.4.2RemoteProcedureCall第29頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫通過RPC我們可以充分利用非共享內存的多處理器環(huán)境（例如通過局域網連接的多臺工作站），這樣可以簡便地將應用分布在多臺工作站上，應用程序就像運行在一個多處理器的計算機上一樣。你可以方便的實現(xiàn)過程代碼共享，提高系統(tǒng)資源的利用率，也可以將以大量數值處理的操作放在處理能力較強的系統(tǒng)上運行，從而減輕前端機的負擔。6.4.2RemoteProcedureCall第30頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫RPC其實也是一種C/S的編程模式，有點類似C/SSocket編程模式，但要比它更高一層。當我們在建立RPC服務以后，客戶端的調用參數通過底層的RPC傳輸通道，可以是UDP，也可以是TCP，并根據傳輸前所提供的目的地址及RPC上層應用程序號轉至相應的RPCApplicationPorgrammeServer，且此時的客戶端處于等待狀態(tài)，直至收到應答或TimeOut超時信號。

6.4.2RemoteProcedureCall第31頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫RPC是把傳統(tǒng)本地過程調用的概念加以擴充后引入分布式環(huán)境的一種形式。RPC的形式和行為與傳統(tǒng)本地過程調用極為相似,差別僅在于被調用的procedure(過程)實際運行在與調用者的場點不同的場點上(如圖1).也正是由于這一差別,得通過編寫程序來實現(xiàn)兩場地之間的連接和信息溝通。

6.4.2RemoteProcedureCall第32頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6.4.2RemoteProcedureCall第33頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫RPC機制的實質是實現(xiàn)OSI七層模型中的會話層功能.它在兩個試圖進行通信的場點之間建立一條邏輯信道(即會話連接),并利用這個信道交換信息,不用時就釋放連接.下面我們就來看看RPC的通信模型。6.4.2RemoteProcedureCall第34頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6.4.2RemoteProcedureCall第35頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Client端:1)

發(fā)送遠程過程調用的消息(以消息包形式)給遠程的server端；2)

等待,直到收到server端對該請求的回復；3)

一旦接收到來自server端的返回執(zhí)行結果,就繼續(xù)執(zhí)行后面的程序。Server端:

1)

傾聽狀態(tài),等待client端發(fā)送過程調用消息;2)

一旦接收到過程調用消息,server就抽取參數并分析它,然后執(zhí)行所請求的過程;3)

將執(zhí)行結果以消息包形式回送給client。

6.4.2RemoteProcedureCall第36頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫其中stub是一組RPC機制的操作原語,這些原語構成了RPC的實現(xiàn)細節(jié),它可以獨立于client、server編程.Fig6.24Stepsinmakingaremoteprocedurecall.6.4.2RemoteProcedureCall第37頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫1)調用者調用本地stub中的一個過程(開始遠程過程調用請求)。6.4.2RemoteProcedureCall第38頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫2)這個stub過程把有關的參數組裝成一個消息包或一組消息包,形成一條消息。運行此執(zhí)行過程的遠程場點的IP地址和執(zhí)行該過程的進程ID號也包含在這條消息中。6.4.2RemoteProcedureCall第39頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫3)將這條消息發(fā)送給對應的RPCruntime(RPC運行庫)子程序,由這個子程序將消息發(fā)送到遠程場點。6.4.2RemoteProcedureCall第40頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫4)在接收到這條消息時,server端的RPCruntime子程序調用與被調用者對應的stub中的一個子程序,并讓它來處理消息。6.4.2RemoteProcedureCall第41頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫5)與被調用者對應的stub中的這個子程序解封裝消息,解析出相關參數,并用本地調用方式執(zhí)行所指定的過程。6.4.2RemoteProcedureCall第42頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6)

返回調用結果，調用者對應的stub子程序執(zhí)行return語句返回到用戶,整個RPC過程結束。6.4.2RemoteProcedureCall第43頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫實際上，從上面這個執(zhí)行過程中，我們可以看到RPC的實現(xiàn)主要有兩個問題需要解決。一個是在遠程過程調用時，如何定位遠程場點；另外一個就是相關的兩個場點必須能協(xié)同工作，所有這些工作對用戶都是透明的，依次執(zhí)行。

6.4.2RemoteProcedureCall第44頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫RTP被定義為傳輸音頻、視頻、模擬數據等實時數據的傳輸協(xié)議。1、應用領域：實時多媒體2、流動的媒體在網絡上傳輸音/視頻（A/V）等多媒體信息，有下載和流式傳輸兩種方案。▲采用下載方式，用戶必須考慮兩個因素：①對客戶端的存儲需求和播放啟動延時。因為A/V文件一般都較大，所以需要的存儲容量也較大；②同時由于網絡帶寬的限制，下載常常要花數分鐘甚至數小時。

6.4.3TheReal-TimeTransportProtocol第45頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫▲流媒體簡單來說就是應用流技術在網絡上傳輸的多媒體文件.

流技術就是把連續(xù)的影象和聲音信息經過壓縮處理后放上網站服務器，讓用戶一邊下載一邊觀看、收聽，而不需要等整個壓縮文件下載到自己機器后才可以觀看的網絡傳輸技術。

流技術先在使用者端的電腦上創(chuàng)建緩沖區(qū)，于播放前預先下載一段數據作為緩沖，當網路實際連線速度小于播放所耗用資料的速度時，播放程序就會取用這一小段緩沖區(qū)內的數據，避免播放的中斷，使得播放品質得以維持。6.4.3TheReal-TimeTransportProtocol第46頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫支持流媒體傳輸的網絡協(xié)議：（1）實時傳輸協(xié)議RTP（Real-timeTransportProtocol），一種用于Internet上針對多媒體數據流的一種傳輸協(xié)議。（2）實時傳輸控制協(xié)議RTCP(Real-timeTransportControlProtocol)，和RTP一起提供流量控制和擁塞控制服務。（3）實時流協(xié)議RTSP(RealTimeStreamingProtocol)

，定義了一對多的應用程序如何有效地通過IP網絡傳送多媒體數據。（4）RSVP協(xié)議(ResourceReserveProtocol），正在開發(fā)的Internet上的資源預訂協(xié)議。

6.4.3TheReal-TimeTransportProtocol第47頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Figure6-25.(a)ThepositionofRTPintheprotocolstack.(b)Packetnesting.6.4.3TheReal-TimeTransportProtocol第48頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫前面講到UDP，它是一種無連接、不可靠的服務，一般應用在多媒體或C/S模型中，但大多數情況下需要可靠的數據傳輸服務。

6.5TheInternetTransportProtocols:TCP第49頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫△功能：提供可靠的，面向連接的數據傳輸服務，定義在RFC793?！鱐CP協(xié)議的設計目標：⑴IP協(xié)議提供的數據傳輸服務不可靠。

⑵TCP協(xié)議在IP協(xié)議提供的數據傳輸服務基礎上，提供可靠的、端到端的字節(jié)流服務。

6.5.1IntroductiontoTCP第50頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫TSAP：套接字(socket)●

Port:一個UDP、TCP實體可以向多個高層用戶提供服務，使用端口區(qū)分不同的用戶。▲小于1024的端口是知名端口(well-knownport),例:HTTP80；FTP21；TELNET23●TSAP=IP地址+16bit端口號▲服務器守侯在哪個IP地址的哪個Port?▲一個客戶應用程序在哪個IP地址的機器上，并且使用什么端口?▲套接字(socket):TCP/UDP協(xié)議中的TSAP6.5.2TheTCPServiceModel第51頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●TCP

connection：△發(fā)送方套接字+接收方套接字(2endpoints)△一個套接字可以被多個連接使用,例子ftpServer●TCPfactors：△Asender，areceiver△Reliable,orderedbytestream.

△

fullduplex：Trafficcangoinbothdirectionsatthesametime.△

connection-oriented：在通信之前，交換控制信息，初始化表空間等操作。△

Flowcontrol：發(fā)送端不會淹沒接收端6.5.2TheTCPServiceModel第52頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●TCP協(xié)議交換的數據單位：段(segment)△段的結構：20字節(jié)的頭部+一些字節(jié)的選項0或多個字節(jié)的數據△段的大?。河蒚CP實體確定,但是要受到兩個限制形成的數據段不大于65515個字節(jié)數據段的長度>網絡MTU(一般為1500)時將該IP分組分段每一個fragment都有TCP頭和IP頭6.5.3TheTCPProtocol第53頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫段和應用數據的關系●應用數據作為段的數據部分●應用數據可以幾塊一起作為一個段的數據部分●也可以將一塊應用數據分解成幾個部分，分別作為段的數據部分Figure6-28.(a)Four512-bytesegmentssentasseparateIPdatagrams.(b)The2048bytesofdatadeliveredtotheapplicationinasingleREADcall.6.5.3TheTCPProtocol第54頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●TCP協(xié)議的流量控制△使用滑動窗口協(xié)議，窗口的大小由發(fā)送端向接收端申請，由接收端確定。△發(fā)送窗口的大小是動態(tài)地由接收端調整的，最大尺寸是變化的?！魇褂?2位序號(段的標識、確認、流量控制)△發(fā)送段給對方，對方將確認信息和窗口信息通過反向數據捎帶過來6.5.3TheTCPProtocol第55頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●TCP協(xié)議的復雜性△IP協(xié)議提供的服務不可靠△而TCP協(xié)議要在IP協(xié)議的基礎上向應用層提供可靠的數據傳遞服務△一些復雜的情況分組丟失或因為擁塞而延遲，超時重發(fā)可能要分段，目標端TCP重組失序，目標端TCP排序6.5.3TheTCPProtocol第56頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Sourceport:源端口DesPort：目標端口6.5.4TheTCPSegmentHeader第57頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫sequencenumber：順序號6.5.4TheTCPSegmentHeader第58頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫acknowledgementnumber：希望對方下一個傳輸的字節(jié)號是從ACKNUM開始6.5.4TheTCPSegmentHeader第59頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Headerlen:指明TCP的頭部長度，4字節(jié)為單位，也指數據開始的地方6.5.4TheTCPSegmentHeader第60頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6bit未用6.5.4TheTCPSegmentHeader第61頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6個1bit標志6.5.4TheTCPSegmentHeader第62頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫URG:緊急指針被使用的話，置為16.5.4TheTCPSegmentHeader第63頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫ACK：當ACK=1時，ACKNUM是有效的；6.5.4TheTCPSegmentHeader第64頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫PSH：PSH=1，接收端TCP實體立即將數據交付給應用層實體，而不是等緩沖區(qū)滿6.5.4TheTCPSegmentHeader第65頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫RST：表示拒絕連接或拒絕非法的數據段，由于復位或主機崩潰造成的錯誤的連接出現(xiàn)6.5.4TheTCPSegmentHeader第66頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫SYN：用于連接管理，連接建立;當SYN=1，ACK=0時：連接請求；當SYN=1，ACK=1時：連接接受6.5.4TheTCPSegmentHeader第67頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫FIN：用于連接管理，連接釋放；FIN=1，表明，本方已沒有數據發(fā)送了，但可以接收數據，單向連接狀態(tài)6.5.4TheTCPSegmentHeader第68頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Winsize:窗口大小，接收端愿意接收的byte個數Checksum:校驗和，增加可靠性6.5.4TheTCPSegmentHeader第69頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫▲校驗范圍：將整個段和偽頭部▲計算校驗和的技術：以16bit為單位(如果不足補1個byte)，以補碼形式相加，最后對結果求補▲違反了分層的原則。Checksum:校驗和，增加可靠性第70頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Option:選項：增加額外設置，變長6.5.4TheTCPSegmentHeader第71頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫傳輸層連接建立的復雜性1、傳輸層實體之間是整個子網；2、子網的存儲能力，會造成延遲的重復分組問題6.5.5TCPConnectionEstablishment第72頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●傳輸層連接技術：three-wayhandshake▲CR：主機1選擇一個初始序號x，向主機2發(fā)送一個連接請求的TPDU▲ACC：主機2接收該TPDU，并回送一個確認TPDU，包含了自己的序號y▲DATA：主機1向主機2發(fā)送的第一個數據TPDU中確認了主機2的序號y6.5.5TCPConnectionEstablishment第73頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Three-wayhandshake:●情況1：延遲重復分組▲CR是延遲的重復分組▲主機2接收主機1的請求，并回應ACC，序號為y▲主機1拒絕連接的建立▲主機2釋放半連接有錯6.5.5TCPConnectionEstablishment第74頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●情況2：延遲重復分組▲存在延遲的CR和對ACC確認，而且它們的時序配合的很好▲主機2收到CR，回應一個確認ACK，序號為y?！鴣砹艘粋€對ACK的確認-DATA(延遲的)，序號為x,但是ACK序號為不同于Y▲主機2拒絕這個連接▲主機1拒絕這個連接Three-wayhandshake:6.5.5TCPConnectionEstablishment第75頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接的兩種方式非對稱釋放

當一方發(fā)出DR(DisconnectRequest)后，雙方通信中斷非常突然，可能會造成數據丟失不適合于傳輸層數據通信6.5.6TCPConnectionRelease第76頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接的兩種方式對稱釋放（四次揮手）將一個雙向連接看成兩個方向的單向連接構成一方發(fā)出DR后，不發(fā)送數據，但能夠接收數據(結束了這一方向到對方的單向連接)另外一方在發(fā)出DR后，結束了另一個方向的單向連接整個通信終止DRDR6.5.6TCPConnectionRelease第77頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接（正常情況）1、主機1發(fā)出DR，啟動定時器2、主機2收到DR，啟動定時器，并回應3、主機1收到回應，再發(fā)送一個對回應的確認ACK，釋放連接4、主機2收到ACK，釋放連接6.5.6TCPConnectionRelease第78頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接（異常）▲ACK丟失1、主機2定時器超時2、主機2釋放連接6.5.6TCPConnectionRelease第79頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接（異常）第二個DR丟失1、主機1的定時器超時2、再次要求釋放連接6.5.6TCPConnectionRelease第80頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接（異常）第二個DR丟失，且主機1重發(fā)的DR也丟失1、N次超時之后，主機1釋放2、主機2定時器超時，釋放連接6.5.6TCPConnectionRelease第81頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫釋放連接的三次握手技術▲失敗的情況主機1的DR丟失，并且以后重發(fā)的DR都丟失。主機1重發(fā)N次之后，釋放連接。主機2沒有收到釋放連接的要求，維持連接。半連通狀態(tài)。▲不好的解決辦法主機1重發(fā)N次之后，仍然維持連接。問題主機2有可能收到DR(主機2的DR丟失)，已經釋放▲解決辦法在一段時間內沒有收到任何TPDU，連接自動釋放。要求雙方，在沒有數據發(fā)送期間，通過定時器的觸發(fā)，發(fā)送一些偽TPDU。6.5.6TCPConnectionRelease第82頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6.5.8TCPTransmissionPolicy第83頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●DL層的數據傳輸策略▲發(fā)送端有幀落入發(fā)送窗口,允許就發(fā)送▲接收端只要將幀收到并交付給上層就發(fā)確認給對方，讓發(fā)送窗口向前走?！馜L層的傳輸策略不適合傳輸層▲主要問題：效率太低?！粋€例子:客戶端是telnet客戶程序；服務器是交互式編輯器。6.5.8TCPTransmissionPolicy第84頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫◆客戶每輸入一個字符，交給TCP，形成一個IP分組，41字節(jié)◆接收端TCP，每收到一個IP分組，發(fā)確認分組，40B1:Typeachar2:totcp3:DATAPDU4:ACK6:Buffer8:result7:result5:toServer一個例子第85頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫◆接收端服務器接受1個字符，發(fā)一個分組告訴發(fā)送端緩沖區(qū)向前移動，40Bytes◆處理結果返回客戶端(回顯)，41Bytes◆對每個輸入的字符共162B，并發(fā)送4個數據段。6.5.8TCPTransmissionPolicy1:Typeachar2:totcp3:DATAPDU4:ACK6:Buffer8:result7:result5:toServer第86頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫1:Typeachar2:totcp3:DATAPDU4:ACK6:Buffer8:result7:result5:toServer第87頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Nagle‘salgorithm▲目的：使發(fā)送方不再發(fā)送小的數據段▲原理：1,Whendatacomeintothesenderonebyteatatime,justsendthefirstbyteandbufferalltherestuntiltheoutstandingbyteisacknowledged.2,ThensendallthebufferedcharactersinoneTCPsegmentandstartbufferingagainuntiltheyareallacknowledged.6.5.8TCPTransmissionPolicy第88頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫1、接收TCP收到很大的數據塊，將它的緩存用完sillywindowsyndrome第89頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫2、接收端的應用一次只從TCP中取走一個字符sillywindowsyndrome第90頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫3、接收TCP向發(fā)送端TCP報告它出現(xiàn)了一個字符的可用緩存sillywindowsyndrome第91頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫4、發(fā)送端發(fā)送一個字符，緩存用完，停止發(fā)送sillywindowsyndrome第92頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫5、接收端的應用再次從TCP中取走一個字符sillywindowsyndrome第93頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫6、接收端TCP向發(fā)送端TCP報告它出現(xiàn)了一個可用的緩存sillywindowsyndrome第94頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Solution：clarkalgorithm▲禁止接收端發(fā)送較少字節(jié)的窗口更新信息▲等到緩存有最大段大小的空間；▲或緩存區(qū)有1/2空閑時；▲以上兩者的最小值?！癜l(fā)送端和接收端相互配合▲解決問題：一次發(fā)送一個字符的問題，效率低?！l(fā)送端：采用nagle算法，或發(fā)送端積攢一個完整的數據段或接收緩存區(qū)的1/2時發(fā)送，解決發(fā)送方不要發(fā)送太小的數據段。▲接收端：clark算法，解決接收方不要請求太小的數據段。sillywindowsyndrome第95頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●Congestion▲擁塞：分組的數量已超過了子網的處理能力?！鴵砣刂浦饕枷耄航档拖蜃泳W中發(fā)送分組的速率?！穹纸M的來源▲網絡層的數據大都來源于傳輸層，傳輸層是源?！罱K來源于應用，對于用戶而言，不可能要求他們減少數據產生的速率。6.5.9TCPCongestionControl第96頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫●原因：應用很多，假如在應用層進行擁塞控制，將用戶的數據緩存起來不是一個很有效的方案?！裨趥鬏攲訉嶓w中體現(xiàn)擁塞控制，緩存所有應用產生的數據，減少發(fā)往子網的速率，是很有效的方法?！駬砣臋z測▲以定時器超時作為擁塞的指標▲定時器超時的原因分組由于出錯而丟失，情況比較少分組由于擁塞而被路由器丟棄，情況比較多分組由于接收端緩存不夠而被目標主機拋棄，通過預留緩存區(qū)辦法很少發(fā)生●分組被丟棄的原因接收端緩存有限，一次發(fā)送分組的數量>緩存區(qū)網絡處理能力有限，超過了網絡的容量6.5.9TCPCongestionControl第97頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫Figure6-36.(a)Afastnetworkfeedingalow-capacityreceiver.(b)Aslownetworkfeedingahigh-capacityreceiver.6.5.9TCPCongestionControl第98頁，共107頁，2023年，2月20日，星期日百度文庫百度文庫發(fā)送方維持的兩個窗口●擁塞窗口(congestionwindow)：目的是不讓發(fā)送速率超過子網處理能力●接收窗