Perché traceroute impiega molto più tempo del ping?

16

Come spiegarlo?

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.

Quindi il tempo medio dovrebbe essere: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, che è molto più grande di 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
fonte

3

Così tante cattive risposte a questa domanda. Tutti mi ricordate, in un certo senso, di youtube.com/watch?v=SXmv8quf_xM

— Tom O'Connor

16

Non puoi semplicemente sommare tutti quei numeri. Questo è il tempo di ping per ciascuno dei salti sul percorso di Google. Quindi nativamente ogni tappa del percorso diventa sempre più lontana e vedi tempi di ping variabili. Se guardi l'ultimo tempo di ping in tracert (34 ms) e l'ora che hai ricevuto quando hai emesso il ping (34ms), questi sono gli stessi. Il programma tracert non è più lento del ping.

Vorrei suggerire di leggere su come funziona un traceroute:
http://en.wikipedia.org/wiki/Traceroute

— einstiien
fonte

Non lo è farther and farther away.

Non capisco cosa intendi. Ogni indirizzo IP elencato sul traceroute è l'indirizzo del router successivo in linea tra te e google. Nella topologia di rete "logica" queste si allontanano man mano che avanzi nella lista. Inoltre, per la maggior parte, si allontanano fisicamente più lontano dalla tua posizione geografica. Anche se questo non è sempre vero poiché a volte le rotte sembrano saltare "inutilmente" sulla mappa. Ma il mio punto è che la distanza fisica e i salti multipli aumentano il tempo di ping.

— einstiien,

Prova a eseguire il ping di ciascun nodo nel percorso. Dovresti trovare lo stesso totale (approssimativamente).

— Chris Nava,

1

Forse PHP si trova sul sito dello stackoverflow sbagliato e significa che più lontano si riferisce alla distanza fisica mentre più è più appropriato per la distanza di rete? english.stackexchange.com

— dunxd

12

Puoi vedere il ping come un disco da New York a San Francisco. Ci vogliono, diciamo 200 ore (sono dalla Svizzera e non ho familiarità con le distanze negli Stati Uniti)

Ma il conducente deve tornare a New York per dirti che era a San Francisco. Dai un'occhiata all'orologio e ora calcoli che ha impiegato 400 ore per la distanza. Questo è quello che fa Ping. Quello che fa Traceroute è: dì al tuo autista che dovrebbe guidare da New York a San Franciso e ogni volta che incontra un incrocio dovrebbe tornare e dirti il nome. Quindi è sulla buona strada e i primi incroci sono a New York. Quindi è abbastanza veloce nel tornare da te e dirti il nome del bivio. Ma quando sarà più lontano, ci vorrà più tempo per tornare da te. e così via...

Quindi, se si contano tutte le ore di guida che stava arrivando, avrebbe impiegato molto più tempo a riferire tutti gli incroci che se avesse dovuto guidare a San Francisco. Spero che questo chiarisca alcune cose per te ...

— Bona
fonte

2

Un'analogia migliore sarebbe quella di inviare 30 conducenti, dicendo a ciascuno di loro di dirigersi verso New York, ma ognuno di loro deve voltarsi e tornare al primo incrocio, al secondo incrocio, al terzo incrocio e così via, tutto la strada fino a trenta incroci (sperando che ci siano meno di 30 tra SF e NY).

— Jed Daniels,

0

In realtà, è essenzialmente dovuto al fatto che PING ha inviato una richiesta ICMP sulla rete al DNS e all'appliance dell'altra rete.

Tuttavia, Traceroute invia molti paquets con un TTL davvero breve.

Ad esempio, quando provi a unirti a www.google.com dal tuo posto, traceroute ha inviato un paquet a www.google.com con un TTL impostato su 1 e attendi una risposta dall'appliance della rete del primo incontro.

Quindi, Traceroute visualizza l'IP del primo dispositivo di rete sullo schermo e dopo farà lo stesso, ma questa volta con un TTL impostato su 2 ecc.

Alla fine, Traceroute ha atteso per circa la metà di tempo in più, perché ad ogni invio è in attesa di una risposta dell'appliance di una rete.

— Dr I.
fonte

0

Traceroute ti dice sempre la media a destinazione, non un accumulo di tempi, cioè nel tuo caso è di 34ms con pinge traceroute.

Se traceroute dovesse fare ciò che suggerisci, il suo output sarebbe piuttosto illeggibile.

Se sei interessato solo al tempo di risposta della destinazione, pingè abbastanza, tracerouteè quando devi eseguire il debug di qualcosa sul percorso verso la destinazione. Inoltre, tutti i salti tra te e la destinazione sono router e, nella maggior parte dei casi, i router hanno la priorità su cosa fare, vale a dire i primi pacchetti di route e quindi rispondono al ping o al traceroute (ovvero, il primo caso, rispondendo a icmp echo reply, e nel secondo caso, an icmp time exceeded) e rispondendo spesso più lentamente (quando rispondono affatto)

— stuoia
fonte

0

Per i posteri, poiché nessuna delle risposte corrette è molto chiara ...

-

Ogni volta mostrato nel traceroute è il TEMPO TOTALE dalla TUA MACCHINA (o dalla macchina che fa il traceroute ...) a QUESTO NODO PARTICOLARE.

In altre parole, il tempo mostrato sul secondo nodo non è il tempo impiegato tra i nodi 1 e 2, ma piuttosto il tempo totale impiegato tra l'origine, il primo nodo e il secondo nodo messi tutti insieme.

