Повторното предаване на TCP означава повторно изпращане на пакетите по мрежата, които са или изгубени, или повредени. Тук повторното предаване е механизъм, използван от протоколи като напр TCP за осигуряване на надеждна комуникация. Тук надеждната комуникация означава, че протоколът гарантира доставката на пакета, дори ако пакетът с данни е бил изгубен или повреден.
java списък празен
Мрежите са ненадеждни и не гарантират забавяне или повторно предаване на изгубени или повредени пакети. Мрежата, която използва комбинация от потвърждение и повторно предаване на повредени или изгубени пакети, предлага надеждност.
Механизъм за препредаване
Тук повторното предаване означава, че пакетите с данни са били загубени, което води до липса на потвърждение. Тази липса на потвърждение задейства таймер за изчакване, което води до повторно предаване на пакети с данни. Тук таймерът означава, че ако не бъде получено потвърждение преди изтичането на таймера, пакетът данни се предава повторно.
Нека разгледаме следните сценарии на препредаване.
Сценарий 1: Когато пакетът данни е загубен или е грешен.
В този сценарий пакетът се изпраща до получателя, но не се получава потвърждение в рамките на този период на изчакване. Когато периодът на изчакване изтече, пакетът се изпраща отново. При повторно предаване на пакета се получава потвърждението. След като бъде получено потвърждението, повторното предаване няма да се извърши отново.
Сценарий 2: Когато пакетът е получен, но потвърждението е загубено.
В този сценарий пакетът се получава от другата страна, но потвърждението се губи, т.е. ACK не се получава от страната на подателя. След като периодът на изчакване изтече, пакетът се изпраща повторно. От другата страна има две копия на пакетите; въпреки че пакетът е получен правилно, потвърждението не е получено, така че подателят препредава пакета. В този случай повторното предаване можеше да бъде избегнато, но поради загубата на ACK, пакетът се предава повторно.
Сценарий 3: Когато настъпи ранното изчакване.
В този сценарий пакетът се изпраща, но поради забавянето на потвърждението или изчакването е настъпило преди действителното изчакване, пакетът се предава повторно. В този случай пакетът е изпратен отново ненужно поради забавянето на потвърждението или времето за изчакване е зададено по-рано от действителното изчакване.
В горните сценарии първият сценарий не може да бъде избегнат, но другите два сценария могат да бъдат избегнати. Нека да видим как можем да избегнем тези ситуации.
Колко време трябва да чака подателят?
Подателят задава периода на изчакване за ACK. Периодът на изчакване може да бъде два вида:
За да преодолеете горните две ситуации, TCP задава времето за изчакване като функция на RTT (време за двупосочно пътуване), където времето за двупосочно пътуване е времето, необходимо на пакета да пътува от източника до дестинацията и след това да се върне отново.
Как можем да получим RTT?
RTT може да варира в зависимост от характеристиките на мрежата, т.е. ако мрежата е претоварена, това означава, че RTT е много висок. Можем да оценим RTT, като просто наблюдаваме ACK.
Нека видим как можем да измерим RTT.
Ние ще използваме оригинален алгоритъм за измерване на RTT.
Етап 1: Първо измерваме SampleRTT за всеки сегмент или ACK двойка. Когато изпращачът изпрати пакета, ние знаем таймера, при който пакетът е изпратен, и също така знаем таймера, при който е получено потвърждението. Изчислете времето между тези две и това става SampleRTT .
Стъпка 2: Няма да вземем само една проба. Ще продължим да вземаме различни проби и ще изчисляваме среднопретеглената стойност на тези проби и това се превръща в EstRTT (Прогнозно RTT).
където α+ β = 1
свързан списък java
α е между 0,8 и 0,9
β е между 0,1 и 0,2
Стъпка 3: Времето за изчакване се задава въз основа на EstRTT.
изчакване = 2 * EstRTT.
Времето за изчакване е настроено да бъде два пъти очакваното RTT. Ето как се изчислява действителният коефициент на изчакване.
Грешка в този подход
Има грешка в оригиналния алгоритъм. Нека разгледаме два сценария.
Сценарий 1.
ако иначе java
Горната диаграма показва, че изпращачът изпраща данните, които се наричат оригинално предаване. В рамките на периода на изчакване не е получено потвърждение. И така, изпращачът препредава данните. След повторно предаване на данните се получава потвърждението. Да приемем, че е получено потвърждение за първоначалното предаване, а не за повторното предаване. След като получихме потвърждението за оригиналното предаване, значи SampleRTT се изчислява между момента на първоначалното предаване и момента, в който е получено потвърждението. Но всъщност, SampleRTT трябва да е между времето на повторното предаване и времето на потвърждението.
Сценарий 2.
Горната диаграма показва, че изпращачът изпраща оригиналния пакет данни, за който получаваме и потвърждението. Но потвърждението се получава след повторно предаване на данните. Ако приемем, че потвърждението принадлежи на повторното предаване, тогава SampleRTT се изчислява между времето на повторното предаване и времето на потвърждението.
И в горните два сценария има неяснота да не се знае дали потвърждението е за първоначалното предаване или за повторното предаване.
Заключение на горния алгоритъм.
- Тук ACK не означава потвърждаване на предаване, но всъщност потвърждава получаването на данните.
- Ако разгледаме първия сценарий, повторното предаване се извършва за изгубения пакет. В този случай ние приемаме, че ACK принадлежи на оригиналното предаване, поради което SampleRTT излиза много голям.
- Ако разгледаме втория сценарий, два еднакви пакета се изпращат, така че в този случай възниква дублиране. В този случай ние приемаме, че ACK принадлежи на повторното предаване, поради което SampleRTT става много малък.
За да се преодолеят горните проблеми, е дадено просто решение от алгоритъма Karn/Partridge. Този алгоритъм даде просто решение, което събира пробите, изпратени наведнъж и не взема предвид пробите по време на повторното предаване за изчисляване на прогнозния RTT.
Алгоритъм Karn/Partridge
В горните два сценария възниква повторно предаване и ние разгледахме примерния RTT. Но този алгоритъм не взема предвид Sample RTT при повторно предаване. Тъй като повторното предаване е настъпило, което означава, че нещо се случва в това време за двупосочно пътуване или може да възникне известно задръстване в мрежата. За да преодолее този проблем, този алгоритъм удвоява времето за изчакване след всяко повторно предаване. Този алгоритъм е реализиран в TCP мрежата.
Ограничение
Не отчита вариацията в RTT.
За да се преодолее горното ограничение, беше разработен алгоритъмът на Jacobson/Karels, който въвежда фактора на вариация в RTT.
Алгоритъм на Джейкъбсън/Карелс
Този алгоритъм е разработен, за да се преодолее ограничението на Карн/Яребица алгоритъм. Той изчислява разликата между SampleRTT и EstimatedRTT и увеличава RTT въз основа на разликата.
unix горна команда
Изчисления за средна RTT
- Първо, изчисляваме коефициента на разликата.
Diff = SampleRTT - EstimatedRTT
- Сега изчисляваме EstimatedRTT, който ще бъде изчислен по същия начин, както направихме по-горе.
EstRTT = EstRTT + (δ*Разл.)
- Сега изчисляваме средната стойност на фактора на разликата.
Dev = Dev + δ ( |Diff| - Dev)
Тук Dev е фактор на отклонение, а δ е фактор между 0 и 1. The Dev е оценка на дисперсията от EstRTT .
- Ще вземем предвид дисперсията, докато изчисляваме стойността на времето за изчакване.
Където, µ =1 и ɸ =4
Бързо препредаване
Базираната на изчакване стратегия за повторно предаване е неефективна. TCP е вид протокол с плъзгащ се прозорец, така че когато се случи повторно предаване, той започва да го изпраща от изгубения пакет нататък.
jfx java урок
Да предположим, че предавам пакетите 0, 1, 2 и 3. Тъй като пакет 0 и пакет 1 се получават от другата страна, пакет 2 се губи в мрежата. Получих потвърждението за пакет 0 и пакет 1, така че изпращам още два пакета, т.е. пакет 4 и пакет 5. Когато бъдат изпратени пакети 3, 4 и 5, тогава ще получа потвърждението за пакет 1 като TCP потвърждения са кумулативни, така че той признава до пакета, който е получил по ред. Не съм получил потвърждението за пакет 2, 3, 4 и 5 в рамките на периода на изчакване, така че предавам повторно пакетите 2, 3, 4 и 5. Тъй като пакет 2 е загубен, но други пакети, т.е. 3, 4 ,5 са получени от другата страна, те все още се препредават поради този механизъм за изчакване.
Как може да се отстрани тази неефективност при изчакване?
По-доброто решение под плъзгащ се прозорец:
Да предположим, че n пакет е бил загубен, но все пак пакетите n+1, n+2 и т.н. са получени. Получателят непрекъснато получава пакетите и изпраща ACK пакетите, казвайки, че приемникът все още чака n-тия пакет. Получателят изпраща повтарящи се или дублирани потвърждения. В горния случай ACK на пакет 1 се изпраща три пъти, тъй като пакет 2 е изгубен. Този дублиран ACK пакет е индикация, че n-тият пакет липсва, но по-късните пакети са получени.
Горната ситуация може да бъде разрешена по следните начини:
- Изпращачът може да приеме „дублираните ACK“ като ранен намек, че n-тият пакет е загубен, така че изпращачът да може да извърши повторното предаване възможно най-рано, т.е. подателят не трябва да чака, докато настъпи времето за изчакване.
- Подателят може да приложи стратегия за бързо предаване в TCP. При стратегия за бързо предаване подателят трябва да разглежда тройните дублирани ACK като тригер и да го препредаде.
TCP използва три дублирани ACK като тригер и след това извършва повторно предаване. В горния случай, когато са получени три ACK на пакет 1, изпращачът трябва да изпрати изгубения пакет, т.е. пакет 2, без да чака да настъпи периодът на изчакване.