TCP -pålitelighetstransport
Vi er alle kjent med TCP -protokoll som en pålitelig transportprotokoll, men hvordan sikrer det påliteligheten til transport?
For å oppnå pålitelig overføring, må mange faktorer vurderes, for eksempel datakorrupsjon, tap, duplisering og skår uten ordre. Hvis disse problemene ikke kan løses, kan ikke pålitelig overføring oppnås.
Derfor benytter TCP mekanismer som sekvensnummer, kvitteringssvar, send kontroll, tilkoblingsstyring og vinduskontroll for å oppnå pålitelig overføring.
I denne artikkelen vil vi fokusere på skyvevinduet, strømningskontroll og overbelastningskontroll av TCP. Overføringsmekanismen er dekket separat i neste avsnitt.
Nettverksstrømkontroll
Nettverksflytkontroll eller kjent som nettverkstrafikkontroll er faktisk en manifestasjon av det subtile forholdet mellom produsenter og forbrukere. Du har sannsynligvis kommet over dette scenariet mye på jobben eller i intervjuer. Hvis produsentens kapasitet til å produsere overstiger forbrukerens kapasitet til å konsumere, vil det føre til at køen vokser på ubestemt tid. I et mer alvorlig tilfelle kan du kanskje vite at når RabbitMQ -meldinger hoper seg opp for mye, kan det føre til ytelsesnedbrytning av hele MQ -serveren. Det samme er tilfelle for TCP; Hvis det ikke blir sjekket, vil det bli lagt for mange meldinger i nettverket, og forbrukerne vil ha overskredet kapasiteten deres, mens produsentene vil fortsette å sende dupliserte meldinger, noe som vil påvirke ytelsen til nettverket i stor grad.
For å adressere dette fenomenet, gir TCP en mekanisme for avsenderen for å kontrollere mengden data som er sendt basert på den faktiske mottakskapasiteten til mottakeren, som er kjent som flytkontroll. Mottakeren opprettholder et mottaksvindu, mens avsenderen opprettholder et sendingsvindu. Det skal bemerkes at disse vinduene bare er for en enkelt TCP -tilkobling og ikke alle tilkoblinger deler et vindu.
TCP gir flytkontroll ved å bruke en variabel for et mottaksvindu. Mottaksvinduet gir avsenderen en indikasjon på hvor mye cache -plass som fremdeles er tilgjengelig. Avsenderen kontrollerer mengden data som er sendt i henhold til mottakerens faktiske akseptkapasitet.
Mottakerverten varsler avsenderen om størrelsen på dataene den kan motta, og avsenderen sender opp til denne grensen. Denne grensen er vindusstørrelsen, husker du TCP -overskriften? Det er et mottaksvindufelt, som brukes til å indikere antall byte mottakeren er i stand til eller villig til å motta.
Avsenderverten vil med jevne mellomrom sende en vinduskondepakke, som brukes til å oppdage om mottakerverten fremdeles er i stand til å godta data. Når mottakerens buffer står i fare for å overfylte, settes vindusstørrelsen til en mindre verdi for å instruere avsenderen om å kontrollere datamengden som sendes.
Her er et nettverksstrømkontrolldiagram:
Nettverkstettingskontroll
Før vi introduserer overbelastningskontroll, må vi forstå at i tillegg til mottaksvinduet og sendingsvinduet, er det også et overbelastningsvindu, som hovedsakelig brukes til å løse problemet med hvilken hastighet avsenderen begynner å sende data til mottaksvinduet. Derfor opprettholdes også overbelastningsvinduet av TCP -avsenderen. Vi trenger en algoritme for å bestemme hvor mye data som er passende å sende, siden det å sende for lite eller for mye data ikke er ideelt, derav konseptet med et overbelastningsvindu.
I den forrige nettverksflytkontrollen var det vi unngikk at avsenderen fylte mottakerens hurtigbuffer med data, men vi visste ikke hva som skjedde i nettverket. Vanligvis er datanettverk i et delt miljø. Som et resultat kan det være nettverkstetting på grunn av kommunikasjon mellom andre verter.
Når nettverket er overbelastet, kan det fortsette et stort antall pakker, hvis et stort antall pakker blir sendt, noe som forsinkelse og tap av pakker. På dette tidspunktet vil TCP overføre dataene, men overføringen vil øke belastningen på nettverket, noe som resulterer i større forsinkelser og mer pakketap. Dette kan komme inn i en ondskapsfull syklus og fortsette å bli større.
Dermed kan ikke TCP ignorere hva som skjer i nettverket. Når nettverket er overbelastet, ofrer TCP seg ved å redusere datamengden det sender.
Derfor foreslås overbelastningskontroll, som tar sikte på å unngå å fylle hele nettverket med data fra avsenderen. For å regulere datamengden avsenderen skal sende, definerer TCP et konsept som kalles overbelastningsvinduet. Overbelastningskontrollalgoritmen vil justere størrelsen på overbelastningsvinduet i henhold til overbelastningsgraden av nettverket, for å kontrollere datamengden som sendes av avsenderen.
Hva er et overbelastningsvindu? Hva har dette å gjøre med Send -vinduet?
Overbelastningsvinduet er en tilstandsvariabel vedlikeholdt av avsenderen som bestemmer datamengden avsenderen kan sende. Overbelastningsvinduet endres dynamisk i henhold til overbelastningsnivået i nettverket.
Sendingsvinduet er en avtalt vindusstørrelse mellom avsenderen og mottakeren som indikerer datamengden mottakeren kan motta. Overbelastningsvinduet og sendingsvinduet er relatert; Sendingsvinduet er vanligvis lik minimum av overbelastning og mottakende vinduer, det vil si SWND = min (CWND, RWND).
Overbelastningsvinduet CWND endres som følger:
Hvis det ikke er noen overbelastning i nettverket, dvs. ingen timeout for overføring, øker overbelastningsvinduet.
Hvis det er overbelastning i nettverket, avtar overbelastningsvinduet.
Avsenderen avgjør om nettverket er overbelastet ved å observere om ACK -kvitteringspakken mottas innen den spesifiserte tiden. Hvis avsenderen ikke mottar ACK -godkjenningspakken innen den angitte tiden, anses det at nettverket er overbelastet.
I tillegg til overbelastningsvinduet, er det på tide å diskutere TCP -overbelastningskontrollalgoritmen. TCP -overbelastningskontrollalgoritme består av tre hoveddeler:
Sakte start:Opprinnelig er CWND -overbelastningsvinduet relativt lite, og avsenderen øker overbelastningsvinduet eksponentielt for å raskt tilpasse seg kapasiteten til nettverket.
Overbelastnings unngåelse:Etter at overbelastningsvinduet overstiger en viss terskel, øker avsenderen overbelastningsvinduet på en lineær måte for å bremse veksthastigheten i overbelastningsvinduet og unngå overbelastning av nettverket.
Rask gjenoppretting:Hvis overbelastning oppstår, halverer avsenderen overbelastningsvinduet og går inn i den raske utvinningstilstanden for å bestemme plasseringen av nettverksgjenoppretting gjennom de mottatte dupliserte ACK -ene, og fortsetter deretter å øke overbelastningsvinduet.
Sakte start
Når en TCP -tilkobling er etablert, settes overbelastningsvinduet CWND opprinnelig til en minimum MSS -verdi (maksimal segmentstørrelse). På denne måten handler den første sendingsraten om MSS/RTT -byte/sekund. Den faktiske tilgjengelige båndbredden er vanligvis mye større enn MSS/RTT, så TCP ønsker å finne den optimale sendingsfrekvensen, som kan oppnås ved hjelp av sakte-start.
I den langsomme startprosessen vil verdien av overbelastningsvinduet CWND bli initialisert til 1 MSS, og hver gang det overførte pakkesegmentet erkjennes, vil verdien av CWND bli økt med en MSS, det vil si verdien av CWND vil bli 2 MSS. Etter det dobles verdien av CWND for hver vellykket overføring av et pakkesegment, og så videre. Den spesifikke vekstprosessen er vist i følgende figur.
Sendingsfrekvensen kan imidlertid ikke alltid vokse; Veksten må ende en gang. Så når øker sendingsrenten? Sakte start avslutter vanligvis økningen i sendingsrenten på en av flere måter:
Den første måten er tilfellet med pakketap under sendingsprosessen med langsom start. Når et pakketap oppstår, setter TCP avsenderens overbelastningsvindu CWND til 1 og starter langstartprosessen på nytt. På dette tidspunktet introduseres et konsept med langsom startterskel SSthresh, hvis startverdi er halvparten av verdien av CWND som genererer pakketap. Det vil si at når overbelastning oppdages, er verdien av SSthresh halvparten av vindusverdien.
Den andre måten er å direkte korrelere med verdien av sstart-sSthresh. Siden verdien av SSthresh er halvparten av vindusverdien når overbelastning oppdages, kan pakketap oppstå ved hver dobling når CWND er større enn SSthresh. Derfor er det best å sette CWND til SSthresh, noe som vil føre til at TCP går over til overbelastningskontrollmodus og avslutter sakte start.
Den siste måten langsom start kan ende er hvis tre overflødige ACK -er blir oppdaget, TCP utfører en rask overføring og går inn i utvinningstilstanden. (Hvis det ikke er klart hvorfor det er tre ACK -pakker, vil det bli forklart separat i overføringsmekanismen.)
Overbelastnings unngåelse
Når TCP kommer inn i overbelastningskontrolltilstanden, er CWND satt til halvparten av overbelastningsgrensen SSthresh. Dette betyr at verdien av CWND ikke kan dobles hver gang et pakkesegment mottas. I stedet blir en relativt konservativ tilnærming tatt i bruk der verdien av CWND økes med bare en MSS (maksimal pakkesegmentlengde) etter at hver overføring er fullført. Selv om 10 pakkesegmenter erkjennes for eksempel, vil verdien av CWND bare øke med en MSS. Dette er en lineær vekstmodell, og den har også en øvre grense for vekst. Når pakketap oppstår, endres verdien av CWND til en MSS, og verdien av sSthresh settes til halvparten av CWND. Eller det vil også stoppe veksten av MSS når 3 overflødige ACK -svar mottas. Hvis tre overflødige ACK -er fremdeles mottas etter halvering av verdien av CWND, blir verdien av SSthresh registrert som halvparten av verdien av CWND og Fast Recovery State legges inn.
Rask gjenoppretting
I Fast Recovery State økes verdien av overbelastningsvinduet CWND med en MSS for hver mottatte overflødige ACK, det vil si ACK som ikke kommer i rekkefølge. Dette for å benytte seg av pakkesegmentene som har blitt overført i nettverket for å forbedre overføringseffektiviteten så mye som mulig.
Når en ACK av det tapte pakkesegmentet kommer, reduserer TCP verdien av CWND og går deretter inn i overbelastnings unngåelsestilstanden. Dette er for å kontrollere størrelsen på overbelastningsvinduet og unngå å øke nettverkstinnet ytterligere.
Hvis en timeout oppstår etter overbelastningskontrolltilstanden, blir nettverkstilstanden mer alvorlig og TCP migrerer fra overbelastnings unngåelsesstatus til langsomstartstaten. I dette tilfellet settes verdien av overbelastningsvinduet CWND til 1 MSS, den maksimale pakkesegmentlengden, og verdien av SSSthResh SSSth-sSSthes til halvparten av CWND. Hensikten med dette er å øke størrelsen på overbelastningsvinduet på nytt etter at nettverket har gjenopprettet for å balansere overføringshastigheten og graden av nettverkstang.
Sammendrag
Som en pålitelig transportprotokoll implementerer TCP pålitelig transport etter sekvensnummer, kvittering, overføringskontroll, tilkoblingsstyring og vinduskontroll. Blant dem kontrollerer strømningskontrollmekanismen mengden data som sendes av avsenderen i henhold til den faktiske mottakerkapasiteten til mottakeren, som unngår problemene med nettverkstetting og ytelsesnedbrytning. Overbelastningskontrollmekanismen unngår forekomst av nettverkstetting ved å justere datamengden som sendes av avsenderen. Konseptene med overbelastningsvindu og sendingsvindu er relatert til hverandre, og datamengden ved avsenderen styres ved å dynamisk justere størrelsen på overbelastningsvinduet. Sakte start, unngåelse av overbelastning og rask utvinning er de tre hoveddelene av TCP -overbelastningskontrollalgoritmen, som justerer størrelsen på overbelastningsvinduet gjennom forskjellige strategier for å tilpasse seg kapasiteten og overbelastningsgraden på nettverket.
I neste avsnitt vil vi undersøke TCPs overføringsmekanisme i detalj. Overføringsmekanisme er en viktig del av TCP for å oppnå pålitelig overføring. Det sikrer pålitelig overføring av data ved å overføre tapte, ødelagte eller forsinkede data. Implementeringsprinsippet og strategien til overføringsmekanismen vil bli introdusert og analysert i detalj i neste avsnitt. Følg med!
Post Time: Feb-24-2025
