TCP betroubaarheid vervoer
Ons is almal vertroud met TCP -protokol as 'n betroubare vervoerprotokol, maar hoe verseker dit die betroubaarheid van vervoer?
Om betroubare oordrag te bewerkstellig, moet baie faktore oorweeg word, soos datakorrupsie, verlies, duplisering en skerwe buite die orde. As hierdie probleme nie opgelos kan word nie, kan betroubare oordrag nie bereik word nie.
Daarom gebruik TCP meganismes soos volgorde -nommer, erkennings antwoord, beheer beheer, verbindingsbestuur en vensterbeheer om betroubare transmissie te bewerkstellig.
In hierdie artikel fokus ons op die skuifvenster, vloeibeheer en opeenhopingsbeheer van TCP. Die heruitsendingsmeganisme word afsonderlik in die volgende afdeling behandel.
Netwerkvloeibeheer
Netwerkvloeibeheer of weet as netwerkverkeersbeheer is eintlik 'n manifestasie van die subtiele verhouding tussen produsente en verbruikers. U het waarskynlik hierdie scenario baie by die werk of in onderhoude teëgekom. As die produsent se vermoë om te produseer, die verbruiker se vermoë om te verbruik, aansienlik oorskry, sal dit die tou onbepaald groei. In 'n meer ernstige geval, kan u weet dat wanneer RabbitMQ -boodskappe te veel opstyg, dit die prestasie van die hele MQ -bediener kan veroorsaak. Dieselfde geld vir TCP; As dit nie gekontroleer word nie, sal te veel boodskappe in die netwerk geplaas word, en die verbruikers sal hul kapasiteit oorskry het, terwyl die produsente sal voortgaan om duplikaatboodskappe te stuur, wat die prestasie van die netwerk grootliks sal beïnvloed.
Om hierdie verskynsel aan te spreek, bied TCP 'n meganisme vir die sender om die hoeveelheid data wat gestuur is, te beheer op grond van die werklike ontvangsvermoë van die ontvanger, wat bekend staan as vloeibeheer. Die ontvanger handhaaf 'n ontvangsvenster, terwyl die sender 'n stuurvenster onderhou. Daar moet op gelet word dat hierdie vensters slegs vir 'n enkele TCP -verbinding is en nie alle verbindings 'n venster deel nie.
TCP bied vloeibeheer deur 'n veranderlike te gebruik vir 'n ontvangsvenster. Die ontvangsvenster gee die sender 'n aanduiding van hoeveel kasruimte nog beskikbaar is. Die sender beheer die hoeveelheid data wat volgens die werklike aanvaardingskapasiteit van die ontvanger gestuur is.
Die ontvanger -gasheer stel die sender in kennis van die grootte van die data wat hy kan ontvang, en die sender stuur tot op hierdie limiet. Hierdie limiet is die venstergrootte, onthou jy die TCP -kop? Daar is 'n ontvangsvensterveld wat gebruik word om die aantal grepe wat die ontvanger is, aan te dui of bereid is om te ontvang.
Die sender -gasheer sal periodiek 'n venster -ondersoekpakket stuur, wat gebruik word om vas te stel of die ontvanger -gasheer nog steeds data kan aanvaar. As die buffer van die ontvanger in gevaar is om oorloop, is die venstergrootte op 'n kleiner waarde ingestel om die sender opdrag te gee om die hoeveelheid data wat gestuur is, te beheer.
Hier is 'n netwerkvloei -kontrole -diagram:
Netwerkopeenhopingsbeheer
Voordat ons opeenhopingsbeheer bekendstel, moet ons verstaan dat daar benewens die ontvangsvenster en die stuurvenster ook 'n opeenhopingsvenster is, wat hoofsaaklik gebruik word om die probleem op te los in watter tempo die sender data na die ontvangsvenster begin stuur. Daarom word die opeenhopingsvenster ook deur die TCP -sender gehandhaaf. Ons het 'n algoritme nodig om te besluit hoeveel data geskik is om te stuur, want dit is nie ideaal om te min of te veel data te stuur nie, vandaar die konsep van 'n opeenhopingsvenster.
Wat ons vermy het, was die sender wat die kas van die ontvanger met data gevul het, maar ons het nie geweet wat in die netwerk aangaan nie. Tipies is rekenaarnetwerke in 'n gedeelde omgewing. As gevolg hiervan, kan daar netwerkopeenhopings wees as gevolg van kommunikasie tussen ander leërskare.
As die netwerk vol is, kan dit voortgaan om 'n groot aantal pakkies te stuur, maar dit kan probleme veroorsaak, soos vertraging en verlies aan pakkies. Op hierdie punt sal TCP die data weergee, maar die heruitsending sal die las op die netwerk verhoog, wat lei tot groter vertragings en meer pakkieverliese. Dit kan in 'n bose siklus beland en aanhou om groter te word.
TCP kan dus nie ignoreer wat op die netwerk gebeur nie. As die netwerk vol is, offer TCP homself op deur die hoeveelheid data wat dit stuur, te verminder.
Daarom word opeenhopingsbeheer voorgestel, wat daarop gemik is om die hele netwerk met data van die sender te vul. Om die hoeveelheid data wat die sender moet stuur, te reguleer, definieer TCP 'n konsep genaamd die opeenhopingsvenster. Die opeenhopingsbeheeralgoritme sal die grootte van die opeenhopingsvenster volgens die opeenhopingsgraad van die netwerk aanpas om die hoeveelheid data wat deur die sender gestuur is, te beheer.
Wat is 'n opeenhopingsvenster? Wat het dit te doen met die stuurvenster?
Die opeenhopingsvenster is 'n toestandsveranderlike wat deur die sender onderhou word wat die hoeveelheid data wat die sender kan stuur, bepaal. Die opeenhopingsvenster verander dinamies volgens die opeenhopingsvlak van die netwerk.
Die stuurvenster is 'n ooreengekome venstergrootte tussen die sender en die ontvanger wat die hoeveelheid data wat die ontvanger kan ontvang, aandui. Die opeenhopingsvenster en die stuurvenster hou verband; Die stuurvenster is gewoonlik gelyk aan die minimum van die opeenhoping en ontvangs van vensters, dit wil sê SWND = min (CWND, RWND).
Die opeenhopingsvenster verander soos volg:
As daar geen opeenhoping in die netwerk is nie, dit wil sê, daar is geen tydsverloop nie, neem die opeenhopingsvenster toe.
As daar opeenhoping in die netwerk is, neem die opeenhopingsvenster af.
Die sender bepaal of die netwerk gestamp word deur te sien of die ACK -erkenningspakket binne die bepaalde tyd ontvang word. As die sender nie die ACK -erkenningspakket binne die bepaalde tyd ontvang nie, word daar van mening dat die netwerk gestamp is.
Benewens die opeenhopingsvenster, is dit tyd om die TCP -opeenhopingsbeheer -algoritme te bespreek. TCP -opeenhopingsbeheer -algoritme bestaan uit drie hoofdele:
Stadige begin:Aanvanklik is die CWND -opeenhopingsvenster relatief klein, en die sender verhoog die opeenhopingsvenster eksponensieel om vinnig aan te pas by die kapasiteit van die netwerk.
Vermyding van opeenhoping:Nadat die opeenhopingsvenster 'n sekere drempel oorskry, verhoog die sender die opeenhopingsvenster op 'n lineêre manier om die groeitempo van die opeenhopingsvenster te vertraag en om die netwerk te oorlaai.
Vinnige herstel:As opeenhoping plaasvind, halveer die sender die opeenhopingsvenster en gaan die vinnige hersteltoestand in om die ligging van die netwerkherstel deur die ontvangde duplikaat ACK's te bepaal, en verhoog dan die opeenhopingsvenster.
Stadige begin
Wanneer 'n TCP -verbinding tot stand gebring word, word die CWND -venster CWND aanvanklik op 'n minimum MSS (maksimum segmentgrootte) waarde gestel. Op hierdie manier handel die aanvanklike stuurtempo oor MSS/RTT -bytes/tweede. Die werklike beskikbare bandwydte is gewoonlik veel groter as MSS/RTT, dus TCP wil die optimale stuurtempo vind, wat deur middel van 'n stadige begin bereik kan word.
In die stadige beginproses sal die waarde van die opeenhopingsvenster CWND geïnitialiseer word tot 1 MSS, en elke keer as die oordraagbare pakketegment erken word, sal die waarde van CWND met een MSS verhoog word, dit wil sê, die waarde van CWND sal 2 MSS word. Daarna word die waarde van CWND verdubbel vir elke suksesvolle oordrag van 'n pakketegment, ensovoorts. Die spesifieke groeiproses word in die volgende figuur getoon.
Die stuurkoers kan egter nie altyd groei nie; Die groei moet een of ander tyd eindig. Dus, wanneer eindig die stuurkoers? Slow-start eindig gewoonlik die toename in die stuurtempo op een van verskillende maniere:
Die eerste manier is die geval van pakkieverlies tydens die stuurproses van Slow Start. Wanneer 'n pakkieverlies plaasvind, stel TCP die opeenhopingsvenster van die sender op 1 op 1 en begin die stadige beginproses weer. Op hierdie punt word 'n konsep van stadige begindrempel SSTHRESH bekendgestel, waarvan die aanvanklike waarde die helfte van die waarde van CWND is wat pakkieverlies genereer. Dit wil sê wanneer opeenhoping opgespoor word, is die waarde van SSTHRESH die helfte van die raamwaarde.
Die tweede manier is om direk te korreleer met die waarde van die stadige startdrempel SSTHRESH. Aangesien die waarde van SSTHRESH die helfte van die raamwaarde is wanneer opeenhoping opgespoor word, kan pakkieverlies voorkom by elke verdubbeling wanneer CWND groter is as SSTHRESH. Daarom is dit die beste om CWND op SSThresh te stel, wat veroorsaak dat TCP oorgaan na die opeenhopingsmodus en die stadige begin.
Die laaste manier dat Slow Start kan eindig, is as drie oortollige ACK's opgespoor word, TCP 'n vinnige heruitsending uitvoer en die hersteltoestand betree. (As dit nie duidelik is waarom daar drie ACK -pakkies is nie, sal dit afsonderlik in die heruitsendingsmeganisme verduidelik word.)
Vermyding van opeenhoping
Wanneer TCP die opeenhopingsbeheerstoestand binnekom, is CWND ingestel op die helfte van die opeenhopingsdrempel SSTHRESH. Dit beteken dat die waarde van CWND nie verdubbel kan word elke keer as 'n pakketegment ontvang word nie. In plaas daarvan word 'n relatiewe konserwatiewe benadering aangeneem waarin die waarde van CWND met slegs een MSS (maksimum pakketegmentlengte) verhoog word nadat elke transmissie voltooi is. Byvoorbeeld, selfs al word 10 pakkiesegmente erken, sal die waarde van CWND slegs met een MSS toeneem. Dit is 'n lineêre groeimodel en dit het ook 'n boonste grens van groei. Wanneer pakketverlies plaasvind, word die waarde van CWND verander na 'n MSS, en die waarde van SSTHRESH is op die helfte van CWND gestel. Of dit sal ook die groei van MSS stop wanneer 3 oortollige ACK -reaksies ontvang word. As drie oortollige ACK's nog steeds ontvang word na die halvering van die waarde van CWND, word die waarde van SSTHRESH aangeteken as die helfte van die waarde van CWND en word die vinnige hersteltoestand ingevoer.
Vinnige herstel
In die vinnige hersteltoestand word die waarde van die opeenhopingsvenster CWND verhoog met een MSS vir elke ontvangde oortollige ACK, dit wil sê ACK wat nie in volgorde kom nie. Dit is om gebruik te maak van die pakketegmente wat suksesvol in die netwerk oorgedra is om die transmissie -doeltreffendheid soveel as moontlik te verbeter.
As 'n ACK van die verlore pakketegment opdaag, verlaag TCP die waarde van CWND en betree dit dan die vermyding van opeenhoping. Dit is om die grootte van die opeenhopingsvenster te beheer en te voorkom dat die netwerkopeenhopings verder verhoog word.
As 'n time-out plaasvind na die opeenhopingsbeheerstoestand, word die netwerktoestand ernstiger en TCP migreer van die opeenhopingsvermydingstoestand na die stadig-begin-toestand. In hierdie geval is die waarde van die opeenhopingsvenster CWND ingestel op 1 MSS, die maksimum pakketegmentlengte, en die waarde van die stadige startdrempel SSTHRESH is ingestel op die helfte van CWND. Die doel hiervan is om die grootte van die opeenhopingsvenster weer te verhoog nadat die netwerk herstel het om die transmissietempo en die mate van netwerkopeenhopings te balanseer.
Opsomming
As 'n betroubare vervoerprotokol implementeer TCP betroubare vervoer volgens volgorde, erkenning, heruitsendingsbeheer, verbindingsbestuur en vensterbeheer. Onder hulle beheer die vloeibeheermeganisme die hoeveelheid data wat deur die sender gestuur is volgens die werklike ontvangvermoë van die ontvanger, wat die probleme van netwerkopeenhopings en prestasie -agteruitgang vermy. Die opeenhopingsbeheermeganisme vermy die voorkoms van netwerkopeenhoping deur die hoeveelheid data wat deur die sender gestuur is, aan te pas. Die konsepte van die opeenhopingsvenster en die stuurvenster hou verband met mekaar, en die hoeveelheid data by die sender word beheer deur die grootte van die opeenhopingsvenster dinamies aan te pas. Stadige begin, vermyding van opeenhoping en vinnige herstel is die drie belangrikste dele van die TCP -opeenhopingsbeheer -algoritme, wat die grootte van die opeenhopingsvenster deur verskillende strategieë aanpas om aan te pas by die kapasiteit en opeenhoping van die netwerk.
In die volgende afdeling ondersoek ons die heruitsendingsmeganisme van TCP in detail. Die heruitsendingsmeganisme is 'n belangrike deel van TCP om betroubare oordrag te bewerkstellig. Dit verseker die betroubare oordrag van data deur die verlore, beskadigde of vertraagde data weer te gee. Die implementeringsbeginsel en strategie van die heruitsendingsmeganisme word in die volgende afdeling bekendgestel en in detail ontleed. Bly ingeskakel!
Postyd: Februarie 24-2025
