Retransmisja TCP vs. Szybka retransmisja TCP

W Wireshark widzę słowa „retransmisja TCP” i „szybka retransmisja TCP”. Co za różnica? W jaki sposób Wireshark jest w stanie odróżnić?

Gdy pakiet jest wysyłany za pomocą protokołu TCP, przesyłany jest z nim numer sekwencyjny. Kiedy odbiorca odbiera pakiet, wysyła do nadawcy potwierdzenie z numerem sekwencyjnym wskazującym, że pakiet został odebrany. Biorąc pod uwagę sposób, w jaki zadałeś pytanie, zakładam, że o tym wiesz. Chciałem umieścić go dla innych czytelników.

Retransmisja TCP to tylko pakiet, który nie potwierdza się po upływie limitu czasu.

Szybka retransmisja TCP następuje, gdy źródło otrzymuje potwierdzenie, że pakiet nie został odebrany ... cytując z Fast retransmit - Wikipedia, wolna encyklopedia

jeśli nadawca TCP otrzyma trzy zduplikowane potwierdzenia z tym samym numerem potwierdzenia (to znaczy w sumie cztery potwierdzenia z tym samym numerem potwierdzenia), nadawca może mieć wystarczającą pewność, że segment o kolejnym wyższym numerze kolejny został usunięty

Przetrawiłem to z Microsoft :

TCP uruchamia licznik czasu retransmisji, gdy każdy segment wychodzący jest przekazywany do warstwy protokołu internetowego (IP). Jeśli TCP nie otrzyma potwierdzenia danych w danym segmencie przed upływem czasu, segment jest retransmitowany.

Limit czasu retransmisji jest dostosowywany w locie, aby pasował do charakterystyk połączenia, przy użyciu obliczeń wygładzonego czasu podróży w obie strony (SRTT), jak opisano w dokumencie Van Jacobsona i Mike'a Karelsa „Unikanie i kontrola zatorów” w materiałach z konferencji ACM SIGCOMM w sprawie transmisji danych, listopad 1988 r. Artykuł ten można znaleźć w Cyfrowej Bibliotece ACM w Association for Computing Machinery. Aby uzyskać więcej informacji na temat obliczeń SRTT, patrz RFC 793: Protokół kontroli transmisji DARPA Specyfikacja protokołu internetowego . Limit czasu retransmisji dla danego segmentu jest podwojony po każdej retransmisji tego segmentu.

Korzystając z tego algorytmu, TCP dostraja się do zwykłego opóźnienia połączenia. Połączenia TCP przez łącza o dużym opóźnieniu wymagają znacznie dłuższego czasu niż połączenia przez łącza o niskim opóźnieniu, aby uniknąć niepoprawnego przekroczenia limitu czasu, gdy połączenie jest jedynie powolne, a nie obecne.

W niektórych okolicznościach TCP retransmituje dane przed upływem czasu retransmisji określonego segmentu. Najczęstsza taka okoliczność występuje z powodu funkcji znanej jako szybka retransmisja.

Gdy odbiornik obsługujący szybką retransmisję odbiera pakiet o numerze sekwencyjnym wyższym niż oczekiwany, postępuje tak, jakby niektóre dane zostały upuszczone. Aby pomóc nadawcy w jak najszybszym uświadomieniu sobie pozornie upuszczonych danych, odbiorca natychmiast wysyła potwierdzenie (ACK), z numerem ACK ustawionym na numer kolejny, który wydaje się brakować. Odbiornik wysyła kolejne ACK dla tego numeru sekwencyjnego dla każdego dodatkowego segmentu TCP w strumieniu przychodzącym, który przybywa z numerem sekwencyjnym wyższym niż brakujący.

Gdy nadawca otrzyma strumień duplikatów ACK, które potwierdzają ten sam numer sekwencji, a wskazany numer sekwencji jest wcześniejszy niż numer sekwencji wysyłanego bieżącego segmentu, nadawca może wywnioskować, że jeden lub więcej segmentów, które wcześniej wysłał, zostało odrzuconych. Po otrzymaniu pewnej liczby zduplikowanych ACK nadawcy, którzy obsługują algorytm szybkiego retransmisji, ponownie wysyłają segment lub segmenty, o które odbiorca prosi o wypełnienie luki w danych, bez oczekiwania na upływ czasu timera retransmisji dla brakujących segmentów. Ta optymalizacja znacznie poprawia wydajność w ruchliwym środowisku sieciowym.

Dzięki szybkiej retransmitacji nadawca ponownie przesyła brakujące segmenty TCP, zanim upłyną ich liczniki czasu retransmisji. Ponieważ liczniki czasu retransmisji nie wygasły dla brakujących segmentów TCP, brakujące segmenty są odbierane w miejscu docelowym i potwierdzane przez odbiorcę szybciej niż byłyby bez szybkiej retransmisji, a nadawca może szybciej wysyłać późniejsze segmenty do odbiornika. Ten proces jest znany jako szybkie odzyskiwanie. Szybka retransmisja i szybkie odzyskiwanie są opisane w RFC 2581: Kontrola przeciążenia TCP .

Retransmisja, zasadniczo identyczna z automatycznym żądaniem powtórzenia (ARQ), to ponowne wysyłanie pakietów, które zostały uszkodzone lub utracone. Jest to termin odnoszący się do jednego z podstawowych mechanizmów wykorzystywanych przez protokoły działające w sieci komputerowej z komutacją pakietów w celu zapewnienia niezawodnej komunikacji. ALE Fast Retransmit jest rozszerzeniem TCP, które skraca czas oczekiwania nadawcy przed retransmisją utraconego segmentu. Ulepszenie szybkiego retransmitowania działa w następujący sposób: jeśli nadawca TCP odbiera określoną liczbę potwierdzeń, która jest zwykle ustawiona na trzy duplikaty potwierdzeń z tym samym numer potwierdzenia (czyli w sumie cztery potwierdzenia o tym samym numerze potwierdzenia), nadawca może mieć wystarczającą pewność, że segment o kolejnym wyższym numerze został odrzucony i nie przybędzie poza kolejnością. Nadawca ponownie wyśle ​​pakiet, który został uznany za odrzucony, zanim czeka na przekroczenie limitu czasu. sprawdź ten link, aby uzyskać więcej informacji i algorytm http://www.isi.edu/nsnam/DIRECTED_RESEARCH/DR_WANIDA/DR/JavisInActionFastRetransmitFrame.html

Mówiąc najprościej, retransmisja TCP jest głównie zależna od czasu oczekiwania pakietu na wykrycie chybienia, podczas gdy w szybkiej retransmisji TCP duplikat potwierdzenia dla określonego pakietu symbolizuje jego brak.

Przeważnie 3-krotne potwierdzenie dla pakietu jest wydedukowane jako brak pakietu. Źródło może następnie zobaczyć numer kolejny pakietu, dla którego uruchomiono NACK. Jest to numer kolejny brakującego pakietu i może zostać wysłany do odbiornika.

Zaletą szybkiej retransmisji TCP jest to, że nie czeka ona na przekroczenie limitu czasu pakietu, aby zainicjować transmisję, a tym samym szybszą retransmisję pakietu, jak sama nazwa wskazuje.