TCP-reoverføring betyr å sende pakkene på nytt over nettverket som enten har gått tapt eller skadet. Her er retransmission en mekanisme som brukes av protokoller som f.eks TCP å gi pålitelig kommunikasjon. Her betyr pålitelig kommunikasjon at protokollen garanterer pakkens levering selv om datapakken har gått tapt eller skadet.
streng til jsonobject
Nettverkene er upålitelige og garanterer ikke forsinkelse eller reoverføring av tapte eller skadede pakker. Nettverket som bruker en kombinasjon av bekreftelse og reoverføring av skadede eller tapte pakker tilbyr pålitelighet.
Gjenoverføringsmekanisme
Her betyr retransmission at datapakkene har gått tapt, noe som fører til manglende bekreftelse. Denne mangelen på bekreftelse utløser en tidtaker til tidsavbrudd, noe som fører til reoverføring av datapakker. Her betyr timeren at hvis ingen bekreftelse mottas før timeren utløper, blir datapakken sendt på nytt.
La oss vurdere følgende scenarier for retransmisjon.
Scenario 1: Når datapakken går tapt eller er feil.
I dette scenariet sendes pakken til mottakeren, men ingen bekreftelse mottas innen den tidsavbruddsperioden. Når tidsavbruddsperioden utløper, sendes pakken på nytt igjen. Når pakken sendes på nytt, mottas bekreftelsen. Når bekreftelsen er mottatt, vil ikke reoverføring skje igjen.
Scenario 2: Når pakken er mottatt, men bekreftelsen er tapt.
I dette scenariet mottas pakken på den andre siden, men bekreftelsen går tapt, dvs. ACK mottas ikke på avsendersiden. Når tidsavbruddsperioden utløper, sendes pakken på nytt. Det er to kopier av pakkene på den andre siden; Selv om pakken mottas riktig, mottas ikke bekreftelsen, så avsenderen sender pakken på nytt. I dette tilfellet kunne retransmisjonen vært unngått, men på grunn av tapet av ACK blir pakken sendt på nytt.
Scenario 3: Når den tidlige tidsavbruddet inntreffer.
I dette scenariet sendes pakken, men på grunn av forsinkelsen i bekreftelsen eller tidsavbruddet har oppstått før den faktiske tidsavbruddet, blir pakken sendt på nytt. I dette tilfellet har pakken blitt sendt på nytt unødvendig på grunn av forsinkelsen i bekreftelsen eller tidsavbruddet er satt tidligere enn det faktiske tidsavbruddet.
I scenariene ovenfor kan ikke det første scenariet unngås, men de to andre scenariene kan unngås. La oss se hvordan vi kan unngå disse situasjonene.
Hvor lenge bør avsender vente?
Avsenderen angir tidsavbruddsperioden for en ACK. Tidsavbruddsperioden kan være av to typer:
For å overvinne de to ovennevnte situasjonene, TCP setter tidsavbruddet som en funksjon av RTT (tur-retur-tid) der rundturstid er tiden som kreves for at pakken skal reise fra kilden til destinasjonen og deretter komme tilbake igjen.
Hvordan kan vi få tak i RTT?
RTT kan variere avhengig av nettverkets egenskaper, dvs. hvis nettverket er overbelastet, betyr det at RTT er veldig høyt. Vi kan estimere RTT ved ganske enkelt å se på ACK-ene.
La oss se hvordan vi kan måle RTT.
Vi vil bruke original algoritme for å måle RTT.
Trinn 1: Først måler vi EksempelRTT for hvert segment eller ACK-par. Når avsenderen sender pakken, vet vi tidtakeren som pakken sendes ved, og vi vet også tidtakeren der bekreftelsen mottas. Beregn tiden mellom disse to, og det blir EksempelRTT .
Steg 2: Vi tar ikke bare én prøve. Vi vil fortsette å ta forskjellige prøver og beregne det vektede gjennomsnittet av disse prøvene, og dette blir EstRTT (Estimated RTT).
forekomst av i java
hvor, α+ β = 1
α ligger mellom 0,8 og 0,9
β ligger mellom 0,1 og 0,2
dhl betydning
Trinn 3: Tidsavbruddet er satt basert på EstRTT.
tidsavbrudd = 2 * EstRTT.
Tidsavbruddet er satt til å være to ganger estimert RTT. Slik beregnes den faktiske timeout-faktoren.
En feil i denne tilnærmingen
Det er en feil i den opprinnelige algoritmen. La oss vurdere to scenarier.
Scenario 1.
Diagrammet ovenfor viser at avsenderen sender dataene, som sies å være en original overføring. Innenfor tidsavbruddsperioden mottas ingen bekreftelse. Så senderen sender dataene på nytt. Etter at dataene er overført på nytt, mottas bekreftelsen. La oss anta at en bekreftelse mottas for den opprinnelige overføringen, ikke for reoverføringen. Siden vi får bekreftelsen av den opprinnelige overføringen, så EksempelRTT beregnes mellom tidspunktet for den opprinnelige overføringen og tidspunktet da bekreftelsen mottas. Men faktisk EksempelRTT skulle ha vært mellom tidspunktet for reoverføringen og tidspunktet for bekreftelsen.
Scenario 2.
Diagrammet ovenfor viser at avsenderen sender den originale datapakken som vi også får bekreftelsen for. Men bekreftelsen mottas etter at dataene er overført på nytt. Hvis vi antar at bekreftelsen hører til retransmisjonen, da EksempelRTT beregnes mellom tidspunktet for videresending og tidspunktet for bekreftelsen.
I de ovennevnte begge scenariene er det en tvetydighet å ikke vite om bekreftelsen er for den opprinnelige overføringen eller for reoverføringen.
Konklusjon av algoritmen ovenfor.
jdbc jdbc
- Her betyr ACK ikke å bekrefte en overføring, men faktisk bekrefter det en mottak av dataene.
- Hvis vi vurderer det første scenariet, blir retransmisjonen gjort for den tapte pakken. I dette tilfellet antar vi at ACK tilhører den originale overføringen på grunn av at SampleRTT kommer til å være veldig stor.
- Hvis vi vurderer det andre scenariet, sendes to samme pakker, slik at duplisitet oppstår i dette tilfellet. I dette tilfellet antar vi at ACK tilhører retransmisjonen på grunn av at SampleRTT kommer til å bli veldig liten.
For å overvinne problemene ovenfor, er en enkel løsning gitt av Karn/Partridge-algoritmen. Denne algoritmen ga en enkel løsning som samler prøvene som sendes på en gang og ikke tar i betraktning prøvene på retransmisjonstidspunktet for å beregne estimert RTT.
Karn/Partridge Algoritme
I de to ovennevnte scenariene skjer retransmisjon, og vi har vurdert prøven RTT. Men denne algoritmen tar ikke hensyn til Sample RTT ved retransmittering. Siden omsendingen har skjedd, noe som betyr at det skjer noe i denne tur-retur-tiden eller at det kan oppstå overbelastning i et nettverk. For å overvinne dette problemet dobler denne algoritmen tidsavbruddet etter hver reoverføring. Denne algoritmen er implementert i TCP-nettverket.
Begrensning
Den tar ikke hensyn til variansen i RTT.
For å overvinne begrensningene ovenfor ble Jacobson/Karels-algoritmen utviklet som introduserer variansfaktoren i RTT.
Jacobson/Karels algoritme
Denne algoritmen ble utviklet for å overvinne begrensningene til Karn/Partridge algoritme. Den beregner forskjellen mellom SampleRTT og EstimatedRTT, og øker RTT basert på forskjellen.
Beregninger for gjennomsnittlig RTT
- Først beregner vi forskjellsfaktoren.
Diff = SampleRTT - EstimatedRTT
- Nå beregner vi EstimatedRTT, som vil bli beregnet på samme måte som vi gjorde ovenfor.
EstRTT = EstRTT + (δ*Diff)
- Nå beregner vi gjennomsnittet av differansefaktoren.
Dev = Dev + δ ( |Diff| - Dev)
Her er Dev en avviksfaktor, og δ er en faktor mellom 0 og 1. The Dev er et estimat av variansen fra EstRTT .
- Vi vil vurdere variansen mens vi beregner tidsavbruddsverdien.
Hvor, µ =1 og ɸ =4
Rask videresending
Den tidsavbruddsbaserte strategien for videresending er ineffektiv. TCP er en slags skyvevindusprotokoll, så hver gang retransmisjonen skjer, begynner den å sende den fra den tapte pakken og fremover.
Anta at jeg sender pakkene 0, 1, 2 og 3. Siden pakke 0 og pakke 1 mottas på den andre siden, går pakke 2 tapt i et nettverk. Jeg har mottatt bekreftelsen av pakke 0 og pakke 1, så jeg sender to pakker til, dvs. pakke 4 og pakke 5. Når pakke 3, 4 og 5 er sendt, vil jeg få bekreftelsen av pakke 1 som TCP-bekreftelser er kumulative, så den bekrefter opp til pakken at den har mottatt i rekkefølge. Jeg har ikke mottatt bekreftelsen på pakke 2, 3, 4 og 5 innen tidsavbruddsperioden, så jeg sender pakkene 2, 3, 4 og 5 på nytt. Siden pakke 2 er tapt, men andre pakker, dvs. 3, 4 ,5 mottas på den andre siden, sendes de fortsatt på nytt på grunn av denne tidsavbruddsmekanismen.
Hvordan kan denne tidsavbruddsineffektiviteten fjernes?
Den bedre løsningen under et skyvevindu:
Anta at n pakke har gått tapt, men likevel er pakkene n+1, n+2 og så videre mottatt. Mottakeren mottar kontinuerlig pakkene og sender ACK-pakkene og sier at mottakeren fortsatt venter på den n'te pakken. Mottakeren sender gjentatte eller dupliserte bekreftelser. I tilfellet ovenfor sendes ACK av pakke 1 tre ganger ettersom pakke 2 har gått tapt. Denne dupliserte ACK-pakken er en indikasjon på at den n-te pakken mangler, men de senere pakkene er mottatt.
Situasjonen ovenfor kan løses på følgende måter:
les json-filer
- Avsenderen kan ta 'dupliserte ACK-er' som et tidlig hint om at den n-te pakken har gått tapt, slik at avsenderen kan gjøre retransmisjonen så tidlig som mulig, dvs. at avsenderen ikke bør vente til tidsavbruddet inntreffer.
- Avsenderen kan implementere en rask overføringsstrategi i TCP. I en strategi for rask overføring bør avsenderen vurdere de trippel dupliserte ACK-ene som en trigger og sende den på nytt.
TCP bruker tre dupliserte ACK-er som en trigger og utfører deretter retransmisjon. I tilfellet ovenfor, når tre ACK-er av pakke 1 mottas, bør avsenderen sende den tapte pakken, dvs. pakke 2, uten å vente på at tidsavbruddsperioden inntreffer.