計(jì)算機(jī)網(wǎng)絡(luò):Internet中的傳輸協(xié)議_第1頁
計(jì)算機(jī)網(wǎng)絡(luò):Internet中的傳輸協(xié)議_第2頁
計(jì)算機(jī)網(wǎng)絡(luò):Internet中的傳輸協(xié)議_第3頁
計(jì)算機(jī)網(wǎng)絡(luò):Internet中的傳輸協(xié)議_第4頁
計(jì)算機(jī)網(wǎng)絡(luò):Internet中的傳輸協(xié)議_第5頁
已閱讀5頁,還剩40頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論