나는 방금 여러 Raspberry Pi와 기타 컴퓨터를 Debian Stretch로 업데이트했는데, 그 작업을 하는 동안(업그레이드로 인해 손상된 일부 문제를 수정하는 동안) 핑 시간이 시작된 것을 발견했습니다. 먼저 일부 시스템에서는 응답 시간이 실제로 나쁩니다. 저는 지금까지 다양한 시스템에서 동일한 구성을 실행해왔기 때문에 이것이 새로운 것인지, 제가 눈치채지 못한 것인지, 아니면 실제로 업그레이드와 관련된 것인지는 확실하지 않습니다.
이것을 쉘 출력에 넣으면 다음과 같습니다.
time ping -c1 serverfault.com
PING serverfault.com (151.101.193.69) 56(84) bytes of data.
64 bytes from 151.101.193.69 (151.101.193.69): icmp_seq=1 ttl=56 time=29.0 ms
--- serverfault.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 29.085/29.085/29.085/0.000 ms
real 0m5.098s
user 0m0.010s
sys 0m0.000s
두 번째 호출은 캐시되어 예상되는 동작을 보여줍니다.
time ping -c1 serverfault.com
PING serverfault.com (151.101.1.69) 56(84) bytes of data.
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=56 time=16.8 ms
--- serverfault.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.819/16.819/16.819/0.000 ms
real 0m0.063s
user 0m0.000s
sys 0m0.020s
흥미롭게도 실제로는 업스트림 서버가 아닙니다.
19:49:38.040549 IP (tos 0x0, ttl 64, id 37883, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 10.179.1.1.53: [bad udp cksum 0x17ac -> 0xe329!] 54130+ A? serverfault.com. (33)
19:49:38.040624 IP (tos 0x0, ttl 64, id 6297, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 208.67.220.220.53: [bad udp cksum 0xb918 -> 0x41bd!] 54130+ A? serverfault.com. (33)
19:49:38.040657 IP (tos 0x0, ttl 64, id 25130, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 208.67.222.222.53: [bad udp cksum 0xbb1a -> 0x3fbb!] 54130+ A? serverfault.com. (33)
19:49:38.040688 IP (tos 0x0, ttl 64, id 62720, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 83.169.184.33.53: [bad udp cksum 0x17c3 -> 0xe312!] 54130+ A? serverfault.com. (33)
19:49:38.040717 IP (tos 0x0, ttl 64, id 40746, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 83.169.184.97.53: [bad udp cksum 0x1803 -> 0xe2d2!] 54130+ A? serverfault.com. (33)
19:49:38.040744 IP (tos 0x0, ttl 64, id 41541, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 8.8.4.4.53: [bad udp cksum 0x1804 -> 0xe2d1!] 54130+ A? serverfault.com. (33)
19:49:38.040773 IP (tos 0x0, ttl 64, id 58321, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 8.8.8.8.53: [bad udp cksum 0x1c08 -> 0xdecd!] 54130+ A? serverfault.com. (33)
19:49:38.041061 IP (tos 0x0, ttl 64, id 37884, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.35828 > 10.179.1.1.53: [bad udp cksum 0x17ac -> 0xe101!] 49810+ AAAA? serverfault.com. (33)
19:49:38.041120 IP (tos 0x0, ttl 64, id 25131, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.35828 > 208.67.222.222.53: [bad udp cksum 0xbb1a -> 0x3d93!] 49810+ AAAA? serverfault.com. (33)
19:49:38.049748 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 125)
10.179.1.1.53 > 10.179.1.11.37868: [udp sum ok] 54130 q: A? serverfault.com. 4/0/0 serverfault.com. [4m46s] A 151.101.129.69, serverfault.com. [4m46s] A 151.101.65.69, serverfault.com. [4m46s] A 151.101.1.69, serverfault.com. [4m46s] A 151.101.193.69 (97)
19:49:38.054841 IP (tos 0x0, ttl 57, id 43395, offset 0, flags [DF], proto UDP (17), length 125)
208.67.222.222.53 > 10.179.1.11.37868: [udp sum ok] 54130 q: A? serverfault.com. 4/0/0 serverfault.com. [3m7s] A 151.101.129.69, serverfault.com. [3m7s] A 151.101.193.69, serverfault.com. [3m7s] A 151.101.1.69, serverfault.com. [3m7s] A 151.101.65.69 (97)
19:49:38.074955 IP (tos 0x0, ttl 57, id 53865, offset 0, flags [DF], proto UDP (17), length 125)
208.67.220.220.53 > 10.179.1.11.37868: [udp sum ok] 54130 q: A? serverfault.com. 4/0/0 serverfault.com. [5m] A 151.101.1.69, serverfault.com. [5m] A 151.101.65.69, serverfault.com. [5m] A 151.101.129.69, serverfault.com. [5m] A 151.101.193.69 (97)
그래서 보시다시피 꽤 빨리 답변을 받았습니다. 로컬 루프백만 보는 경우에도 ping 명령을 실행할 때 응답은 다소 즉각적입니다.
19:50:48.577615 IP (tos 0x0, ttl 64, id 29962, offset 0, flags [DF], proto UDP (17), length 61)
127.0.0.1.45851 > 127.0.0.1.53: [bad udp cksum 0xfe3c -> 0x12d5!] 40455+ A? serverfault.com. (33)
19:50:48.578344 IP (tos 0x0, ttl 64, id 29963, offset 0, flags [DF], proto UDP (17), length 61)
127.0.0.1.45851 > 127.0.0.1.53: [bad udp cksum 0xfe3c -> 0xab1d!] 60094+ AAAA? serverfault.com. (33)
19:50:48.591133 IP (tos 0x0, ttl 64, id 29964, offset 0, flags [DF], proto UDP (17), length 125)
127.0.0.1.53 > 127.0.0.1.45851: [bad udp cksum 0xfe7c -> 0x3aea!] 40455 q: A? serverfault.com. 4/0/0 serverfault.com. [3m36s] A 151.101.129.69, serverfault.com. [3m36s] A 151.101.65.69, serverfault.com. [3m36s] A 151.101.1.69, serverfault.com. [3m36s] A 151.101.193.69 (97)
그런데 핑이 차단되고 분명히 재시도(tcpdump에서 확인됨)한 다음 응답을 수락합니까?
파헤쳐보면 100ms 이하의 답변만 보입니다. 어떻게든 ping(또는 라이브러리에 있는 것)이 dnsmasq의 첫 번째 답변을 받아들이지 않고 어떻게든 답변을 "캐시"해야 하는 것처럼 느껴집니다.
다른 도구(컬 등)로도 측정할 수 있습니다. 이는 dnsmasq의 목적에 다소 어긋납니다. 기본적으로 구성에서 모든 DNS 관련 옵션을 시도했지만 결과는 없었습니다(dnssec, 캐시 크기 등). 처음 사용할 때는 항상 5초의 지연이 있었습니다.
어디를 볼지에 대한 다른 아이디어가 있나요? 제가 잘못 설명했나요? 이제 아이디어가 거의 없어졌습니다.
고쳐 쓰다 제가 시도하고 관찰한 몇 가지 다른 사항: dnsmasq에서 캐싱을 완전히 비활성화해도 지금 ping을 시작할 때마다 여전히 지연이 발생합니다.
ipv6은 sysctl을 통해 비활성화되지만 ping -4에는 대기 시간이 표시되지 않습니다.
다음에 추가
options single-request
/etc/resolv.conf를 사라지게 만듭니다. 병렬 요청에 문제가 있는 것 같습니다. 메일링 리스트에 물어볼게요.