Dlaczego traceroute zajmuje dużo więcej czasu niż ping?

16

Jak to wytłumaczyć?

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.

Tak więc średni czas powinien wynosić: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, czyli dużo więcej niż 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

ping networking

— splattne
źródło

3

Tyle złych odpowiedzi na to pytanie. W pewnym sensie wszyscy przypominacie mi youtube.com/watch?v=SXmv8quf_xM

— Tom O'Connor,

16

Nie można po prostu dodać wszystkich tych liczb. To jest czas pingowania do każdego z przeskoków na ścieżce do Google. Tak więc naturalnie każda odnoga ścieżki jest coraz bardziej oddalana i widać różne czasy pingowania. Jeśli spojrzysz na ostatni czas pingowania w tracert (34 ms) i czas, który otrzymałeś przy wydaniu ping (34ms), są one takie same. Program tracert nie jest wolniejszy niż ping.

Proponuję przeczytać o tym, jak działa traceroute:
http://en.wikipedia.org/wiki/Traceroute

— einstiien
źródło

To nie jest farther and farther away.

Nie rozumiem o co ci chodzi. Każdy adres IP wymieniony w traceroute to adres następnego routera w linii między tobą a google. W „logicznej” topologii sieci oddalają się one w miarę postępów w dół listy. Ponadto w przeważającej części oddalają się fizycznie od twojej lokalizacji geograficznej. Chociaż nie zawsze jest to prawdą, ponieważ czasami trasy wydają się przeskakiwać po mapie „niepotrzebnie”. Ale chodzi mi o to, że odległość fizyczna i wielokrotne przeskoki zwiększają czas pingowania.

— einstiien

Spróbuj pingować każdy węzeł na trasie. Powinieneś wymyślić taką samą sumę (z grubsza).

— Chris Nava,

1

Może PHP znajduje się na niewłaściwej stronie przepełnienia stosu i oznacza, że dalej odnosi się do fizycznej odległości, podczas gdy dalsze jest bardziej odpowiednie dla odległości sieciowej? english.stackexchange.com

— dunxd

12

Możesz zobaczyć ping jak przejazd z Nowego Jorku do San Francisco. To zajmuje, powiedzmy 200 godzin (jestem ze Szwajcarii i nie znam odległości w USA)

Ale Kierowca musi wrócić do Nowego Jorku, aby powiedzieć, że był w San Francisco. Spoglądasz na zegarek i teraz obliczysz, że pokonał dystans 400 godzin. To właśnie robi Ping. To, co robi Traceroute: Powiedz kierowcy, że powinien jechać z Nowego Jorku do San Franciso, a za każdym razem, gdy znajdzie się na skrzyżowaniu, powinien wracać i podawać ci jego nazwę. Więc jest już w drodze, a kilka pierwszych skrzyżowań znajduje się w Nowym Jorku. Więc jest dość szybki, wracając do ciebie i podając nazwę skrzyżowania. Ale kiedy zbliży się dalej, powrót do ciebie zajmie więcej czasu. i tak dalej...

Więc jeśli weźmiesz pod uwagę wszystkie godziny jazdy, które był w drodze, zgłoszenie wszystkich skrzyżowań zajęłoby mu znacznie więcej czasu, niż gdyby musiał po prostu jechać do San Francisco. Mam nadzieję, że to wyjaśni ci kilka rzeczy ...

— Bona
źródło

2

Lepszą analogią byłoby wysłanie 30 kierowców, którzy kazali każdemu jechać w kierunku Nowego Jorku, ale każdy z nich musi zawrócić i wrócić na pierwsze skrzyżowanie, drugie skrzyżowanie, trzecie skrzyżowanie itd. droga do trzydziestu skrzyżowań (mając nadzieję, że między SF i NY jest mniej niż 30).

— Jed Daniels,

0

W rzeczywistości wynika to z faktu, że PING wysłał żądanie ICMP przez sieć do DNS i innych urządzeń sieciowych.

Jednak Traceroute wysyła wiele paczek z TTL naprawdę krótkimi.

