Чому traceroute займає набагато більше часу, ніж пінг?

Як це пояснити?

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 (34 мс) та час, який ви отримали при видачі ping (34 мс), вони однакові. Програма tracert не повільніше, ніж ping.

Я б запропонував ознайомитись із тим, як працює мікрокамера:
http://en.wikipedia.org/wiki/Traceroute

Ви можете побачити пінг, як поїзд з Нью-Йорка до Сан-Франциско. Потрібно, скажімо, 200 годин (я зі Швейцарії та не знайомий з відстані в США)

Але Водій повинен повернутися до Нью-Йорка, щоб сказати вам, що він був у Сан-Франциско. Ви дивитесь на годинник, і тепер ви підраховуєте, що він взяв 400 годин на відстань. Тепер це робить Пінг. Що Traceroute робить: Скажіть своєму водієві, що він повинен їхати з Нью-Йорка до Сан-Франциско, і кожен раз, коли він приїжджає на перехрестя, він повинен повертатися і говорити вам його ім'я. Тож він на своєму шляху і перші кілька перехрестя перебувають у Нью-Йорку. Тож він досить швидко їздить до вас і говорить вам назву перехрестя. Але коли він подальше здалека, то буде потрібно більше часу, щоб повернутися до вас. і так далі...

Тож якщо ви порахуєте всі години їзди, що він був у дорозі, він мав би набагато більше часу, щоб повідомити про всі перехрестя, ніж якби йому просто довелося їхати до Сан-Франциско. Сподіваюсь, це очистить деякі речі для вас ...

Насправді це в основному пов'язано з тим, що PING надіслав запит ICMP по мережі на DNS та інші пристрої мережі.

Однак Traceroute надсилає дуже багато пакетів з TTL дійсно короткими.

Для прикладу, коли ви намагаєтесь приєднатись до www.google.com зі свого місця, traceroute надіслав пакет на www.google.com з TTL, встановленим на 1, і чекайте відповіді від пристрою першої зустрічної мережі.

Потім Traceroute відобразить IP-адресу пристрою першої мережі на екрані, і після цього він зробить те саме, але на цей раз з TTL, встановленим на 2 тощо.

Зрештою, Traceroute чекав приблизно вдвічі більше часу, оскільки при кожному надсиланні він чекає відповіді на пристрій мережі.

Traceroute завжди повідомляє вам середнє значення до місця призначення, а не скупчення разів, тобто у вашому випадку це 34 мс з pingі traceroute.

Якщо traceroute повинен був робити те, що ви пропонуєте, його результат був би зовсім нечитабельним.

Якщо вас цікавить лише час відповіді пункту призначення, pingце цілком достатньо, tracerouteколи вам потрібно щось налагодити на маршруті до пункту призначення. Більше того, всі перестрибування між вами та пунктом призначення є маршрутизаторами, і в більшості випадків маршрутизатори мають пріоритет щодо того, що робити, тобто спочатку пакети маршрутів, а потім відповідають на ping або traceroute (тобто перший випадок, відповідати на icmp echo reply, а у другому випадку - ан icmp time exceeded) та часто відповідати повільніше (коли вони взагалі відповідають)

Для нащадків, оскільки жодна з правильних відповідей не дуже чітка ...

-

Кожен раз, що відображається в трасе, - це ТОТАЛЬНИЙ ЧАС від ВАШОЇ МАШИНИ (або машини, яка виконує трасування ...), ДО ТОГО ПРАВИЛЬНОГО УЗВУ.

Іншими словами, час, показаний на 2-му вузлі, - це не час, пройдений між вузлами 1 і 2, а, скоріше, загальний час, який пройшов між джерелом, першим вузлом та другим вузлом, узятим разом.

Отже, в середньому, час, показаний на кожному вузлі, повинен приблизно збігатися з часом, яке ви отримаєте, якби пінґувати цей конкретний вузол "безпосередньо" (це не є більш прямим, ніж слідом відслідковування в реальності ... зазвичай це буде слідувати тому ж шляху в інтернеті).

Тільки майте на увазі, що існує таке поняття, як "відставання". Найбільш точний спосіб знайти джерело будь-якого відставання - це запустити traceroute при повторі, використовуючи пакетний файл (якщо ви працюєте в Windows), і знайти найближчий (найменший номер) вузол, який має високі числа в будь-який момент часу.

-

Для пакетного файлу відкрийте блокнот і введіть ці 3 рядки:

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

Потім збережіть як "Trace.bat", але переконайтеся, що ви зміните тип файлу в діалозі збереження на "всі файли" перед збереженням, інакше він збережеться як текстовий файл.

Після відкриття це буде постійно виконувати сліди (для Google). Ви можете зупинити це, натиснувши ctrl + c, поки у вас вибрано вікно.

-

Ви, звичайно, можете змінити те, на якому він веде трасування, змінивши "www.google.com" на будь-яку адресу, яку ви хочете.

Ви також можете видалити параметр "-d", якщо ви хочете побачити вирішені імена хостів, але це зробить трасування через довше через отримання зазначених імен хостів з DNS-сервера для кожного вузла (це НЕ змінює самі фактичні результати, однак ).

Нарешті, якщо ви знайдете вузол із високим часом та просто хочете запустити traceroutes до цього конкретного вузла у випадку, якщо інший вузол перед ним виникне, ви можете або змінити "www.google.com" на ip адресу цього вузла чи ім'я хоста, АБО Ви можете скористатися параметром -h, щоб вказати, скільки вузлів шукати, тобто ...

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

Оскільки tracert використовують пакети UDP, як і ping, використовують пакети ICMP. У Linux, де єtraceroute -I можливість провести ICMP-розслідування.

У вашому тесті час підключення до google однаковий у traceroute та ping: 34ms. Усі маршрутизатори посередині мають свій час відповіді, але це не впливає на остаточний час передачі.

http://en.wikipedia.org/wiki/Traceroute поясніть усе на Traceroute

Ви можете підвищити свій traceroute, відключивши пошук зворотного dns, який часто не працює: tracert -d www.google.com