왜 mtr이 traceroute보다 훨씬 빠릅니까?


12

에서 mtr맨 페이지, 그것을 읽

mtr은 단일 네트워크 진단 도구에서 추적 경로 및 핑 프로그램의 기능을 결합합니다

나는 mtr많이 사용 하고보다 훨씬 빠릅니다 traceroute. 본능적으로, 매 초마다 각 IP 주소 mtrtraceroute나열 하면서 나에게 정중하게 대답 합니다. 내 컴퓨터에서 나는을 사용 time mtr www.google.com했고 time traceroute www.google.com결과는 21.9s VS 6.1s입니다.

문제는 왜? 이므로 mtr = ping + traceroute이것이 느리거나 적어도 같은 것을 의미하지는 않습니다 traceroute.

누구든지 합리적이고 자세한 답변을 줄 수 있습니까?

답변:


21

병렬 처리는 이러한 도구의 속도가 변하는 주요 원인입니다. 또 다른 기여 요인은 홉이 응답하지 않는 것으로 간주되기 전에 응답을 기다리는 시간입니다. 역방향 DNS가 수행되는 경우 해당 DNS도 기다려야합니다. 역방향 DNS를 비활성화하면 일반 traceroute 명령이 훨씬 빨라집니다.

내가 언급하지 않은 또 다른 중요한 차이점은 두 도구가 출력을 렌더링하는 방법입니다. Traceroute는 위에서 아래로 출력을 생성합니다. Mtr은 다른 방식으로 출력을 렌더링합니다. 여기서 mtr은 이전 행의 출력으로 돌아가서 출력을 업데이트 할 수 있습니다.

이것은 mtr이 사용 가능한 즉시 출력을 표시 할 수 있음을 의미합니다. 나중에 응답으로 인해 출력이 정확하지 않으면 mtr이 되돌아 가서 갱신 할 수 있기 때문입니다. traceroute는 되돌아 가서 출력을 업데이트 할 수 없으므로 결국 표시 할 내용을 결정할 때까지 기다려야합니다.

예를 들어 홉 번호 2가 응답하지 않는 경우 (여러 ISP에서 볼 수있는 증상) traceroute는 홉 번호 1을 표시 한 다음 잠시 기다렸다가 홉 번호 2와 3을 표시합니다. traceroute가 여전히 홉 번호 2의 응답을 기다리고 있기 때문에 3이 표시되지 않습니다. Mtr에는 해당 제한이 없으며 홉 번호 3의 응답을 표시 할 수 있으며 여전히 홉 번호 2의 응답을 표시하도록 돌아갈 수 있습니다. 나중에 도착합니다.

병렬 처리가 너무 많으면 출력이 부정확해질 수 있습니다. 일부 시나리오에서는 응답을받을 수있는 패킷 수에 제한이 있습니다. 이 경우 더 많은 패킷을 보내면 프로세스 속도가 빨라지지 않지만 더 많은 패킷이 전송되면 같은 수의 회신을 받으므로 더 많은 패킷이 손실됩니다.

이에 대한 한 가지 예는 경로의 홉이 ARP 요청에 응답하지 않는 경우입니다. 일반적으로 첫 번째 패킷은 ARP 요청을 트리거하며 ARP 요청 시간이 초과되기 전에 더 많은 패킷이 도착하면 마지막 패킷 만 버퍼링되고 응답을받습니다.

또 다른 차이점은 공구가 더 많은 홉 표시를 중지하기 전에 응답이없는 홉 수가 표시되는 것입니다. traceroute 명령이 요청한만큼 많은 홉 (기본적으로 30 개) 동안 계속되는 반면, mtr 명령은 응답없이 5 개의 홉을 통과하자마자 중지됩니다.


이것은 훨씬 더 나은 답변입니다.
NickW

3

traceroute 명령은 홉당 3 개의 프로브를 전송합니다. 1 개의 프로브 -q 1로 제한 하면 결과가 비슷해집니다.

time mtr -r -c 1 google.com
.
.
.
real    0m2.640s
user    0m0.003s
sys     0m0.018s


time traceroute6 -q 1 google.com
.
.
.
real    0m0.445s
user    0m0.006s
sys     0m0.007s

필자는 비교 가능한 테스트 간의 주요 차이점이 DNS 쿼리 시간 및 경로 차이와 관련이있을 것으로 기대합니다. 내 traceroute가 mtr보다 빠르지 만 항상 그런 것은 아닙니다.


2

나는 이것이 경로 추적이 구현되는 방식에서 나온 것이라고 생각합니다. traceroute라우트의 각 홉에 대해 최소 3 개의 패킷을 대상으로 순차적으로 전송합니다.

mtr 먼저 경로에서 홉을 찾은 다음 각 노드에 병렬로 패킷을 보냅니다.

또한 mtr핑 / 프로브에 응답하지 않는 핸들 홉 방식에 차이가있는 것 같습니다 . traceroute첫 번째 시도가 응답을 얻지 못한 경우에도 항상 3 개의 패킷을 보내는 것 보다 빠릅니다 .


1

주된 이유는 traceroute가 실행되는 방식입니다. TTL이 1 인 UDP (또는 Windows의 ICMP) 패킷을 첫 번째 호스트에 전송하고 시간 초과 응답을 받거나 내부 시간 초과를 통과하면 TTL을 사용하여 다음 호스트에 대한 다음 패킷을 생성합니다. 2 개 등 (각 호스트의 TTL에 1 개 추가). 따라서 traceroute의 총 시간에는 각 호스트에 대한 패킷 송수신이 순차적으로 포함됩니다.

mtr은 패킷의 경로를 결정한 후 모든 ICMP ECHO 패킷을 병렬로 보냅니다.


mtr은 패킷을 어디로 보낼지 어떻게 알 수 있습니까?
user9517

그래, 나는 그것을 추가해야한다. 비록 그것이 "실제로"어떻게 그것이 소스를 읽어야한다고 생각하는지 알아 낸다. :)
NickW

[mtr] investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines
NickW

2
@Iain 모든 패킷을 지정한 한 주소로 보냅니다. 서로 다른 패킷은 오류가 발생하기 전에 이동 거리에 대한 최대 거리를 다르게 지정합니다. mtr 또는 traceroute로 표시되는 주소는 회신이 다시 온 후에 만 ​​알 수 있습니다.
kasperd
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.