¿Por qué el traceroute tarda mucho más que el ping?

16

¿Cómo explicar esto?

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.

Entonces, el tiempo promedio debe ser: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, que es mucho más grande que 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
fuente
3
Tantas malas respuestas a esta pregunta. Todos me recuerdan, en cierto modo, youtube.com/watch?v=SXmv8quf_xM
Tom O'Connor

Respuestas:

16

No puedes simplemente sumar todos esos números. Ese es el tiempo de ping para cada uno de los saltos en el camino a google. Entonces, de forma nativa, cada tramo del camino se aleja más y más y se ven diferentes tiempos de ping. Si observa el último tiempo de ping en tracert (34 ms) y el tiempo que recibió cuando emitió el ping (34 ms), estos son los mismos. El programa tracert no es más lento que el ping.

Sugeriría leer sobre cómo funciona un traceroute:
http://en.wikipedia.org/wiki/Traceroute

einstiien
fuente
No es farther and farther away.
No entiendo lo que quieres decir. Cada dirección IP que figura en el traceroute es la dirección del siguiente enrutador en línea entre usted y Google. En la topología de red "lógica", éstas se alejan a medida que avanza en la lista. Además, en su mayor parte, se alejan físicamente de su ubicación geográfica. Aunque esto no siempre es cierto ya que a veces las rutas parecen saltar "innecesariamente" en el mapa. Pero mi punto es que la distancia física y los saltos múltiples aumentan el tiempo de ping.
einstiien
Intente hacer ping a cada nodo en la ruta. Deberías obtener el mismo total (aproximadamente).
Chris Nava
1
¿Quizás PHP está en el sitio de stackoverflow incorrecto y significa que más lejos se refiere a la distancia física mientras que más lejos es más apropiado para la distancia de red? english.stackexchange.com
dunxd
12

Puedes ver el ping como un viaje en automóvil desde Nueva York a San Francisco. Lleva, digamos 200 horas (soy de Suiza y no estoy familiarizado con las distancias en los EE. UU.)

Pero el Conductor tiene que regresar a Nueva York para decirte que estaba en San Francisco. Le echas un vistazo al reloj y ahora calculas que tomó 400 horas para la distancia. Ahora eso es lo que hace Ping. Lo que hace Traceroute es: decirle a su conductor que debe conducir desde Nueva York a San Franciso y que cada vez que se cruce en una encrucijada debe regresar y decirle el nombre. Así que está en camino y las primeras encrucijadas están en Nueva York. Entonces él es bastante rápido con conducir de regreso a ti y decirte el nombre de la encrucijada. Pero cuando llegue más lejos, tardará más en volver a ti. y así...

Entonces, si cuenta todas las horas de manejo que estaba en camino, tardaría mucho más en informar todos los cruces de caminos que si solo tuviera que conducir a San Francisco. Espero que esto te aclare algunas cosas ...

Bona
fuente
2
Una mejor analogía sería enviar 30 conductores, diciéndoles a cada uno que se dirijan hacia Nueva York, pero cada uno de ellos debe darse la vuelta y regresar en la primera encrucijada, la segunda encrucijada, la tercera encrucijada, etc. el camino hasta treinta encrucijadas (con la esperanza de que haya menos de 30 entre SF y NY).
Jed Daniels
0

De hecho, se debe básicamente al hecho de que PING envió una solicitud ICMP a través de la red al DNS y al dispositivo de otra red.

Sin embargo, Traceroute envía muchos paquetes con un TTL realmente corto.

Por ejemplo, cuando intentas unirte a www.google.com desde tu asiento, traceroute envió un paquete a www.google.com con un TTL establecido en 1, y espera una respuesta del dispositivo de la red del primer encuentro.

Luego, Traceroute muestra la IP del primer dispositivo de la red en su pantalla, y luego hará lo mismo, pero esta vez con un TTL establecido en 2, etc.

Al final, Traceroute ha esperado aproximadamente medio tiempo más porque, en cada envío, está esperando la respuesta del dispositivo de una red.

Dr. I
fuente
0

Traceroute siempre le dice el promedio al destino, no una acumulación de tiempos, es decir, en su caso, son 34 ms con pingy traceroute.

Si traceroute hiciera lo que sugieres, su salida sería bastante ilegible.

Si solo está interesado en el tiempo de respuesta del destino, pinges suficiente, traceroutees para cuando necesita depurar algo en la ruta al destino. Además, todos los saltos entre usted y el destino son enrutadores, y la mayoría de las veces, los enrutadores tienen prioridad sobre qué hacer, es decir, primero los paquetes de ruta y luego responden a ping o traceroute (es decir, el primer caso, respondiendo a icmp echo reply, y en el segundo caso, a icmp time exceeded) y a menudo responden más lentamente (cuando responden)

estera
fuente
0

Para la posteridad, ya que ninguna de las respuestas correctas es muy clara ...

-

Cada vez que se muestra en el trazado de ruta es el TIEMPO TOTAL desde SU MÁQUINA (o la máquina que realiza el trazado de ruta ...) hasta ESE NODO EN PARTICULAR.

En otras palabras, el tiempo que se muestra en el segundo nodo no es el tiempo transcurrido entre los nodos 1 y 2, sino el tiempo total transcurrido entre la fuente, el primer nodo y el segundo nodo todos juntos.

