Retransmisja TCP oznacza ponowne wysłanie przez sieć pakietów, które zostały utracone lub uszkodzone. W tym przypadku retransmisja jest mechanizmem używanym przez protokoły takie jak TCP aby zapewnić niezawodną komunikację. W tym przypadku niezawodna komunikacja oznacza, że protokół gwarantuje dostarczenie pakietu nawet w przypadku jego utraty lub uszkodzenia.
uzyskaj aktualną datę w Javie
Sieci te są zawodne i nie gwarantują opóźnienia ani retransmisji utraconych lub uszkodzonych pakietów. Sieć wykorzystująca kombinację potwierdzenia i retransmisji uszkodzonych lub utraconych pakietów zapewnia niezawodność.
Mechanizm retransmisji
W tym przypadku retransmisja oznacza utratę pakietów danych, co prowadzi do braku potwierdzenia. Brak potwierdzenia powoduje przekroczenie limitu czasu, co prowadzi do ponownej transmisji pakietów danych. W tym przypadku licznik czasu oznacza, że jeśli przed upływem czasu licznika nie zostanie odebrane potwierdzenie, pakiet danych zostanie ponownie przesłany.
Rozważmy następujące scenariusze retransmisji.
Scenariusz 1: Gdy pakiet danych zostanie utracony lub błędny.
W tym scenariuszu pakiet jest wysyłany do odbiorcy, ale w tym okresie limitu czasu nie zostaje odebrane żadne potwierdzenie. Po upływie limitu czasu pakiet jest wysyłany ponownie. Po retransmisji pakietu odbierane jest potwierdzenie. Po otrzymaniu potwierdzenia retransmisja nie będzie już powtarzana.
Scenariusz 2: Gdy pakiet został odebrany, ale potwierdzenie zostało utracone.
W tym scenariuszu pakiet jest odbierany po drugiej stronie, ale potwierdzenie zostaje utracone, tj. potwierdzenie nie zostało odebrane po stronie nadawcy. Po upływie limitu czasu pakiet jest wysyłany ponownie. Po drugiej stronie znajdują się dwie kopie pakietów; chociaż pakiet został odebrany poprawnie, potwierdzenie nie zostało odebrane, więc nadawca ponownie przesyła pakiet. W tym przypadku można było uniknąć retransmisji, lecz z powodu utraty potwierdzenia ACK pakiet zostaje ponownie przesłany.
Scenariusz 3: Kiedy nastąpi wcześniejszy przekroczenie limitu czasu.
W tym scenariuszu pakiet zostaje wysłany, ale ze względu na opóźnienie w potwierdzeniu lub przekroczenie limitu czasu przed faktycznym upływem limitu czasu pakiet jest ponownie przesyłany. W tym przypadku pakiet został niepotrzebnie wysłany ponownie ze względu na opóźnienie w potwierdzeniu lub ustawiono wcześniejszy limit czasu niż rzeczywisty.
W powyższych scenariuszach nie można uniknąć pierwszego scenariusza, ale można uniknąć dwóch pozostałych. Zobaczmy, jak możemy uniknąć takich sytuacji.
Jak długo nadawca powinien czekać?
Nadawca ustawia limit czasu dla potwierdzenia. Limit czasu może być dwojakiego rodzaju:
Aby przezwyciężyć powyższe dwie sytuacje, TCP ustawia limit czasu jako funkcję RTT (czas podróży w obie strony), gdzie czas podróży w obie strony to czas potrzebny pakietowi na podróż od źródła do miejsca docelowego, a następnie powrót.
Jak możemy uzyskać RTT?
Wartość RTT może się różnić w zależności od charakterystyki sieci, tzn. jeśli sieć jest przeciążona, oznacza to, że wartość RTT jest bardzo wysoka. Możemy oszacować RTT, po prostu obserwując potwierdzenia ACK.
Zobaczmy, jak możemy zmierzyć RTT.
Będziemy korzystać z oryginalny algorytm do pomiaru RTT.
Krok 1: Najpierw mierzymy PróbkaRTT dla każdego segmentu lub pary ACK. Kiedy nadawca wysyła pakiet, znamy licznik czasu, o którym pakiet został wysłany, a także znamy licznik czasu, po którym otrzymano potwierdzenie. Oblicz czas pomiędzy tymi dwoma momentami i otrzymamy wynik PróbkaRTT .
rotacja drzewa avl
Krok 2: Nie pobierzemy tylko jednej próbki. Będziemy nadal pobierać różne próbki i obliczać średnią ważoną tych próbek, a to stanie się EstRTT (szacowany RTT).
gdzie, α+ β = 1
α leży pomiędzy 0,8 a 0,9
β mieści się w przedziale od 0,1 do 0,2
Krok 3: Limit czasu jest ustawiany na podstawie EstRTT.
limit czasu = 2 * EstRTT.
Limit czasu jest ustawiony na dwukrotność szacowanego RTT. W ten sposób obliczany jest rzeczywisty współczynnik limitu czasu.
Wada w tym podejściu
W oryginalnym algorytmie jest błąd. Rozważmy dwa scenariusze.
rajesh Khanna
Scenariusz 1.
Z powyższego diagramu wynika, że nadawca wysyła dane, co nazywa się transmisją oryginalną. W ciągu limitu czasu nie zostanie odebrane żadne potwierdzenie. Zatem nadawca retransmituje dane. Po ponownym przesłaniu danych następuje potwierdzenie. Załóżmy, że otrzymano potwierdzenie dla pierwotnej transmisji, a nie dla retransmisji. Ponieważ otrzymaliśmy potwierdzenie oryginalnej transmisji, tzw PróbkaRTT liczony jest pomiędzy momentem pierwotnej transmisji a momentem otrzymania potwierdzenia. Ale właściwie, PróbkaRTT powinien przypadać pomiędzy momentem retransmisji a momentem potwierdzenia.
Scenariusz 2.
Z powyższego diagramu wynika, że nadawca wysyła oryginalny pakiet danych, za co również otrzymujemy potwierdzenie. Potwierdzenie następuje jednak po ponownym przesłaniu danych. Jeśli przyjmiemy, że potwierdzenie należy do retransmisji, to PróbkaRTT liczony jest pomiędzy momentem retransmisji a momentem potwierdzenia.
W obu powyższych scenariuszach istnieje niejasność polegająca na tym, że nie wiadomo, czy potwierdzenie dotyczy pierwotnej transmisji, czy retransmisji.
Wniosek z powyższego algorytmu.
- W tym przypadku ACK nie oznacza potwierdzenia transmisji, ale w rzeczywistości potwierdza odbiór danych.
- Jeśli weźmiemy pod uwagę pierwszy scenariusz, retransmisja odbywa się za utracony pakiet. W tym przypadku zakładamy, że ACK należy do oryginalnej transmisji, przez co SampleRTT okazuje się być bardzo duży.
- Jeśli weźmiemy pod uwagę drugi scenariusz, wysyłane są dwa takie same pakiety, więc w tym przypadku występuje duplikacja. W tym przypadku zakładamy, że ACK należy do retransmisji, przez co SampleRTT staje się bardzo mały.
Aby przezwyciężyć powyższe problemy, prostym rozwiązaniem jest algorytm Karna/Partridge'a. Algorytm ten dał proste rozwiązanie, które zbiera próbki wysłane w jednym czasie i nie uwzględnia próbek w czasie retransmisji do obliczenia szacowanego RTT.
Algorytm Karna/Kuropatwy
W powyższych dwóch scenariuszach ma miejsce retransmisja i rozważyliśmy przykładowy RTT. Ale ten algorytm nie uwzględnia przykładowego RTT podczas retransmisji. Ponieważ nastąpiła retransmisja, co oznacza, że w tym czasie w obie strony coś się wydarzy lub w sieci mogą wystąpić pewne przeciążenia. Aby przezwyciężyć ten problem, algorytm ten podwaja limit czasu po każdej retransmisji. Algorytm ten jest zaimplementowany w sieci TCP.
Ograniczenie
Nie uwzględnia wariancji w RTT.
tablica kodów c zawierająca ciągi znaków
Aby przezwyciężyć powyższe ograniczenie, opracowano algorytm Jacobsona/Karelsa, który wprowadza współczynnik wariancji w RTT.
Algorytm Jacobsona/Karelsa
Algorytm ten został opracowany w celu przezwyciężenia ograniczeń Karn/Kopatwa algorytm. Oblicza różnicę między SampleRTT i EstimatedRTT i zwiększa RTT na podstawie różnicy.
Obliczenia dla średniego RTT
- Najpierw obliczamy współczynnik różnicy.
Różn. = PróbkaRTT — szacunkowyRTT
- Teraz obliczamy szacunkowy RTT, który zostanie obliczony w taki sam sposób, jak zrobiliśmy to powyżej.
EstRTT = EstRTT + (δ*różnica)
- Teraz obliczamy średnią współczynnika różnicy.
Dev = Dev + δ ( |Różnica| - Dev)
Tutaj Dev jest współczynnikiem odchylenia, a δ jest czynnikiem z zakresu od 0 do 1. The Rozw jest oszacowaniem wariancji z EstRTT .
- Rozważymy tę wariancję podczas obliczania wartości limitu czasu.
Gdzie, µ =1 i ɸ =4
poradnik hadoopa
Szybka retransmisja
Strategia retransmisji oparta na przekroczeniu limitu czasu jest nieefektywna. TCP jest protokołem typu przesuwane okno, więc za każdym razem, gdy nastąpi retransmisja, rozpoczyna się wysyłanie go dalej od utraconego pakietu.
Załóżmy, że transmituję pakiety 0, 1, 2 i 3. Ponieważ pakiet 0 i pakiet 1 są odbierane po drugiej stronie, pakiet 2 zostaje utracony w sieci. Otrzymałem potwierdzenie pakietów 0 i pakietu 1, więc wysyłam jeszcze dwa pakiety, tj. pakiet 4 i pakiet 5. Kiedy pakiety 3, 4 i 5 zostaną wysłane, otrzymam potwierdzenie pakietu 1 jako potwierdzenia TCP kumulują się, więc potwierdza aż do pakietu, który otrzymał w określonej kolejności. Nie otrzymałem potwierdzenia pakietów 2, 3, 4 i 5 w określonym czasie, więc ponownie wysyłam pakiety 2, 3, 4 i 5. Ponieważ pakiet 2 został utracony, ale inne pakiety, tj. 3, 4 ,5 są odbierane po drugiej stronie, nadal są retransmitowane ze względu na mechanizm przekroczenia limitu czasu.
Jak można usunąć tę nieefektywność przekroczenia limitu czasu?
Lepsze rozwiązanie pod oknem przesuwnym:
Załóżmy, że n pakietów zostało utraconych, ale mimo to odebrane zostały pakiety n+1, n+2 itd. Odbiorca w sposób ciągły odbiera pakiety i wysyła pakiety ACK, mówiąc, że nadal oczekuje na n-ty pakiet. Odbiorca wysyła powtarzające się lub zduplikowane potwierdzenia. W powyższym przypadku potwierdzenie pakietu 1 jest wysyłane trzykrotnie, gdy pakiet 2 został utracony. Ten zduplikowany pakiet ACK wskazuje, że brakuje n-tego pakietu, ale odebrane zostały kolejne pakiety.
Powyższą sytuację można rozwiązać w następujący sposób:
- Nadawca może potraktować „zduplikowane potwierdzenia” jako wczesną wskazówkę, że n-ty pakiet został utracony, aby nadawca mógł dokonać retransmisji tak wcześnie, jak to możliwe, tj. nadawca nie powinien czekać do upłynięcia limitu czasu.
- Nadawca może wdrożyć strategię szybkiej transmisji w protokole TCP. W strategii szybkiej transmisji nadawca powinien uznać potrójne zduplikowane potwierdzenia ACK za wyzwalacz i przesłać je ponownie.
TCP wykorzystuje trzy zduplikowane potwierdzenia ACK jako wyzwalacz, a następnie wykonuje retransmisję. W powyższym przypadku, gdy zostaną odebrane trzy potwierdzenia pakietu 1, nadawca powinien wysłać utracony pakiet, czyli pakiet 2, nie czekając na upłynięcie limitu czasu.