Ubuntu 12.04
宛先が受信した確認を受信しないときに、TCPがパケットを再送信しようとする回数をよりよく理解しようとしています。tcpのmanページを読んだ後、これが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.
私のシステムはデフォルト値の3に設定されています。
# cat /proc/sys/net/ipv4/tcp_retries1
3
これをテストしたいので、システムA（172.16.249.138）からシステムB（172.16.249.137）にsshで接続し、コンソールで単純な印刷ループを開始しました。次に、この通信が行われている間にBをネットワークから突然切断しました。
別の端末では、システムAで「tcpdump host 172.16.249.137」を実行していました。以下は、出力の関連する行です（わかりやすくするために行番号を追加しています）。
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
私がこれを正しく解釈している場合（そうでない場合もあります）、ライン3のパケットはシステムBによって確認されません。Aは、再送信タイマーを増やすたびに、このパケットの送信を7回再試行します（行5-11）。時間）。
パケットが3回ではなく7回再送信されるのはなぜですか？
注：再送信の数がSSHに固有ではないように、HTTP接続で再送信が6〜7回発生しているいくつかのpcapファイルに気付いた後、この正式なテストを実行しました。
設定の説明を読みましたか？試行する再試行の数ではありません。戦略を変更する前に試行する再試行の数です。
—
David Schwartz
上記のとおり、はい、設定を読みました。この場合、両方が同じサブネット上にあるため、更新するルートはありません。なぜ7回再試行するのですか？合計で何回の再試行が発生するかを決定するものは何ですか？
—
HodB
sysctl net.ipv4.tcp_retries2の値は何ですか？net.ipv4.tcp_retries2変数は、試行される再試行の回数を実際に制御する変数です。net.ipv4.tcp_retries1変数は、ネットワークが使用可能であることを確認するためにシステムがより低いレベルを通知するまでの再試行回数を制御するだけです。
—
2014