TCP ponovni prijenos znači ponovno slanje paketa preko mreže koji su izgubljeni ili oštećeni. Ovdje je retransmisija mehanizam koji koriste protokoli kao što su TCP osigurati pouzdanu komunikaciju. Ovdje pouzdana komunikacija znači da protokol jamči isporuku paketa čak i ako je paket podataka izgubljen ili oštećen.
javafx na eclipse
Mreže su nepouzdane i ne jamče kašnjenje ili ponovni prijenos izgubljenih ili oštećenih paketa. Mreža koja koristi kombinaciju potvrde i ponovnog slanja oštećenih ili izgubljenih paketa nudi pouzdanost.
Mehanizam retransmisije
Ovdje ponovni prijenos znači da su paketi podataka izgubljeni, što dovodi do nedostatka potvrde. Ovaj nedostatak potvrde aktivira mjerač vremena za istek vremena, što dovodi do ponovnog prijenosa paketa podataka. Ovdje tajmer znači da se paket podataka ponovno šalje ako se ne primi potvrda prije isteka vremena.
Razmotrimo sljedeće scenarije retransmisije.
Scenarij 1: Kada je paket podataka izgubljen ili je pogrešan.
U ovom scenariju, paket se šalje primatelju, ali nije primljena potvrda unutar tog vremenskog razdoblja. Kada istekne razdoblje čekanja, paket se ponovno šalje. Kada se paket ponovno odašilje, prima se potvrda. Nakon što se primi potvrda, ponovni prijenos se više neće dogoditi.
Scenarij 2: Kada je paket primljen, ali je izgubljena potvrda.
U ovom scenariju, paket je primljen na drugoj strani, ali je potvrda izgubljena, tj. ACK nije primljen na strani pošiljatelja. Nakon što istekne razdoblje čekanja, paket se ponovno šalje. Na drugoj strani nalaze se dvije kopije paketa; iako je paket ispravno primljen, potvrda nije primljena, pa pošiljatelj ponovno šalje paket. U tom slučaju se ponovni prijenos mogao izbjeći, ali zbog gubitka ACK-a, paket se ponovno šalje.
Scenarij 3: Kada nastupi rano vremensko ograničenje.
U ovom scenariju, paket je poslan, ali zbog kašnjenja u potvrdi ili isteka vremena prije stvarnog isteka vremena, paket se ponovno šalje. U ovom slučaju, paket je ponovno nepotrebno poslan zbog kašnjenja u potvrdi ili je vrijeme čekanja postavljeno ranije od stvarnog isteka vremena.
U gore navedenim scenarijima, prvi scenarij se ne može izbjeći, ali se druga dva scenarija mogu izbjeći. Pogledajmo kako možemo izbjeći ove situacije.
Koliko dugo pošiljatelj treba čekati?
Pošiljatelj postavlja vremensko ograničenje za ACK. Razdoblje čekanja može biti dvije vrste:
Kako bi se prevladale gornje dvije situacije, TCP postavlja vrijeme čekanja kao funkciju RTT-a (vrijeme povratnog putovanja) gdje je vrijeme povratnog putovanja vrijeme potrebno da paket putuje od izvora do odredišta i zatim se ponovno vrati.
Kako možemo dobiti RTT?
RTT može varirati ovisno o karakteristikama mreže, tj. ako je mreža zagušena, to znači da je RTT vrlo visok. Možemo procijeniti RTT jednostavnim gledanjem ACK-ova.
Pogledajmo kako možemo izmjeriti RTT.
Koristit ćemo se originalni algoritam za mjerenje RTT-a.
podcrtati u markdownu
Korak 1: Prvo mjerimo SampleRTT za svaki segment ili ACK par. Kada pošiljatelj pošalje paket, tada znamo tajmer na kojem je paket poslan, a također, znamo i tajmer na kojem je primljena potvrda. Izračunajte vrijeme između ova dva, i to postaje SampleRTT .
Korak 2: Nećemo uzeti samo jedan uzorak. Nastavit ćemo uzimati različite uzorke i izračunati ponderirani prosjek tih uzoraka, a to postaje EstRTT (Procijenjeni RTT).
gdje je α+ β = 1
α leži između 0,8 i 0,9
β leži između 0,1 i 0,2
Korak 3: Istek je postavljen na temelju EstRTT-a.
vrijeme čekanja = 2 * EstRTT.
Vrijeme čekanja postavljeno je na dvostruko veće od procijenjenog RTT-a. Ovako se izračunava stvarni faktor vremenskog ograničenja.
Greška u ovom pristupu
Postoji greška u izvornom algoritmu. Razmotrimo dva scenarija.
Scenarij 1.
Gornji dijagram pokazuje da pošiljatelj šalje podatke, za koje se kaže da su izvorni prijenos. Unutar vremenskog razdoblja nije primljena nikakva potvrda. Dakle, pošiljatelj ponovno šalje podatke. Nakon ponovnog slanja podataka, prima se potvrda. Pretpostavimo da je potvrda primljena za izvorni prijenos, a ne za ponovni prijenos. Budući da smo dobili potvrdu izvornog prijenosa, dakle SampleRTT izračunava se između vremena izvornog prijenosa i vremena u kojem je primljena potvrda. Ali zapravo, SampleRTT trebao biti između vremena ponovnog slanja i vremena potvrde.
Scenarij 2.
Gornji dijagram pokazuje da pošiljatelj šalje izvorni paket podataka za koji također dobivamo potvrdu. Ali potvrda se prima nakon ponovnog slanja podataka. Ako pretpostavimo da potvrda pripada ponovnom prijenosu, onda SampleRTT izračunava se između vremena ponovnog slanja i vremena potvrde.
U gornja oba scenarija, postoji dvosmislenost nepoznavanja je li potvrda za izvorni prijenos ili za ponovni prijenos.
jlist
Zaključak gornjeg algoritma.
- Ovdje ACK ne znači potvrdu prijenosa, već zapravo potvrđuje primitak podataka.
- Ako uzmemo u obzir prvi scenarij, ponovni prijenos se vrši za izgubljeni paket. U ovom slučaju, pretpostavljamo da ACK pripada izvornom prijenosu zbog čega SampleRTT ispada vrlo velik.
- Ako uzmemo u obzir drugi scenarij, dva ista paketa se šalju tako da u ovom slučaju dolazi do dupliranja. U ovom slučaju, pretpostavljamo da ACK pripada ponovnom prijenosu zbog čega SampleRTT postaje vrlo mali.
Za prevladavanje gore navedenih problema, Karn/Partridgeov algoritam daje jednostavno rješenje. Ovaj algoritam je dao jednostavno rješenje koje prikuplja uzorke poslane odjednom i ne uzima u obzir uzorke u vrijeme ponovnog slanja za izračun procijenjenog RTT-a.
Karn/Partridge algoritam
U gornja dva scenarija dolazi do ponovnog prijenosa, a mi smo razmotrili Uzorak RTT-a. Ali ovaj algoritam ne uzima u obzir Sample RTT prilikom ponovnog slanja. Budući da je došlo do ponovnog slanja, što znači da se nešto događa u ovom povratnom vremenu ili može doći do nekog zagušenja u mreži. Kako bi prevladao ovaj problem, ovaj algoritam udvostručuje vrijeme čekanja nakon svakog ponovnog prijenosa. Ovaj algoritam je implementiran u TCP mreži.
Ograničenje
Ne uzima u obzir varijancu u RTT-u.
Kako bi se prevladalo gornje ograničenje, razvijen je Jacobson/Karelsov algoritam koji uvodi faktor varijance u RTT.
Jacobson/Karelsov algoritam
Ovaj je algoritam razvijen kako bi se prevladala ograničenja Karn/Jarebica algoritam. Izračunava razliku između SampleRTT i EstimatedRTT i pojačava RTT na temelju razlike.
Izračuni za prosječni RTT
pretvorba niza u int u Javi
- Prvo izračunavamo faktor razlike.
Diff = SampleRTT - EstimatedRTT
- Sada izračunavamo EstimatedRTT, koji će se izračunati na isti način kao što smo to učinili gore.
EstRTT = EstRTT + (δ*Diff)
- Sada izračunavamo prosjek faktora razlike.
Dev = Dev + δ ( |Razl| - Dev)
Ovdje je Dev faktor odstupanja, a δ je faktor između 0 i 1. The Dev je procjena varijance od EstRTT .
- Razmotrit ćemo varijancu dok izračunavamo vrijednost vremenskog ograničenja.
Gdje, µ =1 i ɸ =4
Brzo ponovno slanje
Strategija ponovnog slanja zasnovana na vremenskom ograničenju je neučinkovita. TCP je vrsta protokola s kliznim prozorom, tako da kad god dođe do ponovnog prijenosa, počinje ga slati od izgubljenog paketa dalje.
Pretpostavimo da šaljem pakete 0, 1, 2 i 3. Budući da su paket 0 i paket 1 primljeni na drugoj strani, paket 2 je izgubljen u mreži. Primio sam potvrdu za paket 0 i paket 1, pa šaljem još dva paketa, tj. paket 4 i paket 5. Kada se pošalju paketi 3, 4 i 5, tada ću dobiti potvrdu za paket 1 kao TCP potvrdu su kumulativni, tako da priznaje sve do paketa koji je redom primio. Nisam primio potvrdu za pakete 2, 3, 4 i 5 unutar vremenskog razdoblja, pa ponovno šaljem pakete 2, 3, 4 i 5. Budući da je paket 2 izgubljen, ali drugi paketi, tj. 3, 4 ,5 primaju s druge strane, oni se i dalje ponovno odašilju zbog ovog mehanizma vremenskog ograničenja.
Kako se ova neučinkovitost vremenskog ograničenja može ukloniti?
Bolje rješenje ispod kliznog prozora:
Pretpostavimo da je n paket izgubljen, ali ipak su primljeni paketi n+1, n+2 itd. Primatelj neprekidno prima pakete i šalje ACK pakete govoreći da primatelj još uvijek čeka n-ti paket. Primatelj šalje ponovljene ili dvostruke potvrde. U gornjem slučaju, ACK paketa 1 šalje se tri puta jer je paket 2 izgubljen. Ovaj duplikat ACK paketa je pokazatelj da n-ti paket nedostaje, ali kasniji paketi su primljeni.
java provjera je nula
Gore navedena situacija može se riješiti na sljedeće načine:
- Pošiljatelj može uzeti 'duplicirane ACK-ove' kao ranu naznaku da je n-ti paket izgubljen tako da pošiljatelj može izvršiti ponovni prijenos što je ranije moguće, tj. pošiljatelj ne bi trebao čekati dok ne istekne vrijeme čekanja.
- Pošiljatelj može implementirati strategiju brzog prijenosa u TCP-u. U strategiji brzog prijenosa, pošiljatelj bi trebao uzeti u obzir trostruki duplikat ACK-a kao okidač i ponovno ga poslati.
TCP koristi tri dvostruka ACK-a kao okidač i zatim izvodi ponovni prijenos. U gornjem slučaju, kada su primljena tri ACK-a paketa 1, pošiljatelj bi trebao poslati izgubljeni paket, tj. paket 2, bez čekanja da nastupi vremensko ograničenje.