Na przykład, gdy próbujesz dołączyć do www.google.com ze swojego miejsca, traceroute wysłał paquet na www.google.com z wartością TTL ustawioną na 1 i czeka na odpowiedź od urządzenia sieciowego pierwszego spotkania.

Następnie Traceroute wyświetla na ekranie adres IP pierwszego urządzenia sieciowego, a potem zrobi to samo, ale tym razem z TTL ustawionym na 2 itd.

Na koniec Traceroute odczekał około połowę więcej czasu, ponieważ przy każdej wysyłce czeka na odpowiedź urządzenia sieciowego.

— Dr I.
źródło

0

Traceroute zawsze informuje o średniej do celu, a nie o kumulacji czasów, czyli w twoim przypadku jest to 34ms z pingi traceroute.

Jeśli traceroute zrobiłby to, co sugerujesz, jego wynik byłby dość nieczytelny.

Jeśli interesuje Cię tylko czas reakcji miejsca docelowego, pingwystarczy, traceroutejeśli potrzebujesz debugować coś na trasie do miejsca docelowego. Co więcej, wszystkie przeskoki między tobą a miejscem docelowym są routerami i przez większość czasu routery mają pierwszeństwo w tym, co należy zrobić, to znaczy najpierw pakiety trasy, a następnie odpowiedzą na ping lub traceroute (to jest pierwszy przypadek, odpowiadanie na icmp echo reply, a w drugim przypadku an icmp time exceeded) i często odpowiadam wolniej (kiedy w ogóle odpowiadają)

— mata
źródło

0

Dla potomnych, ponieważ żadna z poprawnych odpowiedzi nie jest bardzo jasna ...

-

Za każdym razem w traceroute jest CAŁKOWITY CZAS OD TWOJEJ MASZYNY (lub maszyny wykonującej traceroute ...) do TEGO SZCZEGÓŁOWEGO WĘŻA.

Innymi słowy, czas pokazany na drugim węźle nie jest czasem zajmowanym między węzłami 1 i 2, ale raczej całkowitym czasem pomiędzy źródłem, pierwszym i drugim węzłem.

Średnio więc czasy pokazane na każdym węźle powinny w przybliżeniu odpowiadać czasom, które można uzyskać, gdybyś pingował ten konkretny węzeł „bezpośrednio” (w rzeczywistości nie jest to bardziej bezpośrednie niż traceroute ... zwykle będzie podążał tą samą ścieżką w Internecie).

Pamiętaj tylko, że istnieje coś takiego jak „skok opóźnienia”. Najdokładniejszym sposobem na znalezienie źródła dowolnego opóźnienia jest uruchomienie traceroute przy powtórzeniu przy użyciu pliku wsadowego (jeśli korzystasz z systemu Windows) i znalezienie najbliższego (najniższego numeru) węzła, który ma wysoką liczbę w danym momencie.

-

W przypadku pliku wsadowego otwórz notatnik i wpisz 3 wiersze:

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

Następnie zapisz jako „Trace.bat”, ale pamiętaj, aby zmienić typ pliku w oknie dialogowym zapisu na „wszystkie pliki” przed zapisaniem, ponieważ nadal będzie zapisywany jako plik tekstowy.

Po otwarciu spowoduje to ciągłe uruchamianie traceroutes (do google). Możesz go zatrzymać, naciskając kombinację klawiszy Ctrl + C, gdy masz wybrane okno.

-

Możesz oczywiście zmienić miejsce, w którym działa traceroute, zmieniając „www.google.com” na dowolny adres, na jaki masz ochotę.

Możesz także usunąć opcję „-d”, jeśli chcesz zobaczyć rozstrzygnięte nazwy hostów, ale spowoduje to, że traceroute zajmie więcej czasu ze względu na pobieranie tych nazw hostów z serwera DNS dla każdego węzła (to jednak nie zmienia samych faktycznych wyników ).

