우분투 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 행) 보내려고 재 시도합니다 (각각 두 배씩 증가) 시각).
패킷이 3이 아닌 7 번 재전송되는 이유는 무엇입니까?
참고 : 재전송 횟수가 SSH에만 국한되지 않도록 HTTP 연결을 통해 재전송이 6-7 번 발생한 일부 pcap 파일을 확인한 후에이 공식 테스트를 수행했습니다.
설정 설명을 읽었습니까? 재시도 횟수는 아닙니다. 전략을 변경하기 전에 시도하는 재시도 횟수입니다.
—
David Schwartz
위에서 언급했듯이 예, 설정을 읽었습니다. 이 경우 둘 다 동일한 서브넷에 있으므로 업데이트 할 경로가 없습니다. 7 번의 재시도? 재시도 횟수는 어떻게 결정됩니까?
—
HodB
sysctl net.ipv4.tcp_retries2의 가치는 무엇입니까? net.ipv4.tcp_retries2 변수는 시도 할 재시도 횟수를 실제로 제어하는 변수입니다. net.ipv4.tcp_retries1 변수는 시스템이 하위 레벨에 신호를 보내기 전에 재시도 횟수를 제어하여 네트워킹을 사용할 수 있는지 확인합니다.
—
잘라