Ponovno pošiljanje TCP pomeni ponovno pošiljanje paketov po omrežju, ki so bili izgubljeni ali poškodovani. Tukaj je retransmisija mehanizem, ki ga uporabljajo protokoli, kot je npr TCP zagotoviti zanesljivo komunikacijo. Tu zanesljiva komunikacija pomeni, da protokol zagotavlja dostavo paketa, tudi če je bil podatkovni paket izgubljen ali poškodovan.

kje je tipka za vstavljanje na tipkovnici prenosnika

Omrežja so nezanesljiva in ne zagotavljajo zakasnitve ali ponovnega prenosa izgubljenih ali poškodovanih paketov. Omrežje, ki uporablja kombinacijo potrditve in ponovnega prenosa poškodovanih ali izgubljenih paketov, nudi zanesljivost.

Mehanizem ponovnega prenosa

V tem primeru ponovni prenos pomeni, da so bili podatkovni paketi izgubljeni, kar vodi do pomanjkanja potrditve. To pomanjkanje potrditve sproži časovnik za časovno omejitev, kar vodi do ponovnega prenosa podatkovnih paketov. Tukaj časovnik pomeni, da se podatkovni paket ponovno pošlje, če pred potekom časovnika ni prejete potrditve.

Razmislimo o naslednjih scenarijih ponovnega prenosa.

1. scenarij: Ko je podatkovni paket izgubljen ali napačen.

V tem scenariju je paket poslan prejemniku, vendar v tem časovnem obdobju ni prejeta nobena potrditev. Ko se časovna omejitev izteče, se paket znova pošlje. Ko je paket ponovno poslan, je prejeta potrditev. Ko je potrditev prejeta, do ponovnega prenosa ne bo več prišlo.

Scenarij 2: Ko je paket prejet, vendar je potrditev izgubljena.

V tem scenariju je paket prejet na drugi strani, vendar je potrditev izgubljena, tj. ACK ni prejet na strani pošiljatelja. Ko se časovna omejitev izteče, se paket ponovno pošlje. Na drugi strani sta dve kopiji paketov; čeprav je paket prejet pravilno, potrditev ni prejeta, zato pošiljatelj ponovno pošlje paket. V tem primeru bi se ponovnemu prenosu lahko izognili, vendar se zaradi izgube ACK-a paket ponovno pošlje.

3. scenarij: ko nastopi zgodnja časovna omejitev.

V tem scenariju je paket poslan, vendar je zaradi zakasnitve potrditve ali časovne omejitve prišlo pred dejansko časovno omejitvijo, se paket ponovno pošlje. V tem primeru je bil paket ponovno poslan po nepotrebnem zaradi zakasnitve pri potrditvi ali pa je bila časovna omejitev nastavljena prej kot dejanska časovna omejitev.

V zgornjih scenarijih se prvemu scenariju ni mogoče izogniti, drugim dvema pa se je mogoče izogniti. Poglejmo, kako se lahko izognemo tem situacijam.

Kako dolgo naj pošiljatelj čaka?

Pošiljatelj nastavi časovno omejitev za ACK. Časovna omejitev je lahko dveh vrst:

pvr polna oblika

Prekratko:Če je časovna omejitev prekratka, bodo ponovni prenosi izgubljeni.Predolgo:Če je časovna omejitev predolga, bo ob izgubi paketa prišlo do prevelike zakasnitve.

Da bi premagali zgornji dve situaciji, TCP nastavi časovno omejitev kot funkcijo RTT (čas povratnega potovanja), kjer je čas povratnega potovanja čas, ki je potreben, da paket potuje od vira do cilja in se nato znova vrne.

Kako lahko pridobimo RTT?

RTT se lahko razlikuje glede na značilnosti omrežja, tj. če je omrežje preobremenjeno, to pomeni, da je RTT zelo visok. RTT lahko ocenimo tako, da preprosto opazujemo ACK.

