Lecture5:TheTransportLayer(InternetTransportProtocols)AdvancedComputerNetworkYangQinDepartmentofComputerScienceShenzhenGraduateSchoolHarbinInstituteofTechnologyLayer4:TheTransportLayerAnOverviewofLayer4TCP(TransmissionControlProtocol)UDP(UserDatagramProtocol)Layer4:TheTransportLayerTheTCP/IPProtocolStackIPisaLayer3protocolandTCPisaLayer4protocol.TCPisconnection-orientedandensuresreliabilitybutIPisconnection-lesswithbesteffortattemptsatdelivery.Flowcontrolandreliabilityofthetransportlayercanbecomparedtoastudentwhostudiesonlyoneyearofaforeignlanguage,thenvisitsthecountrythatusesthatlanguage.Wheneverthestudenttriestojoinaconversation,heorshehastoaskeveryone,frequently,torepeathis/herwords(reliability)andtospeakslowly(flowcontrol).TCP:connection-orientedreliabledividesoutgoingmessagesintosegmentsreassemblesmessagesatthedestinationstationre-sendsanythingnotreceivedUDP:connectionlessunreliabletransmitmessagesprovidesnosoftwarecheckingforsegmentdelivery(unreliable)doesnotreassembleincomingmessagesusesnoacknowledgmentsprovidesnoflowcontrolLayer4:TheTransportLayerLayer4:TheTransportLayerAnOverviewofLayer4TCP(TransmissionControlProtocol)UDP(UserDatagramProtocol)Anapplication:NATandPATTCPServiceModelApplicationsaccessTCPservicesthrough“sockets”Socketispresentedas“(IPaddress,port)”Everyconnectionisexpressedas(socketsource,socketdestination),whichisapoint-to-pointfull-duplexchannelTCPdoesnotsupportmulticastandbroadcastBothTCPandUDPuseportnumberstokeeptrackofdifferentconversationsthatcrossthenetworkatthesametimeApplicationsoftwaredevelopershaveagreedtousethewell-knownportnumbersthataredefinedinRFC1700TCPServiceModelPortnumbersbelow255arereservedforTCPandUDPpublicapplications.Originatingsourceportnumbersaredynamicallyassignedbythesourcehost.Usually,itisanumberlargerthan1023.SequenceandacknowledgmentnumbersisnecessaryforTCPtotracksincetwosuccessiveIPpacketsmayinmanyinstancesNOTtravelthesamepathandarriveatthedestinationhostoutoforder.TCPServiceModelProblemsmustbesolvedinTCP:ReliabletransferFlowcontrolSlidingwindowcongestionavoidance…ConnectionmanagementEstablishconnection:threehandshakesReleaseconnection:fourhandshakesTCPProtocolTCPSegmentHeaderFielddefinitionsintheTCPsegment:sourceport-numberofthecallingportdestinationport-numberofthecalledportsequencenumber-numberusedtoensurecorrectsequencingofthearrivingdata,32bitsacknowledgmentnumber-nextexpectedTCPoctet,32bitsTCPheaderlength(HLEN)–numberof32-bitwordsintheheaderreserved-settozero,6bitscodebits-controlfunctions(suchassetupandterminationofasession)window-numberofoctetsthatthesenderiswillingtoacceptchecksum-calculatedchecksumoftheheaderanddatafieldsurgentpointer-indicatestheendoftheurgentdataoption-oneoption-maximumTCPsegmentsizedata-upper-layerprotocoldataTCPProtocolCodeBits:URG:workwiththeurgencypointertosendtheurgencydataACK:thissegmentisanACKsegmentPSH:Nodatacachewilldoneinbothsourceanddestinationhost.DatawillbesendorreceiveimmediatelyRST:resettheconnectionbecauseofthefaultsunabletoberecoveredSYN:indicateconnectionestablishingFIN:indicateconnectionreleasingTCPProtocolHostsexchangedatabyusingsegment(TPDU)betweeneachotherEachsegmenthasaheaderof20bytes(exceptoptionalparts)and0ormoredatabytesThesizeofthesegmentmustbematchedwithIPpackets,andalsomustsatisfythedemandofbottomlayers.Forexample,theMTU(MaximalTransferUnit)ofEthernetis1500bytesEachbytehasa32bitssequencenumberSlidingwindowprotocolisusedinTCPtocontrolthedataflow.Intheprotocol,thesequencenumberoftheACKsegmentisjustthesequencenumberoughttobereceivedTCPConnectionManagementRecall:TCPsender,receiverestablish“connection”beforeexchangingdatasegmentsinitializeTCPvariables:seq.#sbuffers,flowcontrolinfo(e.g.RcvWindow)client:connectioninitiatorSocketclientSocket=newSocket(hostname,portnumber);server:contactedbyclientSocketconnectionSocket=welcomeSocket.accept();Threewayhandshake:Step1:clienthostsendsTCPSYNsegmenttoserverspecifiesinitialseq#nodataStep2:serverhostreceivesSYN,replieswithSYNACKsegmentserverallocatesbuffersspecifiesserverinitialseq.#Step3:clientreceivesSYNACK,replieswithACKsegment,whichmaycontaindataTCP:EstablishConnectionSetupconnection:threehandshakesServer:executesLISTENandACCEPTprimitive,andmonitorspassivelyClient:executesCONNECTprimitive,generateaTCPsegmentwithSYN=1andACK=0,whichstandsforconnectionrequestThefirsthandshakeTCP:EstablishConnectionServerreceivestheTCPsegmentandcheckifthereisserviceprocessmonitoringtherequiredport.Ifnoneprocessismonitoringtheport,answeraTCPsegmentwithRST=1Ifthereisanyserviceprocessmonitoringtheport,theprocesscandeciderejectoraccepttheconnectionrequestIfaccepttheconnection,sendaTCPsegmentwithSYN=1andACK=1toacknowledgetheconnection,andrequesttheconnectiontotheotherside(thesecondhandshake)Whenreceivestheacknowledgement,theclientwillsendasegmentwithSYN=0andACK=1toacknowledgetheconnection(thethirdhandshake)Athree-wayhandshake/openconnectionsequencesynchronizesaconnectionatbothendsbeforethetransferreddatareachest