Quindi, in media, i tempi mostrati su ciascun nodo dovrebbero corrispondere approssimativamente ai tempi che otterresti se dovessi eseguire il ping di quel particolare nodo "direttamente" (in realtà non è più diretto di un traceroute ... di solito seguirà lo stesso percorso su internet).

Ricorda solo che esiste un "picco di ritardo". Il modo più accurato per trovare l'origine di qualsiasi ritardo è eseguire un traceroute ripetutamente utilizzando un file batch (se sei su Windows) e trovare il nodo più vicino (con il numero più basso) che ha numeri alti in un dato momento.

-

Per il file batch, apri il blocco note e digita queste 3 righe:

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

Quindi salva come "Trace.bat" ma assicurati di cambiare il tipo di file nella finestra di dialogo di salvataggio in "tutti i file" prima di salvare, altrimenti verrà comunque salvato come file di testo.

Se aperto, questo eseguirà costantemente traceroutes (a google). Puoi fermarlo premendo ctrl + c mentre hai la finestra selezionata.

-

Naturalmente, puoi cambiare la destinazione del traceroute cambiando "www.google.com" in qualunque indirizzo desideri.

Puoi anche rimuovere l'opzione "-d" se desideri vedere i nomi degli host risolti, ma questo farà sì che il traceroute impieghi più tempo a causa dell'ottenimento di detti nomi host da un server DNS per ciascun nodo (questo NON modifica comunque i risultati effettivi stessi ).

Infine, se trovi un nodo con tempi elevati e desideri semplicemente eseguire i traceroute su quel particolare nodo nel caso in cui un altro nodo prima che abbia dei problemi, puoi cambiare "www.google.com" con l'indirizzo IP di quel nodo o il nome host, OPPURE puoi usare l'opzione -h per specificare il numero di nodi da cercare, cioè ...

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

— Laike Endaril
fonte

Una nota importante è che un nodo risponde con ICMP, ma lo scopo principale di un router è instradare i pacchetti e la creazione di risposte ICMP è in fondo all'elenco di ciò che fa. Un router verrà instradato e si muoverà per inviare messaggi ICMP quando arriva il momento. Ecco perché il tempo intermedio potrebbe essere più lungo del percorso completo; il router intermedio potrebbe essere molto più occupato del nodo finale.

— Ron Maupin,

Sì, la priorità QOS di ICMP è in genere inferiore, ma spesso quando si esegue un traceroute, è perché esiste già un problema (si hanno picchi di ritardo o ping errato in un gioco) e quel nodo particolare che hai menzionato ( quello occupato) è il collo di bottiglia che stai cercando.

— Laike Endaril,

Non intendo la priorità QoS, intendo il dispositivo stesso che crea una risposta ICMP. Il nodo può effettivamente essere troppo impegnato nel routing dei pacchetti per aggirare l'invio di un messaggio ICMP prima del timeout del nodo originale. Un router instraderà i pacchetti prima di decidere di inviare un messaggio ICMP. Non ha nulla a che fare con QoS.

— Ron Maupin,

QoS è un termine molto vagamente definito e ritengo che includa tutte le attività che utilizzano lo stesso insieme di risorse, piuttosto che escludere attività che richiedono maggiore attenzione (costruzione di un pacchetto di risposta). In ogni caso, ciò non cambia il fatto che detto router sia carico di un carico eccessivo e sia destinato a causare problemi, quindi i tempi elevati di un traceroute sono ancora un buon indicatore di dove si trovano i tuoi problemi ... con il possibile eccezione di una grande quantità di traffico che ha una priorità più alta rispetto al tuo ICMP ma una priorità inferiore rispetto al tuo traffico normale.

— Laike Endaril,

-1

Perché tracert usa i pacchetti UDP, come il ping usa i pacchetti ICMP. Sotto Linux, abbiamo la traceroute -Ipossibilità di eseguire traceroute ICMP.

Nel tuo test il tempo per collegarti a google è lo stesso in traceroute e ping: 34ms. Tutti i router nel mezzo hanno il loro tempo per rispondere ma non influiscono sul tempo di trasferimento finale.

http://en.wikipedia.org/wiki/Traceroute spiega tutto su Traceroute

— Dom
fonte

3

In realtà, su Windows, tracertutilizza ICMP per impostazione predefinita, a differenza di Linux traceroute.

— phoebus il

tracert utilizza il periodo ICMP. ICMP è il protocollo IP 1, UDP è 17.

— dbasnett

@dbasnett Originariamente, traceroute ha inviato pacchetti in uscita come UDP, e i pacchetti di ritorno sono naturalmente messaggi ICL TTL superati. Windows e ora altri programmi traceroute utilizzano i pacchetti di richiesta echo ICMP per i client in uscita. In genere quando le persone si riferiscono al traceroute UDP o al traceroute ICMP sono questi pacchetti in uscita a cui si riferiscono, poiché ENTRAMBI i meccanismi si basano sul superamento dei messaggi ICMP TTL che ritornano al mittente dai salti lungo il percorso.

— Jed Daniels,

-1

Puoi potenziare il tuo traceroute disabilitando la ricerca DNS inversa, che spesso fallisce: tracert -d www.google.com

— Castello di Mathieu
fonte

Ciò non accelera i tempi di andata e ritorno. Tuttavia, rende più veloce la restituzione dei risultati sullo schermo, poiché non esegue le ricerche DNS.

— Jed Daniels,