TCP-Paket wird 7 Mal erneut übertragen, wenn sysctl tcp_retries1 auf 3 gesetzt ist

Ubuntu 12.04

Ich versuche besser zu verstehen, wie oft TCP versucht, ein Paket erneut zu übertragen, wenn es keine Bestätigung erhält, dass das Ziel es empfangen hat. Nach dem Lesen der TCP-Manpage schien klar zu sein, dass dies vom sysctl tcp_retries1 gesteuert wird:

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.

Mein System ist auf den Standardwert 3 eingestellt:

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

Um dies zu testen, habe ich über ssh eine Verbindung von System A (172.16.249.138) zu System B (172.16.249.137) hergestellt und eine einfache Druckschleife auf der Konsole gestartet. Ich habe dann B abrupt vom Netzwerk getrennt, während diese Kommunikation stattfand.

In einem anderen Terminal habe ich 'tcpdump host 172.16.249.137' auf System A ausgeführt. Nachfolgend sind die relevanten Zeilen aus der Ausgabe aufgeführt (Zeilennummern aus Gründen der Übersichtlichkeit hinzugefügt).

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

Wenn ich dies richtig interpretiere (und möglicherweise nicht), wird das Paket von Leitung 3 von System B niemals bestätigt. A versucht dann erneut, dieses Paket siebenmal zu senden (Zeilen 5 bis 11), wobei der Zeitgeber für die erneute Übertragung jedes Mal erhöht wird (jeweils ungefähr verdoppelt) Zeit).

Warum wird das Paket 7 statt 3 Mal erneut übertragen?

Hinweis: Ich habe diesen formalen Test durchgeführt, nachdem ich einige pcap-Dateien festgestellt habe, bei denen 6-7-mal Neuübertragungen über HTTP-Verbindungen aufgetreten sind, sodass die Anzahl der Neuübertragungen nicht spezifisch für SSH zu sein scheint.

— HodB
quelle

Haben Sie die Erklärung der Einstellung gelesen? Es ist nicht die Anzahl der erneuten Versuche. Dies ist die Anzahl der Wiederholungen, die versucht werden müssen, bevor Strategien geändert werden.

— David Schwartz

Wie oben erwähnt, ja, ich habe die Einstellung gelesen. In diesem Fall gibt es keine Route zum Aktualisieren, da sich beide im selben Subnetz befinden. Warum 7 Wiederholungen? Was bestimmt, wie viele Wiederholungen insgesamt auftreten?

— HodB

Was ist Ihr Wert für die sysctl net.ipv4.tcp_retries2? Die Variable net.ipv4.tcp_retries2 steuert tatsächlich die Anzahl der erneuten Versuche. Die Variable net.ipv4.tcp_retries1 steuert lediglich die Anzahl der Wiederholungsversuche, bevor das System eine niedrigere Ebene signalisiert, um zu überprüfen, ob das Netzwerk verfügbar ist.

— Jagd

Ich glaube, Sie haben einen verwaisten Socket erstellt, indem Sie die Verbindung auf dem .137-Server unterbrochen haben. Der verwendete Kernel-Parameter wäre also tcp_orphan_retries - mit einem generischen Linux-Standard von 7.

Eine Beschreibung sowohl der von Ihnen erstellten Bedingung als auch der Ergebnisse erhalten Sie hier: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html

— Andrew S.
quelle

TCP-Paket wird 7 Mal erneut übertragen, wenn sysctl tcp_retries1 auf 3 gesetzt ist - warum?