Ubuntu 12.04
我试图更好地理解,当目标未收到确认时,TCP将尝试重传数据包多少次。阅读了tcp手册页后,似乎很明显这是由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
为了测试这一点,我通过ssh从系统A(172.16.249.138)连接到系统B(172.16.249.137),并在控制台上启动了一个简单的打印循环。然后,在发生此通信时,我突然断开了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
如果我正确地解释了这个(可能不是),那么系统B永远不会确认行3的数据包。然后,A每次增加其重传计时器(每次将其大约加倍),都重试发送此数据包7次(第5-11行)。时间)。
为什么将数据包重传7次而不是3次?
注意:我在注意到一些pcap文件后执行了此正式测试,这些文件通过HTTP连接进行了6-7次重传,因此重传的次数似乎并不特定于SSH。
您是否阅读过设置说明?这不是尝试重试的次数。这是在更改策略之前要重试的次数。
—
David Schwartz 2014年
如上所述,是的,我阅读了设置。在这种情况下,由于它们都在同一子网中,因此没有更新路径。为什么要重试7次?是什么决定总共进行多少次重试?
—
HodB
您对sysctl net.ipv4.tcp_retries2的值是多少?net.ipv4.tcp_retries2变量实际上是控制将尝试的重试次数的变量。net.ipv4.tcp_retries1变量仅控制系统发出较低级别的信号以尝试验证网络是否可用之前的重试次数。
—
2014年