Pakiet TCP jest retransmitowany 7 razy, gdy sysctl tcp_retries1 jest ustawiony na 3

Ubuntu 12.04

Usiłuję lepiej zrozumieć, ile razy TCP spróbuje retransmitować pakiet, gdy nie otrzyma potwierdzenia, że adresat go otrzymał. Po przeczytaniu strony podręcznika tcp wydawało się jasne, że jest to kontrolowane przez sysctl tcp_retries1:

tcp_retries1 (integer; default: 3)
           The number of times TCP will attempt to retransmit a  packet  on
           an  established connection normally, without the extra effort of
           getting the network layers involved.  Once we exceed this number
           of retransmits, we first have the network layer update the route
           if possible before each new retransmit.  The default is the  RFC
           specified minimum of 3.

Mój system ma domyślną wartość 3:

# cat /proc/sys/net/ipv4/tcp_retries1 
3

Chcąc to przetestować, podłączyłem system A (172.16.249.138) do systemu B (172.16.249.137) przez ssh i uruchomiłem prostą pętlę drukowania na konsoli. Następnie nagle odłączyłem B od sieci podczas trwania tej komunikacji.

W innym terminalu uruchomiłem „tcpdump host 172.16.249.137” w systemie A. Poniżej znajdują się odpowiednie linie z wyjścia (numery linii zostały dodane dla zachowania przejrzystości).

00: ...
01: 13:29:46.994715 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [.], ack 5989441, win 80, options [nop,nop,TS val 1957286 ecr 4294962520], length 0
02: 13:29:46.995084 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [.], ack 5989441, win 186, options [nop,nop,TS val 1957286 ecr 4294962520], length 0    
03: 13:29:47.040360 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 186, options [nop,nop,TS val 1957298 ecr 4294962520], length 48
04: 13:29:47.086552 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [.], ack 5989441, win 376, options [nop,nop,TS val 1957309 ecr 4294962520], length 0
05: 13:29:47.680608 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1957458 ecr 4294962520], length 48
06: 13:29:48.963721 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1957779 ecr 4294962520], length 48
07: 13:29:51.528564 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1958420 ecr 4294962520], length 48
08: 13:29:56.664384 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1959704 ecr 4294962520], length 48
09: 13:30:06.936480 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1962272 ecr 4294962520], length 48
10: 13:30:27.480381 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1967408 ecr 4294962520], length 48
11: 13:31:08.504033 IP 172.16.249.138.50489 > 172.16.249.137.ssh: Flags [P.], seq 29136:29184, ack 5989441, win 376, options [nop,nop,TS val 1977664 ecr 4294962520], length 48
12: 13:31:13.512437 ARP, Request who-has 172.16.249.137 tell 172.16.249.138, length 28
13: 13:31:14.512336 ARP, Request who-has 172.16.249.137 tell 172.16.249.138, length 28
14: 13:31:15.512241 ARP, Request who-has 172.16.249.137 tell 172.16.249.138, length 28

Jeśli interpretuję to poprawnie (a może nie jestem), pakiet linii 3 nigdy nie jest potwierdzany przez system B. A następnie próbuje wysłać ten pakiet 7 razy (linie 5-11) za każdym razem, zwiększając jego czas retransmisji (mniej więcej dwukrotnie czas).

Dlaczego pakiet jest retransmitowany 7 razy zamiast 3?

Uwaga: ten formalny test wykonałem po zauważeniu kilku plików pcap, w których retransmity zachodziły 6-7 razy przez połączenia HTTP, więc liczba retransmitów nie wydaje się specyficzna dla SSH.

— HodB
źródło

Czy przeczytałeś wyjaśnienie ustawienia? To nie jest liczba ponownych prób. Jest to liczba ponownych prób przed zmianą strategii.

— David Schwartz

Jak wspomniano powyżej, tak, czytam ustawienie. W takim przypadku nie byłoby trasy do aktualizacji, ponieważ oba znajdują się w tej samej podsieci. Dlaczego 7 prób? Co decyduje o łącznej liczbie ponownych prób?

— HodB

Jaka jest twoja wartość dla sysctl net.ipv4.tcp_retries2? Zmienna net.ipv4.tcp_retries2 to ta, która faktycznie kontroluje liczbę prób, które będą podejmowane. Zmienna net.ipv4.tcp_retries1 kontroluje tylko liczbę ponownych prób, zanim system zasygnalizuje niższy poziom, aby spróbować zweryfikować dostępność sieci.

— polowanie

Wierzę, że stworzyłeś gniazdo osierocone, zabijając połączenie na serwerze .137. Zatem użytym parametrem jądra byłby tcp_orphan_retries - który ma ogólny domyślny linux 7.

Opis zarówno stanu, jaki stworzyłeś, jak i wyników można znaleźć tutaj: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html

— Andrew S.
źródło

Pakiet TCP jest retransmitowany 7 razy, gdy sysctl tcp_retries1 jest ustawiony na 3 - dlaczego?