Wreszcie, jeśli znajdziesz węzeł z najwyższymi czasami i po prostu chcesz uruchomić traceroutes do tego konkretnego węzła na wypadek, gdyby inny węzeł zanim wystąpił problem, możesz zmienić „www.google.com” na adres IP tego węzła lub nazwę hosta, LUB możesz użyć opcji -h, aby określić liczbę węzłów do przeszukania, tj. ...

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

— Laike Endaril
źródło

Ważną uwagą jest to, że węzeł odpowiada za pomocą ICMP, ale głównym celem routera jest kierowanie pakietami, a tworzenie odpowiedzi ICMP jest znacznie poniżej listy jego działań. Router wyznaczy trasę i przejdzie do wysyłania wiadomości ICMP, gdy tylko będzie na to czas. Dlatego czas pośredni może być dłuższy niż pełna ścieżka; router pośredni może być znacznie bardziej obciążony niż węzeł końcowy.

— Ron Maupin,

Tak, priorytet QOS ICMP jest zwykle niższy, ale często kiedy uruchamiasz traceroute, to dlatego, że problem już istnieje (masz skoki opóźnienia lub zły ping w grze) i ten konkretny węzeł, o którym wspomniałeś ( zajęty) to wąskie gardło, którego szukasz.

— Laike Endaril,

Nie mam na myśli priorytetu QoS, mam na myśli to, że samo urządzenie tworzy odpowiedź ICMP. Węzeł może być zbyt zajęty routingiem pakietów, aby przejść do wysyłania wiadomości ICMP, zanim oryginalny węzeł ją przekroczy. Router skieruje pakiety przed podjęciem decyzji o wysłaniu wiadomości ICMP. To nie ma nic wspólnego z QoS.

— Ron Maupin,

QoS jest bardzo luźno zdefiniowanym terminem i uważam, że obejmuje wszystkie działania korzystające z tego samego zestawu zasobów, a nie wyklucza działań wymagających dodatkowej uwagi (konstruowanie pakietu odpowiedzi). Tak czy inaczej, nie zmienia to faktu, że wspomniany router jest zbyt obciążony i musi powodować problemy, więc wysokie czasy z traceroute są nadal dobrym wskaźnikiem tego, gdzie leżą twoje problemy ... z możliwy wyjątek od dużego ruchu, który ma wyższy priorytet niż Twój ICMP, ale ma niższy priorytet niż normalny ruch.

— Laike Endaril

-1

Ponieważ tracert używa pakietów UDP, podobnie jak ping używa pakietów ICMP. W Linuksie masz traceroute -Iopcję zrobienia śledzenia ICMP.

W twoim teście czas połączenia z Google jest taki sam w traceroute i ping: 34ms. Wszystkie routery na środku mają swój czas na odpowiedź, ale nie wpływa to na końcowy czas transferu.

http://en.wikipedia.org/wiki/Traceroute wyjaśnij wszystko na Traceroute

— Dom
źródło

3

W rzeczywistości w systemie Windows tracertdomyślnie używa ICMP, w przeciwieństwie do systemu Linux traceroute.

— phoebus

tracert używa okresu ICMP. ICMP to protokół IP 1, UDP to 17.

— dbasnett

@dbasnett Początkowo traceroute wysyłał pakiety wychodzące jako UDP, a pakiety zwrotne są oczywiście wiadomościami przekroczonymi przez ICMP TTL. Windows i teraz inne programy traceroute używają pakietów żądania echa ICMP dla wychodzących. Zazwyczaj, gdy ludzie odnoszą się do UDP traceroute lub ICMP traceroute, odnoszą się do tych pakietów wychodzących, ponieważ OBA mechanizmy polegają na tym, że ICMP TTL przekroczyło wiadomości wracające do nadawcy z przeskoków na trasie.

— Jed Daniels,

-1

Możesz zwiększyć swój traceroute, wyłączając odwrotne wyszukiwanie dns, które często kończy się niepowodzeniem: tracert -d www.google.com

— Mathieu Chateau
źródło

Nie przyspiesza to podróży w obie strony. Przyspiesza to jednak wyświetlanie wyników na ekranie, ponieważ nie wykonuje wyszukiwania DNS.

— Jed Daniels