traceroute가 ping보다 훨씬 오래 걸리는 이유는 무엇입니까?

이것을 설명하는 방법?

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

평균 시간은 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34이어야합니다. ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms

그 숫자들을 모두 더할 수는 없습니다. Google로가는 길에있는 각 홉의 핑 시간입니다. 따라서 자연스럽게 경로의 각 다리가 점점 멀어지고 핑 시간이 달라집니다. tracert (34ms)에서 마지막 핑 시간과 핑 (34ms)을 발행했을 때받은 시간을 보면 동일합니다. tracert 프로그램은 ping보다 느리지 않습니다.

나는 traceroute가 어떻게 작동하는지에 관해 읽어 보길 권한다 :
http://en.wikipedia.org/wiki/Traceroute

뉴욕에서 샌프란시스코까지 드라이브처럼 핑을 볼 수 있습니다. 200 시간이 걸린다 (스위스 출신이며 미국의 거리에 익숙하지 않다)

그러나 운전자는 자신이 샌프란시스코에 있다고 알려주기 위해 뉴욕으로 돌아와야합니다. 시계를 살펴보면 거리에 400 시간이 걸린 것으로 계산됩니다. 이것이 바로 Ping이하는 일입니다. Traceroute의 기능 : 운전 기사에게 뉴욕에서 샌 프란체스코까지 운전해야한다고 말하고 교차로에 올 때마다 돌아와서 그 이름을 알려야합니다. 그래서 그는오고 있으며 처음 몇 개의 교차로는 뉴욕에 있습니다. 그래서 그는 당신에게 돌아와서 당신에게 사거리의 이름을 말하는데 꽤 빠릅니다. 그러나 더 멀어지면 다시 돌아 오는 데 시간이 더 걸립니다. 등등...

따라서 운전 시간을 모두 세면 샌프란시스코로 운전하는 것보다 모든 교차로를보고하는 데 훨씬 더 오래 걸립니다. 희망이 당신을 위해 몇 가지를 정리합니다 ...

실제로 PING은 네트워크를 통해 ICMP 요청을 DNS 및 기타 네트워크 어플라이언스로 보냈기 때문입니다.

그러나 Traceroute는 TTL이 매우 짧은 많은 paquets를 보냅니다.

예를 들어 좌석에서 www.google.com에 가입하려고 할 때 traceroute는 TTL이 1로 설정된 상태에서 www.google.com으로 paquet을 보내고 첫 번째 네트워크 장비의 응답을 기다립니다.

그런 다음 Traceroute는 첫 번째 네트워크 어플라이언스의 IP를 화면에 표시하고 TTL을 2 등으로 설정하면 이번에는 동일하게됩니다.

결국 Traceroute는 매번 보낼 때마다 네트워크 어플라이언스의 응답을 기다리고 있기 때문에 약 반 시간을 더 기다렸습니다.

추적 경로는 항상이 34ms있어 귀하의 경우에서, 시간의하지 축적, 목적지에 당신에게 평균을 이야기 ping하고 traceroute.

traceroute가 제안한 것을 수행하면 출력을 읽을 수 없습니다.

목적지의 응답 시간에만 관심이 있다면, 목적지까지 의 경로에서 무언가를 디버깅해야 할 때 ping충분 traceroute합니다. 또한, 사용자와 대상 사이의 모든 홉은 라우터이며, 대부분의 경우 라우터는 무엇을해야하는지, 즉 먼저 패킷을 라우팅 한 다음 핑 또는 추적 경로 (첫 번째 경우, 에 응답 icmp echo reply하고 두 번째 경우에는 icmp time exceeded)에 응답하고 더 느리게 응답합니다 (대부분 응답 할 때)

후손에게는 정답이 명확하지 않기 때문에 ...

-

트레이스 루트에 표시된 각 시간은 기계 (또는 트레이스 루트를 수행하는 기계)에서 특정 노드까지의 총 시간입니다.

즉, 두 번째 노드에 표시된 시간은 노드 1과 2 사이에 걸리는 시간이 아니라 소스, 첫 번째 노드와 두 번째 노드 사이에 걸리는 총 시간입니다.

따라서 평균적으로 각 노드에 표시된 시간은 특정 노드를 "직접"핑하는 경우 얻을 수있는 시간과 대략 일치해야합니다 (실제로 추적 경로보다 직접적인 것은 아닙니다. 일반적으로 동일한 경로를 따릅니다). 인터넷에서).

"래그 스파이크"와 같은 것이 있다는 것을 명심하십시오. 지연의 원인을 찾는 가장 정확한 방법은 배치 파일 (Windows에있는 경우)을 사용하여 반복적으로 트레이스 루트를 실행하고 주어진 시간에 높은 숫자를 가진 가장 가까운 (가장 낮은 번호의) 노드를 찾는 것입니다.

-

배치 파일의 경우 메모장을 열고 다음 세 줄을 입력하십시오.

:start
tracert -d www.google.com
goto start

그런 다음 "Trace.bat"로 저장하지만 저장하기 전에 저장 대화 상자의 파일 유형을 "모든 파일"로 변경하십시오. 그렇지 않으면 여전히 텍스트 파일로 저장됩니다.

열면 추적 경로가 Google에 지속적으로 실행됩니다. 창을 선택한 상태에서 ctrl + c를 눌러 중지 할 수 있습니다.

-

물론 "www.google.com"을 원하는 주소로 변경하여 traceroute가 실행되는 위치를 변경할 수 있습니다.

확인 된 호스트 이름을 보려면 "-d"옵션을 제거 할 수도 있지만 각 노드의 DNS 서버에서 해당 호스트 이름을 가져 오기 때문에 traceroute가 더 오래 걸립니다 (실제 결과 자체는 변경되지 않습니다) ).

마지막으로 시간이 많이 걸리는 노드를 찾고 문제가 발생하기 전에 다른 노드가있는 경우 해당 노드에 대한 추적 경로를 실행하려면 "www.google.com"을 해당 노드의 IP 주소 또는 호스트 이름으로 변경하거나 -h 옵션을 사용하여 검색 할 노드 수를 지정할 수 있습니다.

:start
tracert -d -h 5 www.google.com
goto start

tracert는 ping과 같은 UDP 패킷을 사용하므로 ICMP 패키지를 사용합니다. Linux에서는 traceroute -IICMP 추적 경로를 수행 할 수있는 옵션이 있습니다.

테스트에서 Google에 연결하는 시간은 traceroute와 ping에서 34ms와 같습니다. 중간에있는 모든 라우터는 응답 할 시간이 있지만 최종 전송 시간에는 영향을 미치지 않습니다.

http://ko.wikipedia.org/wiki/Traceroute Traceroute에 대한 설명

tracen -d www.google.com에서 종종 실패하는 역방향 DNS 조회를 사용 중지하여 추적 경로를 향상시킬 수 있습니다.