9 votos

Paquete TCP retransmitido 7 veces cuando sysctl tcp_retries1 se establece en 3 - ¿por qué?

Ubuntu 12.04

Estoy tratando de entender mejor cómo muchas veces TCP intentaremos retransmitir un paquete cuando no recibe la confirmación de que el destino la ha recibido. Después de leer el tcp página man parecía claro esto es controlado por el 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 se establece en el valor predeterminado de 3:

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

Con ganas de probar esto, he conectado el sistema de Un (172.16.249.138) para el sistema B (172.16.249.137) a través de ssh y comenzó una simple impresión de bucle en la consola. Luego me desconecta B abruptamente de la red, mientras que esta comunicación se produzca.

En otra terminal, yo estaba corriendo 'tcpdump host 172.16.249.137' en el sistema A. a Continuación se las correspondientes líneas de la salida (los números de línea añadido 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 yo soy la interpretación de este correctamente (y no puede ser), la línea 3 del paquete nunca es reconocido por el sistema B. a continuación, vuelve a intentar enviar este paquete de 7 veces (líneas 5-11) cada vez que el aumento de su temporizador de retransmisión (aproximadamente duplica cada hora).

¿Por qué es el paquete retransmitido 7 veces en vez de 3?

Nota: he realizado este formales de prueba después de notar un par de ficheros pcap donde retransmite estaban ocurriendo 6-7 veces a través de conexiones HTTP, de modo que el número de retransmite no parece específicos para SSH.

5voto

Andrew S Puntos 227

Creo que has creado un huérfano de socket por el asesinato de la conexión en la .137 servidor. Así, el parámetro de kernel en uso sería tcp_orphan_retries - que tiene un genérico predeterminado de linux de 7.

Usted puede obtener una descripción tanto de la condición que ha creado y los resultados aquí: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: