计算机网络：Internet中的传输协议

1TransportProtocolsInInternetConceptsTCPUDP2OrientationWemoveonelayerupandlookatthetransportlayer.3OrientationTransportlayerprotocolsareend-to-endprotocolsTheyareonlyimplementedatthehosts4TransportProtocolsintheInternetUDP-UserDatagramProtocoldatagramorientedunreliable,connectionlesssimpleunicastandmulticastusefulonlyforfewapplications,e.g.,multimediaapplicationsusedalotforservicesnetworkmanagement(SNMP),routing(RIP),naming(DNS),etc.TCP-TransmissionControlProtocolstreamorientedreliable,connection-orientedcomplexonlyunicastusedformostInternetapplications:web(http),email(smtp),filetransfer(ftp),terminal(telnet),etc.

TheInternetsupports2transportprotocols5UDP-UserDatagramProtocolUDPissupportsunreliabletransmissionsofdatagramsUDPmerelyextendsthehost-to-to-hostdeliveryserviceofIPdatagramtoanapplication-to-applicationserviceTheonlythingthatUDPaddsismultiplexinganddemultiplexing6UDPFormat

Portnumbersidentifysendingandreceivingapplications(processes).Maximumportnumberis216-1=65,535

MessageLengthisatleast8bytes(I.e.,Datafieldcanbeempty)andatmost65,535

Checksumisforheader(ofUDPandsomeoftheIPheaderfields)7PortNumbersUDP(andTCP)useportnumberstoidentifyapplicationsAgloballyuniqueaddressatthetransportlayer(forbothUDPandTCP)isatuple

<IPaddress,portnumber>Thereare65,535UDPportsperhost.8TCPOverviewTCP=TransmissionControlProtocolConnection-orientedprotocolProvidesareliableunicastend-to-endbytestreamoveranunreliableinternetwork.9Connection-OrientedBeforeanydatatransfer,TCPestablishesaconnection:OneTCPentityiswaitingforaconnection(“server”)TheotherTCPentity(“client”)contactstheserverTheactualprocedureforsettingupconnectionsismorecomplex.Eachconnectionis

fullduplex10Connection-Oriented11TCPFormat

TCPsegmentshavea20byteheaderwith>=0bytesofdata.12TCPheaderfieldsPortNumber:Aportnumberidentifiestheendpointofaconnection.Apair<IPaddress,portnumber>identifiesoneendpointofaconnection.Twopairs<clientIPaddress,serverportnumber>and<serverIPaddress,serverportnumber>identifyaTCPconnection.13TCPheaderfieldsSequenceNumber(SeqNo):Sequencenumberis32bitslong.SotherangeofSeqNois0<=SeqNo<=232-1

4.3Gbyte EachsequencenumberidentifiesabyteinthebytestreamInitialSequenceNumber(ISN)ofaconnectionissetduringconnectionestablishment14TCPheaderfieldsAcknowledgementNumber(AckNo):Acknowledgementsarepiggybacked,I.e asegmentfromA->BcancontainanacknowledgementforadatasentintheB->AdirectionAhostsusestheAckNofieldtosendacknowledgements.(IfahostsendsanAckNoinasegmentitsetsthe“ACKflag”)TheAckNocontainsthenextSeqNothatahostswantstoreceive

Example:

Theacknowledgementforasegmentwithsequencenumbers0-1500isAckNo=150115TCPheaderfieldsAcknowledgeNumber(cont’d)TCPusestheslidingwindowflowprotocoltoregulatetheflowoftrafficfromsendertoreceiverTCPusesthefollowingvariationofslidingwindow:noNACKs(NegativeACKnowledgement)onlycumulativeACKs16TCPheaderfieldsExample:

Assume:Sendersendstwosegmentswith“1..1500”and“1501..3000”,butreceiveronlygetsthesecondsegment.Inthiscase,thereceivercannotacknowledgethesecondpacket.ItcanonlysendAckNo=117TCPheaderfieldsHeaderLength(4bits):Lengthofheaderin32-bitwordsNotethatTCPheaderhasvariablelength(withminimum20bytes)18TCPheaderfieldsFlagbits:URG: UrgentpointerisvalidIfthebitisset,thefollowingbytescontainanurgentmessageintherange:SeqNo<=urgentmessage<=SeqNo+urgentpointer

ACK:AcknowledgementNumberisvalidPSH:PUSHFlagNotificationfromsendertothereceiverthatthereceivershouldpassalldatathatithastotheapplication.Normallysetbysenderwhenthesender’sbufferisempty19TCPheaderfieldsFlagbits:RST:ResettheconnectionTheflagcausesthereceivertoresettheconnectionReceiverofaRSTterminatestheconnectionandindicateshigherlayerapplicationabouttheresetSYN:SynchronizesequencenumbersSentinthefirstpacketwheninitiatingaconnectionFIN:SenderisfinishedwithsendingUsedforclosingaconnectionBothsidesofaconnectionmustsendaFIN20TCPheaderfieldsWindowSize:EachsideoftheconnectionadvertisesthewindowsizeWindowsizeisthemaximumnumberofbytesthatareceivercanaccept.Maximumwindowsizeis216-1=65535bytesTCPChecksum:TCPchecksumcoversoverbothTCPheaderandTCPdata(alsocoverssomepartsoftheIPheader)UrgentPointer:OnlyvalidifURGflagisset21TCPheaderfieldsOptions:22TCPheaderfieldsOptions:NOPisusedtopadTCPheadertomultiplesof4bytesMaximumSegmentSizeWindowScaleOptions

