TCP pakartotinis siuntimas reiškia prarastų arba sugadintų paketų pakartotinį siuntimą tinkle. Čia retransliavimas yra mechanizmas, kurį naudoja tokie protokolai kaip TCP užtikrinti patikimą ryšį. Čia patikimas ryšys reiškia, kad protokolas garantuoja paketo pristatymą, net jei duomenų paketas buvo prarastas ar sugadintas.
išsaugoti youtube video vlc
Tinklai yra nepatikimi ir negarantuoja prarastų ar sugadintų paketų vėlavimo ar pakartotinio perdavimo. Tinklas, kuriame naudojamas sugadintų ar prarastų paketų patvirtinimo ir pakartotinio siuntimo derinys, užtikrina patikimumą.
Retransliavimo mechanizmas
Šiuo atveju pakartotinis perdavimas reiškia, kad duomenų paketai buvo prarasti, todėl nėra patvirtinimo. Šis patvirtinimo trūkumas suaktyvina laikmatį iki skirtojo laiko, dėl kurio pakartotinai perduodami duomenų paketai. Čia laikmatis reiškia, kad jei iki laikmačio galiojimo pabaigos negaunamas patvirtinimas, duomenų paketas persiunčiamas iš naujo.
Panagrinėkime šiuos retransliavimo scenarijus.
1 scenarijus: kai duomenų paketas yra prarastas arba klaidingas.
Pagal šį scenarijų paketas siunčiamas gavėjui, bet per tą skirtąjį laikotarpį negaunamas patvirtinimas. Pasibaigus skirtajam laikui, paketas siunčiamas dar kartą. Kai paketas persiunčiamas, gaunamas patvirtinimas. Gavus patvirtinimą, pakartotinis siuntimas nebus kartojamas.
2 scenarijus: kai paketas gautas, bet patvirtinimas prarandamas.
Pagal šį scenarijų paketas gaunamas iš kitos pusės, tačiau patvirtinimas prarandamas, ty siuntėjo pusėje negaunamas ACK. Pasibaigus skirtajam laikui, paketas siunčiamas iš naujo. Kitoje pusėje yra dvi paketų kopijos; nors paketas gautas teisingai, patvirtinimas negaunamas, todėl siuntėjas paketą persiunčia. Tokiu atveju pakartotinio siuntimo buvo galima išvengti, tačiau dėl ACK praradimo paketas persiunčiamas iš naujo.
3 scenarijus: kai įvyksta ankstyvas skirtasis laikas.
Pagal šį scenarijų paketas išsiunčiamas, tačiau dėl patvirtinimo delsos arba pasibaigus laikui, paketas persiunčiamas iš naujo. Šiuo atveju paketas buvo išsiųstas dar kartą be reikalo dėl patvirtinimo vėlavimo arba laikas buvo nustatytas anksčiau nei tikrasis laikas.
Pirmiau nurodytuose scenarijuose negalima išvengti pirmojo scenarijaus, tačiau galima išvengti kitų dviejų scenarijų. Pažiūrėkime, kaip galime išvengti tokių situacijų.
Kiek laiko siuntėjas turėtų laukti?
Siuntėjas nustato ACK skirtąjį laiką. Skirtojo laikas gali būti dviejų tipų:
Norėdami įveikti pirmiau minėtas dvi situacijas, TCP nustato skirtąjį laiką kaip RTT funkciją (reiso pirmyn ir atgal laikas), kur kelionės pirmyn ir atgal laikas yra laikas, reikalingas paketui nukeliauti nuo šaltinio iki paskirties vietos ir grįžti atgal.
Kaip galime gauti RTT?
kali linux komandas
RTT gali skirtis priklausomai nuo tinklo charakteristikų, t. y. jei tinklas yra perkrautas, tai reiškia, kad RTT yra labai didelis. Mes galime įvertinti RTT tiesiog stebėdami ACK.
Pažiūrėkime, kaip galime išmatuoti RTT.
Mes naudosime originalus algoritmas išmatuoti RTT.
1 žingsnis: Pirma, mes išmatuojame RTT pavyzdys kiekvienam segmentui arba ACK porai. Kai siuntėjas siunčia paketą, mes žinome laikmatį, kuriuo paketas siunčiamas, taip pat žinome laikmatį, kuriuo gaunamas patvirtinimas. Apskaičiuokite laiką tarp šių dviejų ir tai taps RTT pavyzdys .
2 žingsnis: Mes neimsime tik vieno pavyzdžio. Mes ir toliau imsime skirtingus mėginius ir skaičiuosime šių mėginių svertinį vidurkį, ir tai tampa EstRTT (apskaičiuota RTT).
kur α+ β = 1
α yra nuo 0,8 iki 0,9
β yra nuo 0,1 iki 0,2
3 veiksmas: Laikas nustatomas remiantis EstRTT.
skirtasis laikas = 2 * EstRTT.
Skirtasis laikas nustatytas taip, kad jis būtų du kartus didesnis už apskaičiuotą RTT. Taip apskaičiuojamas faktinis skirtojo laiko koeficientas.
paveldėjimas java
Šio požiūrio trūkumas
Yra pradinio algoritmo trūkumas. Panagrinėkime du scenarijus.
1 scenarijus.
Aukščiau pateikta diagrama rodo, kad siuntėjas siunčia duomenis, kurie, kaip teigiama, yra originalus perdavimas. Per skirtąjį laikotarpį patvirtinimas negaunamas. Taigi, siuntėjas pakartotinai persiunčia duomenis. Pakartotinai perdavus duomenis, gaunamas patvirtinimas. Tarkime, kad patvirtinimas gaunamas už pradinį siuntimą, o ne už pakartotinį siuntimą. Kadangi gauname pirminio perdavimo patvirtinimą, taigi RTT pavyzdys skaičiuojamas nuo pradinio perdavimo laiko iki patvirtinimo gavimo laiko. Tačiau iš tikrųjų, RTT pavyzdys turėjo būti tarp pakartotinio perdavimo ir patvirtinimo momento.
2 scenarijus.
Aukščiau pateikta diagrama rodo, kad siuntėjas siunčia pradinį duomenų paketą, už kurį taip pat gauname patvirtinimą. Tačiau patvirtinimas gaunamas pakartotinai perdavus duomenis. Jei darysime prielaidą, kad patvirtinimas priklauso perdavimui, tada RTT pavyzdys skaičiuojamas nuo pakartotinio perdavimo iki patvirtinimo laiko.
Pagal pirmiau minėtus abu scenarijus neaišku, ar patvirtinimas skirtas pirminiam, ar pakartotiniam perdavimui.
Aukščiau pateikto algoritmo išvada.
- Čia ACK nereiškia perdavimo patvirtinimo, bet iš tikrųjų jis patvirtina duomenų gavimą.
- Jei atsižvelgsime į pirmąjį scenarijų, pamestas paketas persiunčiamas pakartotinai. Šiuo atveju darome prielaidą, kad ACK priklauso originaliam perdavimui, dėl kurio SampleRTT yra labai didelis.
- Jei atsižvelgsime į antrąjį scenarijų, siunčiami du tie patys paketai, todėl šiuo atveju atsiranda dubliavimas. Šiuo atveju darome prielaidą, kad ACK priklauso pakartotiniam perdavimui, dėl kurio SampleRTT tampa labai mažas.
Norint įveikti aukščiau nurodytas problemas, paprastas sprendimas pateikiamas naudojant Karn/Partridge algoritmą. Šis algoritmas davė paprastą sprendimą, kuris surenka vienu metu siunčiamus pavyzdžius ir neatsižvelgia į mėginius pakartotinio siuntimo metu apskaičiuojant numatomą RTT.
Karn/Partridge algoritmas
Pagal pirmiau minėtus du scenarijus įvyksta pakartotinis perdavimas, ir mes apsvarstėme pavyzdį RTT. Tačiau šis algoritmas persiunčiant neatsižvelgia į RTT pavyzdį. Nuo tada, kai įvyko pakartotinis siuntimas, o tai reiškia, kad per šį kelionės pirmyn ir atgal metu kažkas nutinka arba tinkle gali susidaryti perkrova. Siekiant išspręsti šią problemą, šis algoritmas padvigubina skirtąjį laiką po kiekvieno pakartotinio perdavimo. Šis algoritmas yra įdiegtas TCP tinkle.
Apribojimas
Jame neatsižvelgiama į RTT skirtumą.
Siekiant įveikti minėtą apribojimą, buvo sukurtas Jacobson/Karels algoritmas, kuris įveda RTT dispersijos koeficientą.
Jacobson/Karels algoritmas
Šis algoritmas buvo sukurtas siekiant įveikti apribojimus Karnas / Kurapka algoritmas. Jis apskaičiuoja skirtumą tarp SampleRTT ir EstimatedRTT ir padidina RTT pagal skirtumą.
Vidutinio RTT skaičiavimai
- Pirmiausia apskaičiuojame skirtumo koeficientą.
Skirtumas = SampleRTT – EstimatedRTT
1 milijonas kiek 0
- Dabar apskaičiuojame EstimatedRTT, kuris bus skaičiuojamas taip pat, kaip ir anksčiau.
EstRTT = EstRTT + (δ* Skirtumas)
- Dabar apskaičiuojame skirtumo koeficiento vidurkį.
Dev = Dev + δ ( |Diff| - Dev)
Čia Dev yra nuokrypio koeficientas, o δ yra koeficientas nuo 0 iki 1 Dev yra nukrypimo nuo EstRTT .
perjungimo metodas java
- Apskaičiuodami skirtojo laiko reikšmę atsižvelgsime į dispersiją.
kur, µ =1 ir ɸ =4
Greitas retransliavimas
Pakartotinio perdavimo strategija, pagrįsta skirtuoju laiku, yra neveiksminga. TCP yra slankiojo lango tipo protokolas, todėl kiekvieną kartą, kai įvyksta pakartotinis siuntimas, jis pradeda jį siųsti nuo prarasto paketo.
Tarkime, aš perduodu paketus 0, 1, 2 ir 3. Kadangi paketas 0 ir paketas 1 gaunami kitoje pusėje, 2 paketas prarandamas tinkle. Gavau 0 ir 1 paketo patvirtinimą, todėl siunčiu dar du paketus, ty 4 ir 5 paketus. Kai bus išsiųsti 3, 4 ir 5 paketai, 1 paketo patvirtinimą gausiu kaip TCP patvirtinimus. yra kaupiamieji, todėl jis patvirtina iki paketo, kurį gavo eilės tvarka. Per skirtąjį laikotarpį negavau 2, 3, 4 ir 5 paketų patvirtinimo, todėl 2, 3, 4 ir 5 paketus persiunčiau iš naujo. Kadangi 2 paketas prarastas, bet kiti paketai, t.y. 3, 4 ,5 gaunami kitoje pusėje, jie vis tiek persiunčiami dėl šio skirtojo laiko mechanizmo.
Kaip galima pašalinti šį skirtojo laiko neefektyvumą?
Geresnis sprendimas po stumdomu langu:
Tarkime, kad n paketas buvo prarastas, bet vis tiek buvo gauti paketai n+1, n+2 ir pan. Imtuvas nuolat gauna paketus ir siunčia ACK paketus, sakydamas, kad imtuvas vis dar laukia n-ojo paketo. Gavėjas siunčia pakartotinius arba pasikartojančius patvirtinimus. Pirmiau nurodytu atveju 1 paketo ACK siunčiamas tris kartus, nes 2 paketas buvo prarastas. Šis pasikartojantis ACK paketas rodo, kad trūksta n-ojo paketo, bet vėlesni paketai yra gauti.
Aukščiau pateiktą situaciją galima išspręsti šiais būdais:
- Siuntėjas gali priimti „pasikartojančius ACK“ kaip ankstyvą užuominą, kad n-asis paketas buvo prarastas, kad siuntėjas galėtų kuo anksčiau atlikti pakartotinį siuntimą, t. y. siuntėjas neturėtų laukti, kol baigsis laikas.
- Siuntėjas gali įgyvendinti greito perdavimo strategiją TCP. Taikant greito perdavimo strategiją, siuntėjas turėtų laikyti trigubus pasikartojančius ACK signalus kaip trigerį ir pakartotinai jį perduoti.
TCP kaip trigerį naudoja tris pasikartojančius ACK ir tada atlieka pakartotinį siuntimą. Aukščiau nurodytu atveju, kai gaunami trys 1 paketo ACK, siuntėjas turėtų išsiųsti prarastą paketą, t. y. 2 paketą, nelaukdamas, kol ateis laikas.