Этот сайт предложил бы вокруг 70-80ms задержки между Востоком/Западным побережьем, США типичны (Сан-Франциско в Нью-Йорк, например).

Trans-Atlantic Path
NY      78    London
Wash    87    Frankfurt

Trans-Pacific Path
SF     147    Hong Kong

Trans-USA Path
SF      72    NY

Вот мои синхронизации (я нахожусь в Лондоне, Англия, таким образом, мои времена Западного побережья выше, чем Восток). Я получаю различие в задержке на 74 мс, которое, кажется, поддерживает значение от того сайта.

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

Они измерялись с помощью Google Chrome dev инструменты.

Мера с ICMP сначала, если вообще возможный. Тесты ICMP обычно используют очень маленькую полезную нагрузку по умолчанию, не используйте трехстороннее квитирование, и не должны взаимодействовать с другим приложением, стек как HTTP делает. Безотносительно случая это имеет наибольшее значение, что результаты HTTP не становятся путавшими с результатами ICMP. Они - яблоки и апельсины.

Движение ответом Rich Adams и использования сайта, который он рекомендовал, Вы видите, что на магистрали AT&T, требуется 72 мс для трафика ICMP для перемещения между их SF и нью-йоркскими конечными точками. Это - достаточное количество, чтобы пройти, но необходимо иметь в виду, что это находится в сети, которой полностью управляет AT&T. Это не принимает во внимание переход к Вашей домашней или офисной сети.

Если Вы делаете ping против careers.stackoverflow.com от Вашей исходной сети, необходимо видеть что-то не слишком далеко 72 мс (возможно, +/-20 мс). Если это так, затем можно, вероятно, предположить, что сетевой путь между двумя из Вас хорошо и работающий в нормальных диапазонах. В противном случае не паникуйте и имейте размеры от нескольких других мест. Это мог быть Ваш ISP.

Принимая, который передал, Ваш следующий шаг должен заняться прикладным уровнем и определить, существует ли что-то не так с дополнительными издержками, Вы видите со своими Запросами HTTP. Это может варьироваться от приложения до приложения из-за аппаратных средств, ОС и стека приложений, но так как у Вас есть примерно идентичное оборудование и на Восточных и на Западных побережьях, Вы могли сделать, чтобы пользователи Восточного побережья поразили серверы Западного побережья, и пользователи Западного побережья поражают Восточное побережье. Если бы оба сайта настроены правильно, я ожидал бы видеть все числа, чтобы быть более менее равным и поэтому продемонстрировать, что то, что Вы видите, является в значительной степени паритетом для крупного.

Если бы те времена HTTP имеют широкое различие, я не был бы удивлен, была ли проблема конфигурации о более медленном сайте выполнения.

Теперь, после того как Вы в этой точке, можно попытаться сделать некоторую более агрессивную оптимизацию на стороне приложения, чтобы видеть, может ли то количество быть сокращено вообще. Например, если Ваш используют IIS 7, Вы используете в своих интересах его возможности кэширования и т.д.? Возможно, Вы могли выиграть что-то там, возможно, нет. Когда дело доходит до тонкой настройки объектов низкого уровня, таких как окна TCP, я очень скептически настроен, что она оказала бы большую часть влияния для чего-то как Переполнение стека. Но эй - Вы не будете знать, пока Вы не попробуете его и мера.

Я вижу приблизительно 80-90ms задержку на хорошо выполнении, хорошо измеряемых ссылках между Восточными и Западными побережьями.

Было бы интересно видеть, где Вы получаете задержку - пробуют инструмент как слой четыре traceroute (lft). Возможности являются большим количеством его, получен на "последней миле" (т.е. в Вашем локальном поставщике услуг широкополосного доступа).

То, что на время трансфера незначительно повлияли, должно ожидаться - потеря пакетов и дрожание являются более полезными измерениями для взгляда на при исследовании различий во времени трансфера между двумя местами.

Только для забавы, когда я играл Происхождение онлайн-игры 2 выпуска NA из Европы:

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

Различие, кажется, поддерживает это, до 100 мс в причине, рассматривая непредсказуемый характер Интернета.