IncreasestheTCPwindowfrom16to32bits,I.e.,thewindowsizeisinterpreteddifferentlyThisoptioncanonlybeusedintheSYNsegment(firstsegment)duringconnectionestablishmenttimeTimestampOptionCanbeusedforroundtripmeasurements23ConnectionManagementinTCPOpeningaTCPConnectionClosingaTCPConnectionSpecialScenariosStateDiagram24TCPConnectionEstablishmentTCPusesathree-wayhandshaketoopenaconnection:

(1)ACTIVEOPEN:ClientsendsasegmentwithSYNbitset*portnumberofclientinitialsequencenumber(ISN)ofclient

(2)PASSIVEOPEN:ServerrespondswithasegmentwithSYNbitset*initialsequencenumberofserverACKforISNofclient(3)Clientacknowledgesbysendingasegmentwith:ACKISNofserver(*countsasonebyte)25Three-WayHandshake26Three-WayHandshake27TCPConnectionTerminationEachendofthedataflowmustbeshutdownindependently(“half-close”)IfoneendisdoneitsendsaFINsegment.ThismeansthatnomoredatawillbesentFourstepsinvolved: (1)XsendsaFINtoY(activeclose) (2)YACKstheFIN, (atthistime:YcanstillsenddatatoX) (3)andYsendsaFINtoX(passiveclose)

(4)XACKstheFIN.28TCPStates29TCP-PartIIDatatransmissionFlowcontrolErrorcontrolCongestioncontrol30InteractiveandbulkdatatransferTCPapplicationscanbeputintothefollowingcategoriesbulkdatatransfer -ftp,mail,httpinteractivedatatransfer -telnet,rloginTCPhasheuristicstodealtheseapplicationtypes.Forinteractivedatatransfer:Trytoreducethenumberofpackets31

FlowControl

CongestionControl

ErrorControlTCP:32TCPFlowControl33TCPFlowControl

TCPimplementsslidingwindowflowcontrol Sendingacknowledgementsisseparatedfromsettingthewindowsizeatsender.AcknowledgementsdonotautomaticallyincreasethewindowsizeAcknowledgementsarecumulative34SlidingWindowFlowControl

SlidingWindowProtocolisperformedatthebytelevel:Here:Sendercantransmitsequencenumbers6,7,8.35SlidingWindow:“WindowCloses”

Transmissionofasinglebyte(withSeqNo=6)andacknowledgementisreceived(AckNo=5,Win=4):36SlidingWindow:“WindowOpens”

Acknowledgementisreceivedthatenlargesthewindowtotheright(AckNo=5,Win=6):

AreceiveropensawindowwhenTCPbufferempties(meaningthatdataisdeliveredtotheapplication).37SlidingWindow:“WindowShrinks”

Acknowledgementisreceivedthatreducesthewindowfromtheright(AckNo=5,Win=3):

Shrinkingawindowshouldnotbeused38WindowManagementinTCPThereceiverisreturningtwoparameterstothesenderTheinterpretationis:Iamreadytoreceivenewdatawith SeqNo=AckNo,AckNo+1,….,AckNo+Win-1ReceivercanacknowledgedatawithoutopeningthewindowReceivercanchangethewindowsizewithoutacknowledgingdata39TCPCongestionControl40TCPCongestionControlTCPhasamechanismforcongestioncontrol.ThemechanismisimplementedatthesenderThesenderhastwoparameters:CongestionWindow(cwnd)Slow-startthreshholdValue(ssthresh) InitialvalueistheadvertisedwindowsizeCongestioncontrolworksintwomodes:slowstart(cwnd<ssthresh)congestionavoidance(cwnd>=ssthresh41SlowStartInitialvalue: Setcwnd=1

Note:Unitisasegmentsize.TCPactuallyisbasedonbytesandincrementsby1MSS(maximumsegmentsize)Thereceiversendsanacknowledgement(ACK)foreachpacketNote:Generally,aTCPreceiversendsanACKforeveryothersegment.42SlowStartEachtimeanACKisreceivedbythesender,thecongestionwindowisincreasedby1segment:

cwnd=cwnd+1IfanACKacknowledgestwosegments,cwndisstillincreasedbyonly1segment.EvenifACKacknowledgesasegmentthatissmallerthanMSSbyteslong,cwndisincreasedby1.DoesSlowStartincrementslowly?Notreally.

Infact,theincreaseofcwndisexponential43SlowStartExa