Il pacchetto TCP viene ritrasmesso 7 volte quando sysctl tcp_retries1 è impostato su 3

Ubuntu 12.04

Sto cercando di capire meglio quante volte TCP tenterà di ritrasmettere un pacchetto quando non riceve conferma dalla destinazione ricevuta. Dopo aver letto la pagina man di tcp sembrava chiaro che questo è controllato dal 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.

Il mio sistema è impostato sul valore predefinito di 3:

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

Volendo provare questo, mi sono collegato dal sistema A (172.16.249.138) al sistema B (172.16.249.137) su ssh e ho avviato un semplice ciclo di stampa sulla console. Ho quindi disconnesso improvvisamente B dalla rete mentre si stava verificando questa comunicazione.

In un altro terminale, eseguivo "tcpdump host 172.16.249.137" sul sistema A. Di seguito sono riportate le righe pertinenti dall'output (numeri di riga aggiunti per maggiore chiarezza).

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

Se lo sto interpretando correttamente (e potrei non esserlo), il pacchetto della riga 3 non viene mai riconosciuto dal sistema B. A quindi prova a inviare questo pacchetto 7 volte (righe 5-11) ogni volta aumentando il suo timer di ritrasmissione (raddoppiandolo approssimativamente ogni tempo).

Perché il pacchetto viene ritrasmesso 7 volte anziché 3?

Nota: ho eseguito questo test formale dopo aver notato alcuni file pcap in cui si verificavano ritrasmissioni 6-7 volte su connessioni HTTP in modo che il numero di ritrasmissioni non sembrasse specifico di SSH.

— HodB
fonte

Hai letto la spiegazione dell'impostazione? Non è il numero di tentativi da provare. È il numero di tentativi da provare prima di cambiare strategia.

— David Schwartz,

Come accennato in precedenza, sì, ho letto l'impostazione. In questo caso non ci sarebbe alcun percorso da aggiornare poiché sono entrambi sulla stessa sottorete. Perché 7 tentativi? Cosa determina quanti tentativi si verificano in totale?

— HodB

Qual è il tuo valore per sysctl net.ipv4.tcp_retries2? La variabile net.ipv4.tcp_retries2 è quella che controlla effettivamente il numero di tentativi che verranno tentati. La variabile net.ipv4.tcp_retries1 controlla semplicemente il numero di tentativi prima che il sistema segnali un livello inferiore per provare a verificare che la rete sia disponibile.

— caccia il

Credo che tu abbia creato un socket orfano uccidendo la connessione sul server .137. Quindi, il parametro del kernel in uso sarebbe tcp_orphan_retries - che ha un valore predefinito di linux generico di 7.

Puoi ottenere una descrizione sia della condizione che hai creato sia dei risultati qui: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html

— Andrew S
fonte

Il pacchetto TCP viene ritrasmesso 7 volte quando sysctl tcp_retries1 è impostato su 3 - perché?