Используя приветствуемый тест обновления Chrome, я получаю время загрузки документа, которое не соглашается примерно с 130 мс.

Синхронизации Нью-Йорк Сити:

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

Используя Chrome, на жилом соединении.

Используя lft от VPS в центре обработки данных в Ньюарке, Нью-Джерси:

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
 1  207.192.75.2 0.4/0.5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
 4  nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
 6  216.187.115.145 2.7/2.2ms
 7  64.34.60.28 2.3/1.8ms
 8  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36.4/0.6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
 7  192.205.34.53 2.1/2.1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13  12.118.177.74 82.9/82.8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms

Я вижу последовательные различия, и я сижу в Норвегии:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

Это измерялось с научным точным и испытанным методом использования представления ресурсов Google Chrome и просто неоднократно обновления каждой ссылки.

Traceroute к serverfault

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

Traceroute к карьере

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

К сожалению, это теперь начинает входить в цикл или этажерку и продолжает давать звезды и тайм-аут до 30 транзитных участков и затем заканчивается.

Отметьте, traceroutes от другого хоста, чем синхронизации в запуске, я имел к RDP к моему размещенному серверу для выполнения их

Некоторые из ответы здесь используют 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

В частности, обратите внимание на разницу во времени между результатами трассировки маршрутизатора wash и маршрутизатора atla (переходы 7 и 8). сетевой путь сначала идет на промывку, а затем на атла. Wash занимает 50–100 мсек, atla - около 28 мсек. Очевидно, что atla находится дальше, но результаты его трассировки показывают, что он ближе.

См. http://www.internet2.edu/performance/ для получения дополнительной информации об измерениях сети. (отказ от ответственности, я работал в internet2). См. Также: https://fasterdata.es.net/

Чтобы добавить определенную релевантность к исходному вопросу ... Как вы можете видеть, у меня было время пинга в оба конца до Стэнфорда 83 мс, поэтому мы знайте, что сеть может работать хотя бы так быстро.

Обратите внимание, что исследование & Путь к образовательной сети, который я выбрал для этого traceroute, вероятно, будет быстрее, чем обычный интернет-путь. Сети R&E обычно избыточно предоставляют свои соединения, что делает маловероятной буферизацию в каждом маршрутизаторе. Также обратите внимание на длинный физический путь, более длинный, чем от побережья до побережья, хотя он явно отражает реальное движение.

мичиган-> вашингтон, округ Колумбия-> атланта-> хьюстон-> лос-анджелес-> стэнфорд

У всех здесь есть действительно хорошие мысли. и верны в своей точке зрения.

И все сводится к тому, что здесь нет настоящего точного ответа, потому что существует так много переменных, что любой ответ всегда может быть ошибочным, просто изменив одну из ста переменных.

Подобно задержке 72 мс от NY до SF, это задержка от PoP до PoP носителя пакета. Это не принимает во внимание какие-либо другие важные моменты, на которые здесь указали некоторые, о перегрузке, потере пакетов, качестве обслуживания, неупорядоченных пакетах или размере пакета или перенаправлении сети только между идеальным миром PoP в PoP. .

И затем, когда вы добавляете последнюю милю (обычно много миль) от точки доступа к вашему фактическому местоположению в двух городах, где все эти переменные становятся гораздо более плавными, вещь начинает экспоненциально увеличиваться из-за разумной способности догадываться!

В качестве примера я провел тест между городами Нью-Йорк и Сан-Франциско в течение рабочего дня. Я сделал это в тот день, когда в мире не происходило серьезных «инцидентов», которые могли бы вызвать всплеск трафика. Так что, возможно, это было не в среднем в современном мире! Но тем не менее это была моя проверка. Я фактически измерял расстояние от одного места работы до другого за этот период и в обычные часы работы каждого побережья.

В то же время,Я отслеживал номера провайдеров каналов в сети.

Результаты были числами задержки от 88 до 100 мс от двери до двери в офисах. При этом не учитывались данные о задержке в сети между офисами.

Время задержки в сети поставщика услуг составляло от 70 до 80 мс. Это означает, что задержка последней мили может составлять от 18 до 30 мс. Я не сопоставил точные пики и минимумы между двумя средами.