El paquete TCP se retransmite 7 veces cuando sysctl tcp_retries1 se establece en 3, ¿por qué?

Ubuntu 12.04

Estoy tratando de comprender mejor cuántas veces TCP intentará retransmitir un paquete cuando no recibe confirmación del destino. Después de leer la página de manual de tcp , parecía claro que esto está controlado por 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.

Mi sistema está configurado con el valor predeterminado de 3:

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

Queriendo probar esto, me conecté del sistema A (172.16.249.138) al sistema B (172.16.249.137) a través de ssh y comencé un simple ciclo de impresión en la consola. Luego desconecté B bruscamente de la red mientras ocurría esta comunicación.

En otra terminal, estaba ejecutando 'tcpdump host 172.16.249.137' en el sistema A. A continuación se muestran las líneas relevantes de la salida (se agregaron números de línea para mayor claridad).

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

Si estoy interpretando esto correctamente (y puede que no lo sea), el paquete de la línea 3 nunca es reconocido por el sistema B. A vuelve a intentar enviar este paquete 7 veces (líneas 5-11) cada vez aumentando su temporizador de retransmisión (duplicándolo aproximadamente hora).

¿Por qué el paquete se retransmite 7 veces en lugar de 3?

Nota: Realicé esta prueba formal después de notar algunos archivos pcap donde se producían retransmisiones de 6 a 7 veces a través de conexiones HTTP, por lo que el número de retransmisiones no parece específico de SSH.

— HodB
fuente

¿Leíste la explicación de la configuración? No es el número de reintentos para intentar. Es el número de reintentos a intentar antes de cambiar las estrategias.

— David Schwartz

Como se mencionó anteriormente, sí, leí la configuración. En este caso, no habría una ruta para actualizar, ya que ambos están en la misma subred. ¿Por qué 7 reintentos? ¿Qué determina cuántos reintentos ocurren en total?

— HodB

¿Cuál es su valor para el sysctl net.ipv4.tcp_retries2? La variable net.ipv4.tcp_retries2 es la que realmente controla el número de reintentos que se intentarán. La variable net.ipv4.tcp_retries1 solo controla el número de reintentos antes de que el sistema indique un nivel inferior para intentar verificar que la red esté disponible.

— cazando

Creo que creó un socket huérfano al eliminar la conexión en el servidor .137. Entonces, el parámetro de kernel en uso sería tcp_orphan_retries, que tiene un valor predeterminado genérico de Linux de 7.

Puede obtener una descripción tanto de la condición que creó como de los resultados aquí: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html

— Andrew S
fuente