Varias de las respuestas aquí están usando ping y traceroute para sus explicaciones. Estas herramientas tienen su lugar, pero no son confiables para la medición del rendimiento de la red.
En particular, (al menos algunos) enrutadores Juniper envían el procesamiento de eventos ICMP al plano de control del enrutador. Esto es MUCHO más lento que el plano de reenvío, especialmente en un enrutador de red troncal.
Existen otras circunstancias en las que la respuesta ICMP puede ser mucho más lenta que el rendimiento de reenvío real de un enrutador. Por ejemplo, imagine un enrutador totalmente de software (sin hardware de reenvío especializado) que esté al 99% de la capacidad de la CPU, pero que todavía esté moviendo bien el tráfico. ¿Desea que pase muchos ciclos procesando respuestas de traceroute o reenviando tráfico? Por lo tanto, procesar la respuesta es una prioridad súper baja.
Como resultado, ping / traceroute le da límites superiores razonables (las cosas van al menos tan rápido), pero en realidad no le dicen qué tan rápido va el tráfico real.
En cualquier evento -
Aquí hay un ejemplo de trazado de ruta desde la Universidad de Michigan (centro de EE. UU.) Hasta Stanford (costa oeste de EE. UU.). (Resulta que pasa por Washington, DC (costa este de EE. UU.), Que está a 500 millas en la dirección "incorrecta".
% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
1 * * *
2 * * *
3 v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130) 3.808 ms 4.225 ms 2.223 ms
4 l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131) 1.372 ms 1.281 ms 1.485 ms
5 l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8) 1.784 ms 0.874 ms 0.900 ms
6 v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69) 2.443 ms 2.412 ms 2.957 ms
7 v0x1004.rtr.wash.net.internet2.edu (192.122.183.10) 107.269 ms 61.849 ms 47.859 ms
8 ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6) 28.267 ms 28.756 ms 28.938 ms
9 xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112) 52.075 ms 52.156 ms 88.596 ms
10 * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96) 496.838 ms
11 hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133) 76.537 ms 78.948 ms 75.010 ms
12 svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38) 82.151 ms 82.304 ms 82.208 ms
13 hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62) 82.504 ms 82.295 ms 82.884 ms
14 boundarya-rtr.stanford.edu (171.66.0.34) 82.859 ms 82.888 ms 82.930 ms
15 * * *
16 * * *
17 www-v6.stanford.edu (171.67.215.200) 83.136 ms 83.288 ms 83.089 ms
En particular, observe la diferencia de tiempo entre los resultados del traceroute del enrutador de lavado y el enrutador atla (saltos 7 y 8). la ruta de red va primero a lavar y luego a atla. el lavado tarda 50-100 ms en responder, el atla tarda unos 28 ms. Claramente, el atla está más lejos, pero sus resultados de traceroute sugieren que está más cerca.
Consulte http://www.internet2.edu/performance/ para obtener mucha información sobre la medición de red. (descargo de responsabilidad, solía trabajar para internet2). Ver también: https://fasterdata.es.net/
Para agregar alguna relevancia específica a la pregunta original ... Como puede ver, tuve un tiempo de ping de ida y vuelta de 83 ms para Stanford, por lo que sabemos que la red puede ir al menos tan rápido.
Tenga en cuenta que la ruta de la red de investigación y educación que tomé en este trazado es probable que sea más rápida que una ruta de Internet de productos básicos. Las redes de R&E generalmente sobreaprovisionan sus conexiones, lo que hace poco probable el almacenamiento en búfer en cada enrutador. Además, tenga en cuenta el largo camino físico, más largo que de costa a costa, aunque claramente representativo del tráfico real.
michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford
