TCP-tillförlitlighetstransport
Vi känner alla till TCP-protokollet som ett pålitligt transportprotokoll, men hur säkerställer det transportens tillförlitlighet?
För att uppnå tillförlitlig överföring måste många faktorer beaktas, såsom datakorruption, förlust, duplicering och felaktiga shards. Om dessa problem inte kan lösas kan inte tillförlitlig överföring uppnås.
Därför använder TCP mekanismer som sekvensnummer, bekräftelsesvar, återsändningskontroll, anslutningshantering och fönsterkontroll för att uppnå tillförlitlig överföring.
I den här artikeln kommer vi att fokusera på glidande fönster, flödeskontroll och överbelastningskontroll i TCP. Återöverföringsmekanismen behandlas separat i nästa avsnitt.
Nätverksflödeskontroll
Nätverksflödeskontroll eller Network Traffic Control är faktiskt en manifestation av det subtila förhållandet mellan producenter och konsumenter. Du har förmodligen stött på detta scenario ofta på jobbet eller i intervjuer. Om producentens produktionskapacitet vida överstiger konsumentens konsumtionskapacitet, kommer det att orsaka att kön växer i all oändlighet. I ett allvarligare fall kanske du vet att när RabbitMQ-meddelanden hopar sig för mycket, kan det orsaka prestandaförsämring för hela MQ-servern. Detsamma gäller för TCP; om det lämnas okontrollerat kommer för många meddelanden att skickas till nätverket, och konsumenterna kommer att ha överskridit sin kapacitet, medan producenterna fortsätter att skicka dubbla meddelanden, vilket i hög grad kommer att påverka nätverkets prestanda.
För att hantera detta fenomen tillhandahåller TCP en mekanism som gör det möjligt för sändaren att kontrollera mängden data som skickas baserat på mottagarens faktiska mottagningskapacitet, vilket kallas flödeskontroll. Mottagaren upprätthåller ett mottagningsfönster, medan sändaren upprätthåller ett sändningsfönster. Det bör noteras att dessa fönster endast är för en enda TCP-anslutning och att inte alla anslutningar delar ett fönster.
TCP tillhandahåller flödeskontroll genom att använda en variabel för ett mottagningsfönster. Mottagningsfönstret ger avsändaren en indikation på hur mycket cacheutrymme som fortfarande finns tillgängligt. Avsändaren styr mängden data som skickas enligt mottagarens faktiska acceptanskapacitet.
Mottagarvärden meddelar avsändaren om storleken på den data den kan ta emot, och avsändaren skickar upp till denna gräns. Denna gräns är fönsterstorleken, minns du TCP-rubriken? Det finns ett mottagningsfönsterfält som används för att ange antalet byte som mottagaren kan eller vill ta emot.
Sändarvärden skickar regelbundet ett fönsterprovningspaket, vilket används för att detektera om mottagarvärden fortfarande kan ta emot data. När mottagarens buffert riskerar att bli överfylld, sätts fönsterstorleken till ett mindre värde för att instruera avsändaren att kontrollera mängden data som skickas.
Här är ett diagram över nätverksflödeskontroll:
Kontroll av nätverksöverbelastning
Innan vi introducerar överbelastningskontroll måste vi förstå att förutom mottagningsfönstret och sändningsfönstret finns det också ett överbelastningsfönster, vilket huvudsakligen används för att lösa problemet med i vilken takt sändaren börjar skicka data till mottagningsfönstret. Därför underhålls även överbelastningsfönstret av TCP-sändaren. Vi behöver en algoritm för att avgöra hur mycket data som är lämpligt att skicka, eftersom det inte är idealiskt att skicka för lite eller för mycket data, därav konceptet med ett överbelastningsfönster.
I den tidigare flödeskontrollen för nätverk undvek vi att avsändaren fyllde mottagarens cache med data, men vi visste inte vad som hände i nätverket. Vanligtvis finns datornätverk i en delad miljö. Som ett resultat kan det bli nätverksöverbelastning på grund av kommunikation mellan andra värdar.
När nätverket är överbelastat, om ett stort antal paket fortsätter att skickas, kan det orsaka problem som fördröjningar och paketförlust. Vid denna tidpunkt kommer TCP att sända om data, men omsändningen kommer att öka belastningen på nätverket, vilket resulterar i större fördröjningar och fler paketförluster. Detta kan hamna i en ond cirkel som bara blir större.
Således kan TCP inte ignorera vad som händer i nätverket. När nätverket är överbelastat offrar TCP sig själv genom att minska mängden data det skickar.
Därför föreslås överbelastningskontroll, vilket syftar till att undvika att fylla hela nätverket med data från avsändaren. För att reglera mängden data som avsändaren ska skicka definierar TCP ett koncept som kallas överbelastningsfönstret. Överbelastningskontrollalgoritmen justerar storleken på överbelastningsfönstret i enlighet med nätverkets överbelastningsgrad, för att kontrollera mängden data som skickas av avsändaren.
Vad är ett överbelastningsfönster? Vad har detta med sändningsfönstret att göra?
Överbelastningsfönstret är en tillståndsvariabel som underhålls avsändaren och som bestämmer mängden data som avsändaren kan skicka. Överbelastningsfönstret ändras dynamiskt beroende på nätverkets överbelastningsnivå.
Sändningsfönstret är en överenskommen fönsterstorlek mellan sändare och mottagare som anger mängden data som mottagaren kan ta emot. Överbelastningsfönstret och sändningsfönstret är relaterade; sändningsfönstret är vanligtvis lika med minimum för överbelastnings- och mottagningsfönstret, det vill säga swnd = min(cwnd, rwnd).
Överbelastningsfönstret cwnd ändras enligt följande:
Om det inte finns någon överbelastning i nätverket, dvs. ingen timeout för återsändning inträffar, ökar överbelastningsfönstret.
Om det finns överbelastning i nätverket minskar överbelastningsfönstret.
Avsändaren avgör om nätverket är överbelastat genom att observera om ACK-bekräftelsepaketet tas emot inom den angivna tiden. Om avsändaren inte tar emot ACK-bekräftelsepaketet inom den angivna tiden anses nätverket vara överbelastat.
Utöver överbelastningsfönstret är det dags att diskutera TCP:s algoritm för överbelastningskontroll. TCP:s algoritm för överbelastningskontroll består av tre huvuddelar:
Långsam start:Initialt är cwnds överbelastningsfönster relativt litet, och sändaren ökar överbelastningsfönstret exponentiellt för att snabbt anpassa sig till nätverkets kapacitet.
Undvikande av trafikstockningar:Efter att överbelastningsfönstret överstiger ett visst tröskelvärde ökar sändaren överbelastningsfönstret linjärt för att bromsa tillväxttakten i överbelastningsfönstret och undvika överbelastning av nätverket.
Snabb återhämtning:Om överbelastning uppstår halverar avsändaren överbelastningsfönstret och går in i snabb återställning för att bestämma platsen för nätverksåterställningen via de mottagna dubbletter av bekräftelserna, och fortsätter sedan att öka överbelastningsfönstret.
Långsam start
När en TCP-anslutning upprättas ställs överbelastningsfönstret cwnd initialt in på ett minimalt MSS-värde (maximal segment size). På så sätt är den initiala sändningshastigheten ungefär MSS/RTT byte/sekund. Den faktiska tillgängliga bandbredden är vanligtvis mycket större än MSS/RTT, så TCP vill hitta den optimala sändningshastigheten, vilket kan uppnås med hjälp av långsam start.
I långsamstartsprocessen initieras värdet på överbelastningsfönstret cwnd till 1 MSS, och varje gång det överförda paketsegmentet bekräftas ökas värdet på cwnd med en MSS, det vill säga att värdet på cwnd blir 2 MSS. Därefter fördubblas värdet på cwnd för varje lyckad överföring av ett paketsegment, och så vidare. Den specifika tillväxtprocessen visas i följande figur.
Sändningshastigheten kan dock inte alltid öka; tillväxten måste ta slut någon gång. Så, när slutar ökningen av sändningshastigheten? En långsam start avslutar vanligtvis ökningen av sändningshastigheten på ett av flera sätt:
Det första sättet är fallet med paketförlust under sändningsprocessen med långsam start. När en paketförlust inträffar ställer TCP in avsändarens överbelastningsfönster cwnd till 1 och startar om den långsamma startprocessen. Vid denna tidpunkt introduceras ett koncept med tröskelvärdet ssthresh för långsam start, vars initialvärde är hälften av värdet på cwnd som genererar paketförlust. Det vill säga, när överbelastning detekteras är värdet på ssthresh hälften av fönstervärdet.
Det andra sättet är att direkt korrelera med värdet på tröskelvärdet för långsam start ssthresh. Eftersom värdet på ssthresh är hälften av fönstervärdet när överbelastning detekteras, kan paketförlust uppstå vid varje fördubbling när cwnd är större än ssthresh. Därför är det bäst att ställa in cwnd på ssthresh, vilket gör att TCP växlar till överbelastningskontrollläge och avslutar långsam start.
Det sista sättet en långsam start kan upphöra är om tre redundanta ACK-paket upptäcks, TCP utför en snabb återsändning och går in i återställningsläge. (Om det inte är tydligt varför det finns tre ACK-paket kommer det att förklaras separat i återsändningsmekanismen.)
Undvikande av trängsel
När TCP går in i tillståndet för överbelastningskontroll sätts cwnd till halva tröskelvärdet för överbelastning ssthresh. Detta innebär att värdet på cwnd inte kan fördubblas varje gång ett paketsegment tas emot. Istället används en relativt konservativ metod där värdet på cwnd ökas med endast en MSS (maximal paketsegmentlängd) efter att varje överföring är klar. Till exempel, även om 10 paketsegment bekräftas, kommer värdet på cwnd endast att öka med en MSS. Detta är en linjär tillväxtmodell och den har också en övre gräns för tillväxten. När paketförlust inträffar ändras värdet på cwnd till en MSS, och värdet på ssthresh sätts till hälften av cwnd. Eller så stoppas tillväxten av MSS när 3 redundanta ACK-svar tas emot. Om tre redundanta ACK-svar fortfarande tas emot efter att värdet på cwnd halverats, registreras värdet på ssthresh som hälften av värdet på cwnd och tillståndet för snabb återhämtning går in.
Snabb återhämtning
I läget Snabb återställning ökas värdet på överbelastningsfönstret cwnd med en MSS för varje mottagen redundant ACK, det vill säga ACK som inte anländer i sekvens. Detta är för att utnyttja de paketsegment som har sänts framgångsrikt i nätverket för att förbättra överföringseffektiviteten så mycket som möjligt.
När ett ACK för det förlorade paketsegmentet anländer, minskar TCP värdet på cwnd och går sedan in i tillståndet för att undvika överbelastning. Detta görs för att kontrollera storleken på överbelastningsfönstret och undvika att nätverksöverbelastningen ökar ytterligare.
Om en timeout inträffar efter överbelastningskontrolltillståndet blir nätverksförhållandena allvarligare och TCP migrerar från överbelastningsundvikande tillstånd till långsam starttillstånd. I detta fall sätts värdet för överbelastningsfönstret cwnd till 1 MSS, den maximala paketsegmentlängden, och värdet för långsam starttröskeln ssthresh sätts till hälften av cwnd. Syftet med detta är att gradvis öka storleken på överbelastningsfönstret efter att nätverket återhämtat sig för att balansera överföringshastigheten och graden av nätverksöverbelastning.
Sammanfattning
Som ett tillförlitligt transportprotokoll implementerar TCP tillförlitlig transport via sekvensnummer, bekräftelse, återutsändningskontroll, anslutningshantering och fönsterkontroll. Bland dessa styr flödeskontrollmekanismen mängden data som skickas av sändaren i enlighet med mottagarens faktiska mottagningskapacitet, vilket undviker problem med nätverksöverbelastning och prestandaförsämring. Överbelastningskontrollmekanismen undviker uppkomsten av nätverksöverbelastning genom att justera mängden data som skickas av sändaren. Begreppen överbelastningsfönster och sändningsfönster är relaterade till varandra, och mängden data hos sändaren styrs genom att dynamiskt justera storleken på överbelastningsfönstret. Långsam start, överbelastningsundvikande och snabb återhämtning är de tre huvuddelarna i TCP:s överbelastningskontrollalgoritm, som justerar storleken på överbelastningsfönstret genom olika strategier för att anpassa sig till nätverkets kapacitet och överbelastningsgrad.
I nästa avsnitt kommer vi att undersöka TCP:s återöverföringsmekanism i detalj. Återöverföringsmekanismen är en viktig del av TCP för att uppnå tillförlitlig överföring. Den säkerställer tillförlitlig överföring av data genom att återsända förlorad, korrupt eller försenad data. Implementeringsprincipen och strategin för återöverföringsmekanismen kommer att introduceras och analyseras i detalj i nästa avsnitt. Håll utkik!
Publiceringstid: 24 februari 2025