Poglejmo, kako lahko izmerimo RTT.

Uporabili bomo originalni algoritem za merjenje RTT.

Korak 1: Najprej izmerimo SampleRTT za vsak segment ali par ACK. Ko pošiljatelj pošlje paket, poznamo časovnik, pri katerem je paket poslan, in poznamo tudi časovnik, pri katerem je prejeta potrditev. Izračunajte čas med tema dvema in to postane SampleRTT .

2. korak: Ne bomo vzeli samo enega vzorca. Še naprej bomo jemali različne vzorce in izračunali tehtano povprečje teh vzorcev, kar bo postalo EstRTT (Ocenjeni RTT).

kjer je α+ β = 1

α leži med 0,8 in 0,9

β leži med 0,1 in 0,2

3. korak: Časovna omejitev je nastavljena na podlagi EstRTT.

časovna omejitev = 2 * EstRTT.

medtem ko zanka java

Časovna omejitev je nastavljena na dvakratno ocenjeno RTT. Tako se izračuna dejanski faktor časovne omejitve.

Napaka v tem pristopu

V prvotnem algoritmu je napaka. Razmislimo o dveh scenarijih.

Scenarij 1.

Zgornji diagram kaže, da pošiljatelj pošlje podatke, ki naj bi bili izvirni prenos. V času časovne omejitve ni prejeta nobena potrditev. Torej pošiljatelj ponovno posreduje podatke. Po ponovnem prenosu podatkov je prejeta potrditev. Predpostavimo, da je potrditev prejeta za prvotni prenos, ne za ponovni prenos. Ker dobimo potrditev izvirnega prenosa, torej SampleRTT se izračuna med časom prvotnega prenosa in časom prejema potrditve. Toda pravzaprav, SampleRTT mora biti med časom ponovnega prenosa in časom potrditve.

Scenarij 2.

Zgornji diagram kaže, da pošiljatelj pošlje izvirni podatkovni paket, za katerega prejmemo tudi potrditev. Toda potrditev je prejeta po ponovnem prenosu podatkov. Če predpostavimo, da potrditev pripada ponovnemu prenosu, potem SampleRTT se izračuna med časom ponovnega prenosa in časom potrditve.

V zgornjih obeh scenarijih obstaja dvoumnost, da ne veste, ali je potrditev za prvotni prenos ali za ponovni prenos.

Zaključek zgornjega algoritma.

• Tukaj ACK ne pomeni potrditve prenosa, ampak dejansko potrjuje prejem podatkov.
• Če upoštevamo prvi scenarij, se ponovni prenos izvede za izgubljeni paket. V tem primeru predpostavljamo, da ACK pripada prvotnemu prenosu, zaradi česar je SampleRTT zelo velik.
• Če upoštevamo drugi scenarij, sta poslana dva ista paketa, tako da v tem primeru pride do dvojnosti. V tem primeru predpostavljamo, da ACK pripada ponovnemu prenosu, zaradi česar bo SampleRTT zelo majhen.

Za premagovanje zgornjih težav je na voljo preprosta rešitev z algoritmom Karn/Partridge. Ta algoritem je ponudil preprosto rešitev, ki zbira vzorce, poslane naenkrat, in ne upošteva vzorcev v času ponovnega prenosa za izračun ocenjenega RTT.

Algoritem Karn/Partridge

V zgornjih dveh scenarijih pride do ponovnega prenosa in upoštevali smo vzorec RTT. Toda ta algoritem pri ponovnem pošiljanju ne upošteva vzorčnega RTT-ja. Ker je prišlo do ponovnega prenosa, kar pomeni, da se v tem povratnem času nekaj zgodi ali pa lahko pride do zastojev v omrežju. Za premagovanje te težave ta algoritem podvoji časovno omejitev po vsakem ponovnem prenosu. Ta algoritem je implementiran v omrežju TCP.

Omejitev

Ne upošteva variance v RTT.

Če je varianca majhna, se EstimatedRTT izkaže za točnega. Če je varianca velika, EstimatedRTT ni natančen.

Za premagovanje zgornje omejitve je bil razvit algoritem Jacobson/Karels, ki uvaja faktor variance v RTT.

Jacobson/Karelsov algoritem

.naslednja java

Ta algoritem je bil razvit za premagovanje omejitev Karn/Jerebica algoritem. Izračuna razliko med SampleRTT in EstimatedRTT ter poveča RTT na podlagi razlike.

Izračuni za povprečno RTT

• Najprej izračunamo faktor razlike.

Diff = SampleRTT – EstimatedRTT

• Zdaj izračunamo EstimatedRTT, ki bo izračunan na enak način kot zgoraj.

EstRTT = EstRTT + (δ*Diff)

• Zdaj izračunamo povprečje faktorja razlike.

Dev = Dev + δ ( |Diff| - Dev)

cm do stopal in palcev

Tu je Dev faktor odstopanja, δ pa faktor med 0 in 1 Dev je ocena variance od EstRTT .

• Pri izračunu vrednosti časovne omejitve bomo upoštevali varianco.

Kje, µ =1 in ɸ =4

Hiter ponovni prenos

Strategija za ponovno pošiljanje, ki temelji na časovni omejitvi, je neučinkovita. TCP je vrsta protokola z drsečim oknom, tako da vsakič, ko pride do ponovnega prenosa, ga začne pošiljati od izgubljenega paketa naprej.

Recimo, da pošljem pakete 0, 1, 2 in 3. Ker sta paket 0 in paket 1 prejeta na drugi strani, se paket 2 v omrežju izgubi. Prejel sem potrditev paketa 0 in paketa 1, zato pošiljam še dva paketa, tj. paket 4 in paket 5. Ko bodo poslani paketi 3, 4 in 5, bom prejel potrditev paketa 1 kot potrditve TCP so kumulativni, tako da potrdi do paketa, ki ga je prejel po vrstnem redu. V času časovne omejitve nisem prejel potrditve paketov 2, 3, 4 in 5, zato ponovno pošiljam pakete 2, 3, 4 in 5. Ker je paket 2 izgubljen, drugi paketi, tj. 3, 4 ,5 prejeta na drugi strani, se še vedno ponovno pošiljajo zaradi tega mehanizma časovne omejitve.

Kako se lahko ta neučinkovitost časovne omejitve odpravi?

Boljša rešitev pod drsnim oknom:

Recimo, da je bil n paket izgubljen, vendar so bili še vedno prejeti paketi n+1, n+2 itd. Sprejemnik nenehno prejema pakete in pošilja pakete ACK, ki sporočajo, da sprejemnik še vedno čaka na n-ti paket. Prejemnik pošilja ponavljajoče se ali podvojene potrditve. V zgornjem primeru se ACK paketa 1 pošlje trikrat, ker je bil paket 2 izgubljen. Ta podvojeni paket ACK je znak, da n-ti paket manjka, vendar so prejeti kasnejši paketi.

Zgornjo situacijo je mogoče rešiti na naslednje načine:

• Pošiljatelj lahko 'podvojene ACK-je' vzame kot zgodnji namig, da je bil n-ti paket izgubljen, tako da lahko pošiljatelj opravi ponovni prenos čim prej, tj. pošiljatelj ne bi smel čakati, da nastopi časovna omejitev.
• Pošiljatelj lahko implementira strategijo hitrega prenosa v TCP. Pri strategiji hitrega prenosa mora pošiljatelj upoštevati trojne dvojnike ACK kot sprožilec in jih ponovno poslati.

TCP uporabi tri podvojene ACK-je kot sprožilec in nato izvede ponoven prenos. V zgornjem primeru, ko so prejeti trije ACK paketa 1, mora pošiljatelj poslati izgubljeni paket, tj. paket 2, ne da bi čakal, da nastopi časovna omejitev.