TCP-omsändningen innebär att paketen som antingen har förlorats eller skadats skickas om via nätverket. Här är återsändning en mekanism som används av protokoll som t.ex TCP att tillhandahålla pålitlig kommunikation. Här innebär tillförlitlig kommunikation att protokollet garanterar paketleverans även om datapaketet har förlorats eller skadats.
linux mint cinnamon vs mate
Nätverken är opålitliga och garanterar inte förseningen eller återsändningen av de förlorade eller skadade paketen. Nätverket som använder en kombination av bekräftelse och återsändning av skadade eller förlorade paket erbjuder tillförlitlighet.
Återsändningsmekanism
Här innebär återsändning att datapaketen har gått förlorade, vilket leder till bristande bekräftelse. Denna brist på bekräftelse utlöser en timer till timeout, vilket leder till återsändning av datapaket. Här betyder timern att om ingen bekräftelse tas emot innan timern löper ut så återsänds datapaketet.
Låt oss överväga följande scenarier för återsändning.
Scenario 1: När datapaketet försvinner eller är felaktigt.
I detta scenario skickas paketet till mottagaren, men ingen bekräftelse tas emot inom den tidsgränsen. När timeoutperioden löper ut skickas paketet igen. När paketet återsänds tas bekräftelsen emot. När bekräftelsen väl har tagits emot kommer återsändning inte att ske igen.
Scenario 2: När paketet tas emot men bekräftelsen går förlorad.
I detta scenario tas paketet emot på den andra sidan, men bekräftelsen går förlorad, dvs. ACK tas inte emot på avsändarsidan. När timeoutperioden löper ut skickas paketet igen. Det finns två kopior av paketen på andra sidan; även om paketet tas emot korrekt, mottas inte bekräftelsen, så avsändaren återsänder paketet. I detta fall kunde återsändningen ha undvikits, men på grund av förlusten av ACK:n återsänds paketet.
Scenario 3: När den tidiga timeouten inträffar.
I det här scenariot skickas paketet, men på grund av fördröjningen i bekräftelse eller timeout har inträffat före den faktiska timeouten, sänds paketet om. I det här fallet har paketet skickats igen i onödan på grund av fördröjningen i bekräftelsen eller så har timeouten ställts in tidigare än den faktiska timeouten.
I ovanstående scenarier kan det första scenariot inte undvikas, men de andra två scenarierna kan undvikas. Låt oss se hur vi kan undvika dessa situationer.
Hur länge ska avsändaren vänta?
Avsändaren ställer in timeoutperioden för en ACK. Timeoutperioden kan vara av två typer:
För att övervinna de två ovanstående situationerna, TCP ställer in timeout som en funktion av RTT (tur- och returtid) där tur och retur är den tid som krävs för att paketet ska resa från källan till destinationen och sedan komma tillbaka igen.
Hur kan vi få RTT?
RTT kan variera beroende på nätets egenskaper, d.v.s. om nätet är överbelastat betyder det att RTT är mycket högt. Vi kan uppskatta RTT genom att helt enkelt titta på ACKs.
Låt oss se hur vi kan mäta RTT.
Vi kommer att använda den ursprungliga algoritmen för att mäta RTT.
Steg 1: Först mäter vi SampleRTT för varje segment eller ACK-par. När avsändaren skickar paketet, då vet vi timern vid vilken paketet skickas, och vi vet också timern vid vilken bekräftelse tas emot. Beräkna tiden mellan dessa två, och det blir SampleRTT .
Steg 2: Vi tar inte bara ett prov. Vi kommer att fortsätta att ta olika prover och beräkna det vägda medelvärdet av dessa prover, och detta blir EstRTT (Estimated RTT).
där α+ β = 1
α ligger mellan 0,8 och 0,9
string.valueof java
β ligger mellan 0,1 och 0,2
Steg 3: Timeout ställs in baserat på EstRTT.
java sort arraylist
timeout = 2 * EstRTT.
Timeouten är inställd på två gånger den beräknade RTT. Så här beräknas den faktiska timeoutfaktorn.
Ett fel i detta tillvägagångssätt
Det finns ett fel i den ursprungliga algoritmen. Låt oss överväga två scenarier.
Scenario 1.
Diagrammet ovan visar att avsändaren skickar data, vilket sägs vara en originalöverföring. Inom timeoutperioden tas ingen bekräftelse emot. Så avsändaren återsänder data. Efter återsändning av data tas bekräftelsen emot. Låt oss anta att bekräftelse tas emot för den ursprungliga sändningen, inte för återsändningen. Eftersom vi får erkännandet av den ursprungliga överföringen, så SampleRTT beräknas mellan tidpunkten för den ursprungliga sändningen och tidpunkten då bekräftelsen tas emot. Men faktiskt SampleRTT borde ha varit mellan tidpunkten för återsändningen och tidpunkten för bekräftelsen.
Scenario 2.
Diagrammet ovan visar att avsändaren skickar det ursprungliga datapaketet för vilket vi också får bekräftelsen. Men bekräftelsen tas emot efter återsändning av data. Om vi antar att bekräftelsen hör till återsändningen, då SampleRTT beräknas mellan tidpunkten för återsändningen och tidpunkten för bekräftelsen.
I båda scenarierna ovan finns det en tvetydighet att inte veta om bekräftelsen är för den ursprungliga sändningen eller för återsändningen.
Slutsats av ovanstående algoritm.
- Här betyder ACK inte att kvittera en överföring, utan faktiskt bekräftar det ett mottagande av data.
- Om vi betraktar det första scenariot görs omsändningen för det förlorade paketet. I det här fallet antar vi att ACK tillhör den ursprungliga överföringen på grund av vilken SampleRTT kommer att bli mycket stor.
- Om vi betraktar det andra scenariot, skickas två samma paket så dubbelt uppstår i detta fall. I det här fallet antar vi att ACK tillhör återsändningen på grund av vilken SampleRTT kommer att bli mycket liten.
För att övervinna ovanstående problem ges en enkel lösning av Karn/Partridge-algoritmen. Denna algoritm gav en enkel lösning som samlar in de sampel som sänts på en gång och inte tar hänsyn till proverna vid återsändningstiden för att beräkna den uppskattade RTT.
Karn/Partridge Algoritm
I ovanstående två scenarier sker återsändning, och vi har övervägt provet RTT. Men denna algoritm tar inte hänsyn till Sample RTT vid återsändning. Sedan återsändningen har skett, vilket betyder att något händer under denna tur och retur eller att det kan uppstå någon överbelastning i ett nätverk. För att övervinna detta problem fördubblar denna algoritm timeouten efter varje återsändning. Denna algoritm är implementerad i TCP-nätverket.
Begränsning
java undantag
Den tar inte hänsyn till variansen i RTT.
För att övervinna ovanstående begränsning utvecklades Jacobson/Karels-algoritmen som introducerar variansfaktorn i RTT.
Jacobson/Karels algoritm
Denna algoritm utvecklades för att övervinna begränsningen av Karn/Partridge algoritm. Den beräknar skillnaden mellan SampleRTT och EstimatedRTT, och ökar RTT baserat på skillnaden.
Beräkningar för genomsnittlig RTT
- Först beräknar vi skillnadsfaktorn.
Diff = SampleRTT - EstimatedRTT
- Nu beräknar vi EstimatedRTT, som kommer att beräknas på samma sätt som vi gjorde ovan.
EstRTT = EstRTT + (δ*Diff)
- Nu beräknar vi medelvärdet av skillnadsfaktorn.
Dev = Dev + δ ( |Diff| - Dev)
Här är Dev en avvikelsefaktor och δ är en faktor mellan 0 och 1. The Dev är en uppskattning av variansen från EstRTT .
- Vi tar hänsyn till variansen när vi beräknar timeoutvärdet.
Var, µ =1 och ɸ =4
Snabb återsändning
Den timeoutbaserade strategin för återsändning är ineffektiv. TCP är ett protokoll för skjutbara fönster, så närhelst omsändningen sker börjar den skicka det från det förlorade paketet och framåt.
Antag att jag sänder paketen 0, 1, 2 och 3. Eftersom paket 0 och paket 1 tas emot på andra sidan, förloras paket 2 i ett nätverk. Jag har fått bekräftelsen av paket 0 och paket 1, så jag skickar två paket till, dvs paket 4 och paket 5. När paket 3, 4 och 5 skickas, kommer jag att få bekräftelsen av paket 1 som TCP-bekräftelser är kumulativa, så den bekräftar upp till paketet att den har tagit emot i ordning. Jag har inte fått bekräftelsen på paket 2, 3, 4 och 5 inom timeoutperioden, så jag återsänder paketen 2, 3, 4 och 5. Eftersom paket 2 är förlorat, men andra paket, dvs. 3, 4 ,5 tas emot på andra sidan, sänds de fortfarande om på grund av denna timeout-mekanism.
Hur kan denna timeout-ineffektivitet tas bort?
Den bättre lösningen under ett skjutfönster:
Antag att n paket har gått förlorade, men ändå har paketen n+1, n+2 och så vidare tagits emot. Mottagaren tar kontinuerligt emot paketen och skickar ACK-paketen och säger att mottagaren fortfarande väntar på det n:te paketet. Mottagaren skickar upprepade eller duplicerade bekräftelser. I ovanstående fall skickas ACK för paket 1 tre gånger eftersom paket 2 har gått förlorat. Detta duplicerade ACK-paket är en indikation på att det n:te paketet saknas, men att de senare paketen tas emot.
Ovanstående situation kan lösas på följande sätt:
- Avsändaren kan ta 'dubbletter av ACK' som en tidig hint om att det n:te paketet har gått förlorat så att avsändaren kan göra omsändningen så tidigt som möjligt, d.v.s. avsändaren bör inte vänta tills timeout inträffar.
- Avsändaren kan implementera en strategi för snabb överföring i TCP. I en strategi för snabb överföring bör avsändaren betrakta de tredubbla ACK:erna som en utlösare och återsända den.
TCP använder tre dubbletter av ACK som utlösare och utför sedan omsändning. I ovanstående fall, när tre ACK av paket 1 tas emot, bör avsändaren skicka det förlorade paketet, dvs paket 2, utan att vänta på att timeoutperioden inträffar.
primär nyckel sammansatt nyckel