Por lo tanto, en promedio, los tiempos que se muestran en cada nodo deben coincidir aproximadamente con los tiempos que obtendría si hiciera ping a ese nodo en particular "directamente" (en realidad no es más directo que un traceroute ... generalmente seguirá el mismo camino En Internet).

Solo tenga en cuenta que existe un "pico de retraso". La forma más precisa de encontrar el origen de cualquier retraso es ejecutar un traceroute en repetición utilizando un archivo por lotes (si está en Windows), y encontrar el nodo más cercano (con el número más bajo) que tenga números altos en un momento dado.

-

Para el archivo por lotes, abra el bloc de notas y escriba estas 3 líneas:

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

Luego guárdelo como "Trace.bat", pero asegúrese de cambiar el tipo de archivo en el diálogo de guardar a "todos los archivos" antes de guardarlo o de lo contrario se guardará como un archivo de texto.

Cuando se abre, esto ejecutará constantemente traceroutes (a google). Puede detenerlo presionando ctrl + c mientras tiene la ventana seleccionada.

-

Por supuesto, puede cambiar dónde está ejecutando el traceroute cambiando "www.google.com" a la dirección que desee.

También puede eliminar la opción "-d" si desea ver los nombres de host resueltos, pero esto hará que el traceroute tome más tiempo debido a que dichos nombres de host provienen de un servidor DNS para cada nodo (sin embargo, esto NO cambia los resultados reales) )

Por último, si encuentra un nodo con tiempos altos y solo desea ejecutar traceroutes a ese nodo en particular en caso de que otro nodo antes tenga problemas, puede cambiar "www.google.com" a la dirección IP o nombre de host de ese nodo, O puede usar la opción -h para especificar cuántos nodos buscar, es decir ...

:start
tracert -d -h 5 www.google.com
goto start
Laike Endaril
fuente
Una nota importante es que un nodo responde con ICMP, pero el propósito principal de un enrutador es enrutar paquetes, y crear respuestas ICMP está muy por debajo de la lista de lo que hace. Un enrutador se enrutará, y podrá enviar mensajes ICMP cuando llegue el momento. Es por eso que el tiempo intermedio podría ser más largo que el camino completo; el enrutador intermedio podría estar mucho más ocupado que el nodo final.
Ron Maupin
Sí, la prioridad de calidad de servicio de ICMP suele ser menor, pero a menudo, cuando ejecuta un traceroute, es porque ya existe un problema (está teniendo picos de retraso o mal ping en un juego), y ese nodo en particular que mencionó ( el ocupado) es el cuello de botella que estás buscando.
Laike Endaril
No me refiero a la prioridad de QoS, me refiero al dispositivo en sí mismo que crea una respuesta ICMP. El nodo puede estar demasiado ocupado enrutando paquetes para enviar un mensaje ICMP antes de que el nodo original agote el tiempo de espera. Un enrutador enrutará los paquetes antes de decidir enviar un mensaje ICMP. Eso no tiene nada que ver con QoS.
Ron Maupin
QoS es un término muy poco definido, y considero que incluye todas las actividades que usan el mismo conjunto de recursos, en lugar de excluir las actividades que requieren atención adicional (construir un paquete de respuesta). Sin embargo, de cualquier manera, eso no cambia el hecho de que dicho enrutador está bajo una carga demasiado pesada y está destinado a causar problemas, por lo que los tiempos altos de un traceroute siguen siendo un buen indicador de dónde se encuentran sus problemas ... con el posible excepción de una gran cantidad de tráfico que tiene una prioridad más alta que su ICMP pero una prioridad más baja que su tráfico normal.
Laike Endaril
-1

Debido a que tracert usa paquetes UDP, como ping usa paquetes ICMP. En Linux, tenemos la traceroute -Iopción de hacer un trazado ICMP.

En su prueba, el tiempo para conectarse a google es el mismo en traceroute y ping: 34ms. Todos los enrutadores del medio tienen su propio tiempo para responder pero no afectan el tiempo de transferencia final.

http://en.wikipedia.org/wiki/Traceroute explica todo en Traceroute

Dom
fuente
3
En realidad, en Windows, tracertusa ICMP por defecto, a diferencia de Linux traceroute.
phoebus
tracert utiliza el período ICMP. ICMP es el protocolo IP 1, UDP es 17.
dbasnett
@dbasnett Originalmente, traceroute envió paquetes salientes como UDP, y los paquetes de retorno son, por supuesto, mensajes superados por ICMP TTL. Windows y ahora otros programas de traceroute usan paquetes de solicitud de eco ICMP para el saliente. Por lo general, cuando las personas se refieren a UDP traceroute o ICMP traceroute son a estos paquetes salientes a los que se refieren, ya que AMBOS mecanismos dependen de ICMP TTL excedieron los mensajes que regresan al remitente desde los saltos a lo largo de la ruta.
Jed Daniels
-1

Puede aumentar su traceroute deshabilitando la búsqueda de DNS inversa, que a menudo falla: tracert -d www.google.com

Mathieu Chateau
fuente
Esto no hace que los tiempos de ida y vuelta sean más rápidos. Sin embargo, hace que sea más rápido devolver resultados en su pantalla, ya que no realiza las búsquedas de DNS.
Jed Daniels