Opakovaný prenos TCP znamená opätovné odoslanie paketov cez sieť, ktoré boli stratené alebo poškodené. Tu je retransmisia mechanizmus, ktorý využívajú protokoly ako napr TCP poskytnúť spoľahlivú komunikáciu. Spoľahlivá komunikácia tu znamená, že protokol zaručuje doručenie paketu aj v prípade straty alebo poškodenia dátového paketu.
volanie funkcie javascript z html
Siete sú nespoľahlivé a nezaručujú oneskorenie alebo opätovný prenos stratených alebo poškodených paketov. Sieť, ktorá využíva kombináciu potvrdenia a opätovného prenosu poškodených alebo stratených paketov, ponúka spoľahlivosť.
Mechanizmus retransmisie
V tomto prípade opakovaný prenos znamená, že dátové pakety boli stratené, čo vedie k nedostatočnému potvrdeniu. Tento nedostatok potvrdenia spúšťa časový limit, ktorý vedie k opakovanému prenosu dátových paketov. Časovač tu znamená, že ak nie je prijaté žiadne potvrdenie pred uplynutím časovača, dátový paket sa odošle znova.
Uvažujme o nasledujúcich scenároch retransmisie.
Scenár 1: Keď sa dátový paket stratí alebo je chybný.
V tomto scenári sa paket odošle príjemcovi, ale počas tohto časového limitu sa neprijme žiadne potvrdenie. Po uplynutí časového limitu sa paket znova odošle. Keď je paket znova odoslaný, prijme sa potvrdenie. Po prijatí potvrdenia sa opakovaný prenos nevykoná.
Scenár 2: Keď je paket prijatý, ale potvrdenie sa stratí.
V tomto scenári je paket prijatý na druhej strane, ale potvrdenie sa stratí, t.j. ACK nie je prijaté na strane odosielateľa. Po uplynutí časového limitu sa paket odošle znova. Na druhej strane sú dve kópie paketov; aj keď je paket prijatý správne, potvrdenie nie je prijaté, takže odosielateľ odošle paket znova. V tomto prípade sa dalo opätovnému prenosu vyhnúť, ale v dôsledku straty ACK sa paket odošle znova.
Scenár 3: Keď nastane skorý časový limit.
V tomto scenári sa paket odošle, ale v dôsledku oneskorenia potvrdenia alebo časového limitu, ktorý nastal pred skutočným časovým limitom, sa paket odošle znova. V tomto prípade bol paket odoslaný znova zbytočne z dôvodu oneskorenia potvrdenia alebo bol nastavený časový limit skôr ako skutočný časový limit.
Vo vyššie uvedených scenároch sa prvému scenáru vyhnúť nedá, ale ďalším dvom scenárom sa dá vyhnúť. Pozrime sa, ako sa týmto situáciám môžeme vyhnúť.
Ako dlho by mal odosielateľ čakať?
Odosielateľ nastaví časový limit pre ACK. Časový limit môže byť dvoch typov:
Aby ste prekonali vyššie uvedené dve situácie, TCP nastavuje časový limit ako funkciu RTT (spiatočný čas), kde spiatočný čas je čas potrebný na to, aby paket prešiel zo zdroja do cieľa a potom sa vrátil späť.
Ako môžeme získať RTT?
RTT sa môže meniť v závislosti od charakteristík siete, t.j. ak je sieť preťažená, znamená to, že RTT je veľmi vysoká. RTT môžeme odhadnúť jednoduchým sledovaním ACK.
matice v jazyku c
Pozrime sa, ako môžeme merať RTT.
Budeme používať pôvodný algoritmus na meranie RTT.
Krok 1: Najprv zmeriame SampleRTT pre každý segment alebo ACK pár. Keď odosielateľ odošle paket, poznáme časovač, v ktorom je paket odoslaný, a tiež poznáme časovač, v ktorom je prijaté potvrdenie. Vypočítajte čas medzi týmito dvoma, a to sa stane SampleRTT .
Krok 2: Neberieme len jednu vzorku. Budeme pokračovať v odoberaní rôznych vzoriek a vypočítame vážený priemer týchto vzoriek, z čoho sa stane EstRTT (odhadovaný RTT).
kde α+ β = 1
α leží medzi 0,8 a 0,9
β leží medzi 0,1 a 0,2
Krok 3: Časový limit je nastavený na základe EstRTT.
časový limit = 2 * EstRTT.
Časový limit je nastavený na dvojnásobok odhadovaného RTT. Takto sa vypočíta skutočný faktor časového limitu.
Chyba v tomto prístupe
V pôvodnom algoritme je chyba. Uvažujme o dvoch scenároch.
Scenár 1.
Vyššie uvedený diagram ukazuje, že odosielateľ odosiela údaje, o ktorých sa hovorí, že ide o pôvodný prenos. Počas časového limitu nie je prijaté žiadne potvrdenie. Odosielateľ teda znova odošle údaje. Po opätovnom odoslaní údajov sa prijme potvrdenie. Predpokladajme, že potvrdenie je prijaté pre pôvodný prenos, nie pre opakovaný prenos. Keďže dostaneme potvrdenie o pôvodnom prenose, tak SampleRTT sa vypočítava medzi časom pôvodného prenosu a časom prijatia potvrdenia. Ale v skutočnosti, SampleRTT mala byť medzi časom opätovného odoslania a časom potvrdenia.
Scenár 2
Vyššie uvedený diagram ukazuje, že odosielateľ posiela pôvodný dátový paket, pre ktorý dostaneme aj potvrdenie. Potvrdenie je však prijaté po opätovnom odoslaní údajov. Ak predpokladáme, že potvrdenie patrí k retransmisii, potom SampleRTT sa počíta medzi časom opakovaného prenosu a časom potvrdenia.
koľko týždňov má mesiac
V oboch vyššie uvedených scenároch existuje nejednoznačnosť nevedomosti, či je potvrdenie pre pôvodný prenos alebo pre retransmisiu.
Záver vyššie uvedeného algoritmu.
- ACK tu neznamená potvrdenie prenosu, ale v skutočnosti potvrdzuje príjem údajov.
- Ak vezmeme do úvahy prvý scenár, opakovaný prenos sa vykoná pre stratený paket. V tomto prípade predpokladáme, že ACK patrí k pôvodnému prenosu, vďaka čomu je SampleRTT veľmi veľký.
- Ak vezmeme do úvahy druhý scenár, odosielajú sa dva rovnaké pakety, takže v tomto prípade dochádza k duplicite. V tomto prípade predpokladáme, že ACK patrí k retransmisii, vďaka ktorej bude SampleRTT veľmi malý.
Na prekonanie vyššie uvedených problémov poskytuje Karn/Partridge algoritmus jednoduché riešenie. Tento algoritmus poskytol jednoduché riešenie, ktoré zhromažďuje vzorky odoslané naraz a neberie do úvahy vzorky v čase opätovného prenosu na výpočet odhadovaného RTT.
Algoritmus Karn/Partridge
Vo vyššie uvedených dvoch scenároch nastáva retransmisia a my sme uvažovali o vzorovom RTT. Ale tento algoritmus neberie do úvahy vzorový RTT pri opakovanom prenose. Pretože došlo k opakovanému prenosu, čo znamená, že sa niečo stane v tomto spiatočnom čase alebo môže dôjsť k nejakému preťaženiu v sieti. Na prekonanie tohto problému tento algoritmus zdvojnásobuje časový limit po každom opakovanom prenose. Tento algoritmus je implementovaný v sieti TCP.
Obmedzenie
Nezohľadňuje rozptyl v RTT.
Na prekonanie vyššie uvedeného obmedzenia bol vyvinutý Jacobson/Karelsov algoritmus, ktorý zavádza faktor rozptylu v RTT.
ako sa vymaniť zo slučky while java
Jacobsonov/Karelsov algoritmus
Tento algoritmus bol vyvinutý na prekonanie obmedzení Karn/Partridge algoritmu. Vypočítava rozdiel medzi SampleRTT a EstimatedRTT a zvyšuje RTT na základe rozdielu.
Výpočty pre priemernú RTT
- Najprv vypočítame rozdielový faktor.
Rozdiel = SampleRTT - Odhadovaný RTT
- Teraz vypočítame odhadovaný RTT, ktorý sa vypočíta rovnakým spôsobom ako vyššie.
EstRTT = EstRTT + (δ*Diff)
- Teraz vypočítame priemer rozdielového faktora.
Dev = Dev + δ ( |Diff| - Dev)
Tu je Dev faktor odchýlky a δ je faktor medzi 0 a 1. The Dev je odhad rozptylu od EstRTT .
- Pri výpočte hodnoty časového limitu budeme brať do úvahy rozptyl.
Kde, µ = 1 a ɸ = 4
Rýchla retransmisia
Stratégia opakovaného prenosu založená na časovom limite je neefektívna. TCP je protokol s posuvným oknom, takže vždy, keď dôjde k opakovanému prenosu, začne ho odosielať od strateného paketu ďalej.
Predpokladajme, že prenášam pakety 0, 1, 2 a 3. Keďže paket 0 a paket 1 sú prijaté na druhej strane, paket 2 sa stratí v sieti. Dostal som potvrdenie paketu 0 a paketu 1, takže posielam ďalšie dva pakety, t.j. paket 4 a paket 5. Keď sa odošlú pakety 3, 4 a 5, potom dostanem potvrdenie paketu 1 ako TCP potvrdenia sú kumulatívne, takže potvrdí až paket, že prijal v poriadku. Nedostal som potvrdenie o pakete 2, 3, 4 a 5 v časovom limite, takže posielam znova pakety 2, 3, 4 a 5. Keďže paket 2 je stratený, ale ostatné pakety, t.j. 3, 4 ,5 sú prijímané na druhej strane, sú stále znova vysielané kvôli tomuto mechanizmu časového limitu.
Ako možno túto neefektívnosť časového limitu odstrániť?
Lepšie riešenie pod posuvným oknom:
webové stránky ako coomeet
Predpokladajme, že n paketov sa stratilo, ale napriek tomu boli prijaté pakety n+1, n+2 atď. Prijímač nepretržite prijíma pakety a odosiela ACK pakety s tým, že prijímač stále čaká na n-tý paket. Príjemca posiela opakované alebo duplicitné potvrdenia. Vo vyššie uvedenom prípade sa ACK paketu 1 odošle trikrát, pretože paket 2 sa stratil. Tento duplicitný ACK paket znamená, že n-tý paket chýba, ale sú prijaté neskoršie pakety.
Vyššie uvedenú situáciu je možné vyriešiť nasledujúcimi spôsobmi:
- Odosielateľ môže brať 'duplicitné ACK' ako skorú nápovedu, že n-tý paket sa stratil, takže odosielateľ môže uskutočniť opakovaný prenos čo najskôr, t.j. odosielateľ by nemal čakať, kým nedôjde k vypršaniu časového limitu.
- Odosielateľ môže implementovať stratégiu rýchleho prenosu v TCP. Pri stratégii rýchleho prenosu by mal odosielateľ považovať trojité duplicitné ACK za spúšťač a znova ho odoslať.
TCP používa tri duplicitné ACK ako spúšťač a potom vykoná retransmisiu. Vo vyššie uvedenom prípade, keď sú prijaté tri ACK paketu 1, odosielateľ by mal poslať stratený paket, t. j. paket 2, bez čakania, kým nastane časový limit.