Некоторые из ответов здесь используют ping и traceroute для своих объяснений. Эти инструменты имеют свое место, но они не надежны для измерения производительности сети.
В частности, (по крайней мере, некоторые) маршрутизаторы Juniper отправляют обработку событий ICMP в плоскость управления маршрутизатора. Это НАМНОГО медленнее, чем плоскость пересылки, особенно в магистральном маршрутизаторе.
Существуют другие обстоятельства, когда ответ ICMP может быть намного медленнее, чем фактическая производительность пересылки маршрутизатора. Например, представьте себе полностью программный маршрутизатор (без специального оборудования для пересылки), который загружен на 99% процессорной мощности, но по-прежнему нормально обрабатывает трафик. Вы хотите потратить много циклов на обработку ответов traceroute или пересылку трафика? Таким образом, обработка ответа является супер низким приоритетом.
В результате ping / traceroute дают вам разумные верхние границы - дела идут, по крайней мере, так быстро, - но они на самом деле не говорят вам, как быстро идет реальный трафик.
В любом случае -
Вот пример трассировки из Мичиганского университета (центральная часть США) в Стэнфорд (западное побережье США). (Это происходит из Вашингтона, округ Колумбия (восточное побережье США), которое находится в 500 милях в «неправильном» направлении.)
% 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
В частности, обратите внимание на разницу во времени между результатами traceroute для маршрутизатора стирки и маршрутизатора atla (переходы 7 и 8). сетевой путь идет сначала, чтобы вымыть и затем к атле. для ответа требуется 50-100 мс, для атла - около 28 мс. Очевидно, что атла находится еще дальше, но результаты ее трассировки показывают, что она ближе.
Смотрите http://www.internet2.edu/performance/ для большого количества информации об измерении сети. (Отказ от ответственности, я работал на интернет2). Также смотрите: https://fasterdata.es.net/
Чтобы добавить определенную релевантность к исходному вопросу ... Как вы можете видеть, у меня было 83 мс времени пинга в Стэнфорд, поэтому мы знаем, что сеть может работать по крайней мере так быстро.
Обратите внимание, что путь к научно-образовательной сети, который я выбрал для этой трассировки, скорее всего, будет быстрее, чем обычная интернет-связь. Сети R & E обычно обеспечивают избыточное количество соединений, что делает буферизацию в каждом маршрутизаторе маловероятной. Также обратите внимание на длинный физический путь, более длинный, чем от побережья к побережью, хотя он явно отражает реальный трафик.
Мичиган-> Вашингтон, округ Колумбия, Атланта-> Хьюстон, Лос-Анджелес, Стэнфорд
