Opakovaný přenos TCP znamená opětovné odeslání paketů po síti, které byly ztraceny nebo poškozeny. Zde je retransmise mechanismus používaný protokoly jako např TCP poskytovat spolehlivou komunikaci. Spolehlivá komunikace zde znamená, že protokol zaručuje doručení paketu i v případě ztráty nebo poškození datového paketu.
primární klíč složený klíč
Sítě jsou nespolehlivé a nezaručují zpoždění nebo opětovné odeslání ztracených nebo poškozených paketů. Síť, která využívá kombinaci potvrzení a opětovného přenosu poškozených nebo ztracených paketů, nabízí spolehlivost.
Mechanismus opětovného přenosu
Zde opakovaný přenos znamená, že datové pakety byly ztraceny, což vede k nedostatečnému potvrzení. Tento nedostatek potvrzení spouští časovač do vypršení časového limitu, což vede k opětovnému přenosu datových paketů. Časovač zde znamená, že pokud není přijato žádné potvrzení před vypršením časovače, je datový paket znovu odeslán.
Uvažujme následující scénáře opětovného přenosu.
Scénář 1: Když se datový paket ztratí nebo je chybný.
V tomto scénáři je paket odeslán příjemci, ale během tohoto časového limitu není přijato žádné potvrzení. Po vypršení časového limitu je paket znovu odeslán. Když je paket znovu odeslán, je přijato potvrzení. Jakmile je potvrzení přijato, k opakovanému přenosu již nedojde.
Scénář 2: Když je paket přijat, ale potvrzení je ztraceno.
V tomto scénáři je paket přijat na druhé straně, ale potvrzení je ztraceno, tj. ACK není přijato na straně odesílatele. Po vypršení časového limitu je paket odeslán znovu. Na druhé straně jsou dvě kopie paketů; ačkoli je paket přijat správně, potvrzení není přijato, takže odesílatel paket odešle znovu. V tomto případě bylo možné se opětovnému přenosu vyhnout, ale kvůli ztrátě ACK je paket znovu odeslán.
Scénář 3: Když nastane předčasný časový limit.
V tomto scénáři je paket odeslán, ale kvůli zpoždění v potvrzení nebo vypršení časového limitu, který nastal před skutečným časovým limitem, je paket znovu odeslán. V tomto případě byl paket znovu odeslán zbytečně z důvodu zpoždění potvrzení nebo byl timeout nastaven dříve, než je skutečný timeout.
Ve výše uvedených scénářích se nelze vyhnout prvnímu scénáři, ale dalším dvěma scénářům se lze vyhnout. Pojďme se podívat, jak se můžeme těmto situacím vyhnout.
Jak dlouho by měl odesílatel čekat?
Odesílatel nastaví časový limit pro ACK. Časový limit může být dvou typů:
náhodné číslo gen java
Aby bylo možné překonat dvě výše uvedené situace, TCP nastavuje časový limit jako funkci RTT (doba zpáteční cesty), kde doba zpáteční cesty je doba potřebná k tomu, aby paket prošel ze zdroje do cíle a pak se znovu vrátil.
Jak můžeme získat RTT?
RTT se může lišit v závislosti na charakteristikách sítě, tj. pokud je síť přetížená, znamená to, že RTT je velmi vysoká. RTT můžeme odhadnout pouhým sledováním ACK.
Podívejme se, jak můžeme měřit RTT.
Budeme používat původní algoritmus k měření RTT.
Krok 1: Nejprve změříme UkázkaRTT pro každý segment nebo ACK pár. Když odesílatel odešle paket, pak známe časovač, ve kterém je paket odeslán, a také známe časovač, ve kterém je přijato potvrzení. Vypočítejte čas mezi těmito dvěma, a to se stane UkázkaRTT .
Krok 2: Nebudeme odebírat pouze jeden vzorek. Budeme pokračovat v odebírání různých vzorků a vypočítávat vážený průměr těchto vzorků, z čehož se stane EstRTT (Estimated RTT).
kde α+ β = 1
α leží mezi 0,8 a 0,9
β leží mezi 0,1 a 0,2
Krok 3: Časový limit je nastaven na základě EstRTT.
časový limit = 2 * EstRTT.
java celé číslo na řetězec
Časový limit je nastaven na dvojnásobek odhadovaného RTT. Takto se vypočítá faktor skutečného časového limitu.
Chyba v tomto přístupu
V původním algoritmu je chyba. Uvažujme dva scénáře.
Scénář 1.
Výše uvedený diagram ukazuje, že odesílatel odesílá data, což je považováno za původní přenos. Během časového limitu není přijato žádné potvrzení. Odesílatel tedy odešle data znovu. Po opětovném přenosu dat je přijato potvrzení. Předpokládejme, že potvrzení je přijato pro původní přenos, nikoli pro opakovaný přenos. Vzhledem k tomu, že dostaneme potvrzení o původním přenosu, tak UkázkaRTT se počítá mezi časem původního přenosu a časem, kdy je přijato potvrzení. Ale ve skutečnosti, UkázkaRTT měla být mezi časem opětovného přenosu a časem potvrzení.
Scénář 2
Výše uvedený diagram ukazuje, že odesílatel posílá původní datový paket, pro který dostáváme také potvrzení. Ale potvrzení je přijato po opětovném přenosu dat. Pokud předpokládáme, že potvrzení patří k opakovanému přenosu, pak UkázkaRTT se počítá mezi časem opětovného přenosu a časem potvrzení.
V obou výše uvedených scénářích je nejasné, že není známo, zda je potvrzení pro původní přenos nebo pro opakovaný přenos.
Závěr výše uvedeného algoritmu.
- Zde ACK neznamená potvrzení přenosu, ale ve skutečnosti potvrzuje příjem dat.
- Pokud vezmeme v úvahu první scénář, opakovaný přenos se provede pro ztracený paket. V tomto případě předpokládáme, že ACK patří k původnímu přenosu, díky kterému je SampleRTT velmi velký.
- Pokud vezmeme v úvahu druhý scénář, jsou odeslány dva stejné pakety, takže v tomto případě dochází k duplicitě. V tomto případě předpokládáme, že ACK patří k opakovanému přenosu, díky kterému bude SampleRTT velmi malý.
K překonání výše uvedených problémů poskytuje jednoduché řešení Karn/Partridge algoritmus. Tento algoritmus poskytuje jednoduché řešení, které shromažďuje odeslané vzorky najednou a nebere v úvahu vzorky v čase opětovného přenosu pro výpočet odhadovaného RTT.
Algoritmus Karn/Partridge
Ve dvou výše uvedených scénářích dochází k opakovanému přenosu a my jsme uvažovali o vzorovém RTT. Ale tento algoritmus nebere v úvahu vzorový RTT při opakovaném přenosu. Vzhledem k tomu, že došlo k opakovanému přenosu, což znamená, že se něco stane v tomto zpátečním čase nebo může dojít k přetížení sítě. K překonání tohoto problému tento algoritmus zdvojnásobuje časový limit po každém opakovaném přenosu. Tento algoritmus je implementován v síti TCP.
Omezení
Nezohledňuje rozptyl v RTT.
K překonání výše uvedeného omezení byl vyvinut Jacobson/Karelsův algoritmus, který zavádí variační faktor v RTT.
Jacobsonův/Karelsův algoritmus
připojit k databázi java
Tento algoritmus byl vyvinut k překonání omezení Karn/Partridge algoritmus. Vypočítá rozdíl mezi SampleRTT a EstimatedRTT a na základě tohoto rozdílu zvýší RTT.
Výpočty pro průměrnou RTT
- Nejprve vypočítáme rozdílový faktor.
Rozdíl = SampleRTT - Odhadovaný RTT
- Nyní vypočítáme EstimatedRTT, která bude vypočítána stejným způsobem jako výše.
EstRTT = EstRTT + (δ*Diff)
- Nyní vypočítáme průměr rozdílového faktoru.
Dev = Dev + δ ( |Diff| - Dev)
if else příkazy java
Zde je Dev faktor odchylky a δ je faktor mezi 0 a 1. The Dev je odhad rozptylu od EstRTT .
- Při výpočtu hodnoty časového limitu budeme uvažovat rozptyl.
Kde, µ = 1 a ɸ = 4
Rychlý přenos
Strategie opětovného přenosu založená na časovém limitu je neefektivní. TCP je protokol s posuvným oknem, takže kdykoli dojde k opakovanému přenosu, začne jej odesílat od ztraceného paketu dále.
Předpokládejme, že přenáším pakety 0, 1, 2 a 3. Protože paket 0 a paket 1 jsou přijímány na druhé straně, paket 2 je v síti ztracen. Obdržel jsem potvrzení o paketu 0 a paketu 1, takže posílám další dva pakety, tj. paket 4 a paket 5. Když jsou odeslány pakety 3, 4 a 5, obdržím potvrzení paketu 1 jako potvrzení TCP jsou kumulativní, takže potvrdí až paket, že přijal v pořádku. Neobdržel jsem potvrzení o paketu 2, 3, 4 a 5 v časovém limitu, takže znovu odesílám pakety 2, 3, 4 a 5. Protože paket 2 je ztracen, ale další pakety, tj. 3, 4 ,5 jsou přijímány na druhé straně, jsou stále znovu vysílány kvůli tomuto mechanismu timeoutu.
Jak lze tuto neefektivnost časového limitu odstranit?
Lepší řešení pod posuvným oknem:
Předpokládejme, že n paketů bylo ztraceno, ale přesto byly přijaty pakety n+1, n+2 a tak dále. Přijímač nepřetržitě přijímá pakety a odesílá ACK pakety s tím, že přijímač stále čeká na n-tý paket. Příjemce posílá opakovaná nebo duplicitní potvrzení. Ve výše uvedeném případě je ACK paketu 1 odesláno třikrát, protože paket 2 byl ztracen. Tento duplicitní ACK paket znamená, že n-tý paket chybí, ale jsou přijaty pozdější pakety.
Výše uvedenou situaci lze vyřešit následujícími způsoby:
- Odesílatel může brát 'duplicitní ACK' jako včasnou nápovědu, že n-tý paket byl ztracen, takže odesílatel může provést opakovaný přenos co nejdříve, tj. odesílatel by neměl čekat, dokud nenastane časový limit.
- Odesílatel může implementovat strategii rychlého přenosu v TCP. Ve strategii rychlého přenosu by měl odesílatel považovat trojité duplicitní ACK za spouštěcí událost a znovu je odeslat.
TCP používá tři duplicitní potvrzení ACK jako spouštěč a poté provede opakovaný přenos. Ve výše uvedeném případě, když jsou přijata tři potvrzení ACK paketu 1, pak by měl odesílatel poslat ztracený paket, tj. paket 2, aniž by čekal, než nastane časový limit.