TCP-pålitelighetstransport
Vi er alle kjent med TCP-protokollen som en pålitelig transportprotokoll, men hvordan sikrer den påliteligheten til transporten?
For å oppnå pålitelig overføring må mange faktorer vurderes, som datakorrupsjon, tap, duplisering og feilaktige shards. Hvis disse problemene ikke kan løses, kan ikke pålitelig overføring oppnås.
Derfor bruker TCP mekanismer som sekvensnummer, bekreftelsessvar, sendingskontroll, tilkoblingsadministrasjon og vinduskontroll for å oppnå pålitelig overføring.
I denne artikkelen vil vi fokusere på glidevinduet, flytkontrollen og overbelastningskontrollen til TCP. Retransmisjonsmekanismen dekkes separat i neste avsnitt.
Nettverksflytkontroll
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å jobb eller i intervjuer. Hvis produsentens produksjonskapasitet i stor grad overstiger forbrukerens forbrukskapasitet, vil det føre til at køen vokser i det uendelige. I et mer alvorlig tilfelle vet du kanskje at når RabbitMQ-meldinger hoper seg opp for mye, kan det føre til ytelsesforringelse for hele MQ-serveren. Det samme gjelder for TCP; hvis det ikke kontrolleres, vil for mange meldinger bli lagt inn i nettverket, og forbrukerne vil ha overskredet kapasiteten sin, mens produsentene vil fortsette å sende dupliserte meldinger, noe som i stor grad vil påvirke nettverkets ytelse.
For å håndtere dette fenomenet tilbyr TCP en mekanisme som senderen kan bruke til å kontrollere mengden data som sendes basert på mottakerens faktiske mottakskapasitet, kjent som flytkontroll. Mottakeren opprettholder et mottaksvindu, mens senderen opprettholder et sendevindu. Det bør bemerkes at disse vinduene kun er for én 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 fortsatt er tilgjengelig. Avsenderen kontrollerer mengden data som sendes i henhold til mottakerens faktiske akseptkapasitet.
Mottakerverten varsler avsenderen om størrelsen på dataene den kan motta, og avsenderen sender opptil denne grensen. Denne grensen er vindusstørrelsen, husker du TCP-headeren? Det finnes et mottaksvindufelt, som brukes til å angi antall byte mottakeren er i stand til eller villig til å motta.
Avsenderverten sender med jevne mellomrom en vindusprøvepakke, som brukes til å oppdage om mottakerverten fortsatt kan motta data. Når mottakerens buffer er i fare for å bli overfylt, settes vindusstørrelsen til en mindre verdi for å instruere avsenderen til å kontrollere mengden data som sendes.
Her er et diagram for nettverksflytkontroll:
Kontroll av nettverksbelastning
Før vi introduserer overbelastningskontroll, må vi forstå at i tillegg til mottaksvinduet og sendevinduet, finnes det også et overbelastningsvindu, som hovedsakelig brukes til å løse problemet med hvilken hastighet senderen begynner å sende data til mottaksvinduet. Derfor vedlikeholdes også overbelastningsvinduet av TCP-senderen. Vi trenger en algoritme for å bestemme hvor mye data som er passende å sende, siden det ikke er ideelt å sende for lite eller for mye data, derav konseptet med et overbelastningsvindu.
I den forrige nettverksflytkontrollen unngikk vi at avsenderen fylte mottakerens hurtigbuffer med data, men vi visste ikke hva som skjedde i nettverket. Datanettverk er vanligvis i et delt miljø. Som et resultat kan det være nettverksbelastning på grunn av kommunikasjon mellom andre verter.
Når nettverket er overbelastet, og et stort antall pakker fortsetter å bli sendt, kan det føre til problemer som forsinkelser og tap av pakker. På dette tidspunktet vil TCP sende dataene på nytt, men reoverføringen vil øke belastningen på nettverket, noe som resulterer i større forsinkelser og flere pakketap. Dette kan havne i en ond sirkel som bare blir større.
Dermed kan ikke TCP ignorere hva som skjer på nettverket. Når nettverket er overbelastet, ofrer TCP seg selv ved å redusere mengden data det sender.
Derfor foreslås det overbelastningskontroll, som har som mål å unngå å fylle hele nettverket med data fra avsenderen. For å regulere mengden data avsenderen skal sende, definerer TCP et konsept som kalles overbelastningsvinduet. Overbelastningskontrollalgoritmen vil justere størrelsen på overbelastningsvinduet i henhold til nettverkets overbelastningsgrad, for å kontrollere mengden data som sendes av avsenderen.
Hva er et overbelastningsvindu? Hva har dette med sendevinduet å gjøre?
Overbelastningsvinduet er en tilstandsvariabel som vedlikeholdes av avsenderen og som bestemmer mengden data avsenderen kan sende. Overbelastningsvinduet endres dynamisk i henhold til nettverkets overbelastningsnivå.
Sendevinduet er en avtalt vindusstørrelse mellom sender og mottaker som angir mengden data mottakeren kan motta. Overbelastningsvinduet og sendevinduet er relaterte; sendevinduet er vanligvis lik minimum av overbelastnings- og mottaksvinduet, det vil si swnd = min(cwnd, rwnd).
Overbelastningsvinduet cwnd endres som følger:
Hvis det ikke er noen overbelastning i nettverket, dvs. at det ikke oppstår noen tidsavbrudd for retransmisjon, øker overbelastningsvinduet.
Hvis det er overbelastning i nettverket, reduseres overbelastningsvinduet.
Avsenderen avgjør om nettverket er overbelastet ved å observere om ACK-bekreftelsespakken mottas innen den angitte tiden. Hvis avsenderen ikke mottar ACK-bekreftelsespakken innen den angitte tiden, anses det at nettverket er overbelastet.
I tillegg til overbelastningsvinduet er det på tide å diskutere TCP-algoritmen for overbelastningskontroll. TCP-algoritmen for overbelastningskontroll består av tre hoveddeler:
Treg start:I utgangspunktet er cwnd-overbelastningsvinduet relativt lite, og avsenderen øker overbelastningsvinduet eksponentielt for raskt å tilpasse seg nettverkets kapasitet.
Unngåelse av trafikkork:Etter at overbelastningsvinduet overstiger en viss terskel, øker avsenderen overbelastningsvinduet lineært for å bremse vekstraten i overbelastningsvinduet og unngå overbelastning av nettverket.
Rask gjenoppretting:Hvis det oppstår overbelastning, halverer avsenderen overbelastningsvinduet og går inn i tilstanden for rask gjenoppretting for å bestemme plasseringen av nettverksgjenopprettingen gjennom de mottatte duplikatbekreftelsene, og fortsetter deretter å øke overbelastningsvinduet.
Treg start
Når en TCP-forbindelse opprettes, settes overbelastningsvinduet cwnd i utgangspunktet til en minimumsverdi for MSS (maksimal segmentstørrelse). På denne måten er den innledende sendehastigheten omtrent MSS/RTT byte/sekund. Den faktiske tilgjengelige båndbredden er vanligvis mye større enn MSS/RTT, så TCP ønsker å finne den optimale sendehastigheten, som kan oppnås ved hjelp av saktestart.
I den langsomme startprosessen vil verdien av overbelastningsvinduet cwnd bli initialisert til 1 MSS, og hver gang det overførte pakkesegmentet bekreftes, vil verdien av cwnd økes med én MSS, det vil si at verdien av cwnd blir 2 MSS. Deretter dobles verdien av cwnd for hver vellykket overføring av et pakkesegment, og så videre. Den spesifikke vekstprosessen er vist i figuren nedenfor.
Sendehastigheten kan imidlertid ikke alltid vokse; veksten må ta slutt en gang. Så når slutter økningen i sendehastigheten? En langsom start avslutter vanligvis økningen i sendehastigheten på en av flere måter:
Den første måten er tilfellet med pakketap under sendeprosessen med langsom start. Når et pakketap oppstår, setter TCP avsenderens overbelastningsvindu cwnd til 1 og starter den langsomme startprosessen på nytt. På dette tidspunktet introduseres et konsept med langsom startterskel ssthresh, hvis startverdi er halvparten av verdien til cwnd som genererer pakketap. Det vil si at når overbelastning oppdages, er verdien til ssthresh halvparten av vindusverdien.
Den andre måten er å korrelere direkte med verdien av ssthresh-terskelen for langsom start. Siden verdien av ssthresh er halvparten av vindusverdien når det oppdages overbelastning, 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 bytter til overbelastningskontrollmodus og avslutter langsom start.
Den siste måten en treg start kan opphøre på er hvis tre redundante ACK-pakker oppdages. TCP utfører en rask retransmisjon og går inn i gjenopprettingstilstand. (Hvis det ikke er klart hvorfor det er tre ACK-pakker, vil det bli forklart separat i retransmisjonsmekanismen.)
Unngåelse av trafikkork
Når TCP går inn i tilstanden «congestion control» (kontroll av overbelastning), settes cwnd til halvparten av overbelastningsterskelen ssthresh. Dette betyr at verdien av cwnd ikke kan dobles hver gang et pakkesegment mottas. I stedet benyttes en relativt konservativ tilnærming der verdien av cwnd økes med bare én MSS (maksimal pakkesegmentlengde) etter at hver overføring er fullført. For eksempel, selv om 10 pakkesegmenter bekreftes, vil verdien av cwnd bare øke med én 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 den vil også stoppe veksten av MSS når 3 redundante ACK-svar mottas. Hvis tre redundante ACK-svar fortsatt mottas etter at verdien av cwnd er halvert, registreres verdien av ssthresh som halvparten av verdien av cwnd, og tilstanden «rask gjenoppretting» går inn.
Rask gjenoppretting
I tilstanden Fast Recovery økes verdien av overbelastningsvinduet cwnd med én MSS for hver mottatt redundant ACK, det vil si ACK som ikke ankommer i rekkefølge. Dette er for å utnytte pakkesegmentene som har blitt overført i nettverket for å forbedre overføringseffektiviteten så mye som mulig.
Når en bekreftelse på det tapte pakkesegmentet ankommer, reduserer TCP verdien av cwnd og går deretter inn i tilstanden for å unngå overbelastning. Dette er for å kontrollere størrelsen på overbelastningsvinduet og unngå ytterligere økning av nettverksbelastningen.
Hvis det oppstår en tidsavbrudd etter at trafikkbelastningskontrolltilstanden er nådd, blir nettverkstilstanden mer alvorlig, og TCP migrerer fra trafikkbelastningsunngåelsestilstanden til langsom starttilstand. I dette tilfellet settes verdien av trafikkbelastningsvinduet cwnd til 1 MSS, den maksimale pakkesegmentlengden, og verdien av langsom startterskelen ssthresh settes til halvparten av cwnd. Formålet med dette er å gradvis øke størrelsen på trafikkbelastningsvinduet etter at nettverket har gjenopprettet seg for å balansere overføringshastigheten og graden av nettverksbelastning.
Sammendrag
Som en pålitelig transportprotokoll implementerer TCP pålitelig transport via sekvensnummer, bekreftelse, retransmisjonskontroll, tilkoblingsadministrasjon og vinduskontroll. Blant disse kontrollerer flytkontrollmekanismen mengden data som sendes av senderen i henhold til mottakerens faktiske mottakskapasitet, noe som unngår problemer med nettverksbelastning og ytelsesforringelse. Overbelastningskontrollmekanismen unngår forekomsten av nettverksbelastning ved å justere mengden data som sendes av senderen. Konseptene overbelastningsvindu og sendevindu er relatert til hverandre, og mengden data hos senderen kontrolleres ved dynamisk å justere størrelsen på overbelastningsvinduet. Langsom start, unngåelse av overbelastning og rask gjenoppretting er de tre hoveddelene av TCP-overbelastningskontrollalgoritmen, som justerer størrelsen på overbelastningsvinduet gjennom ulike strategier for å tilpasse seg nettverkets kapasitet og overbelastningsgrad.
I neste avsnitt skal vi undersøke TCPs retransmisjonsmekanisme i detalj. Retransmisjonsmekanismen er en viktig del av TCP for å oppnå pålitelig overføring. Den sikrer pålitelig overføring av data ved å retransmittere tapte, ødelagte eller forsinkede data. Implementeringsprinsippet og strategien for retransmisjonsmekanismen vil bli introdusert og analysert i detalj i neste avsnitt. Følg med!
Publisert: 24. feb. 2025
