Какая латентность сети является «типичной» для восточно - западного побережья США?

107

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

Тем не менее, я вижу некоторые тревожные цифры латентности от моего западного побережья до восточного побережья. Вот пример результата, извлекая небольшой файл логотипа .png в Google Chrome и используя инструменты разработчика, чтобы увидеть, сколько времени занимает запрос:

  • От западного побережья до восточного:
    задержка 215 мс, время передачи 46 мс, всего 261 мс
  • От западного побережья до западного:
    задержка 114 мс, время передачи 41 мс, всего 155 мс

Имеет смысл, что Corvallis, OR географически ближе к моему местоположению в Беркли, Калифорния, поэтому я ожидаю, что соединение будет немного быстрее ... но я вижу увеличение задержки + 100 мс, когда я выполняю тот же тест для NYC сервер. Это кажется .. чрезмерным для меня. В частности, поскольку время, затраченное на передачу фактических данных, увеличилось только на 10%, а задержка увеличилась на 100%!

Это чувствует себя ... неправильно ... для меня.

Я нашел несколько ссылок, которые были полезны (через Google не меньше!) ...

... но ничего авторитетного.

Так это нормально? Это не чувствует себя нормально. Какую «типичную» задержку я должен ожидать при перемещении сетевых пакетов с восточного побережья на западное побережье США?

Джефф Этвуд
источник
10
Любые измерения в сетях, которые вы не контролируете, кажутся почти бессмысленными. Слишком часто в этих типах сетевых обсуждений кажется, что мы забываем, что есть временный компонент, связанный с каждым пакетом. Если вы неоднократно проходили тест 24 x 7 и пришли к какому-то заключению, это одно. Если вы запускали тест дважды, я советую вам провести его еще раз. А для тех, кто выступает за использование пинга в качестве меры производительности, нет. В каждой крупной сети, над которой я когда-либо работал, мы устанавливаем трафик ICMP с самым низким приоритетом. Пинг означает только одну вещь, и это не;) о производительности.
dbasnett
Оттуда, где я живу, Джефферсон-Сити, Миссури, времена похожи.
dbasnett
4
В качестве примечания: самому свету требуется ~ 14 мс, чтобы проехать от Нью-Йорка до SF по прямой (с учетом оптоволокна).
Шадок
Свет в волокне движется с коэффициентом скорости 0,67 (эквивалентно показателю преломления) ~ 201 000 км / с, поэтому он составляет не менее 20 мс.
Zac67,

Ответы:

114

Скорость Света:
Вы не собираетесь преодолевать скорость света как интересную академическую точку. Эта ссылка работает из Стэнфорда в Бостон в наилучшее время ~ 40 мс. Когда этот человек сделал расчет, он решил, что интернет работает примерно «в два раза быстрее скорости света», поэтому время передачи составляет около 85 мс.

Размер окна TCP:
Если у вас возникают проблемы со скоростью передачи, вам может потребоваться увеличить размер tcp окна приема. Вам также может понадобиться включить масштабирование окна, если это соединение с высокой пропускной способностью и высокой задержкой (называется «длинная толстая труба»). Поэтому, если вы передаете большой файл, вам нужно иметь достаточно большое окно приема, чтобы заполнить канал, не дожидаясь обновления окна. Я подробно рассказал о том, как рассчитать это в своем ответе « Настройка слона» .

География и латентность.
Недостатком некоторых CDN (сетей распространения контента) является то, что они приравнивают латентность и географию. Google провел много исследований с их сетью и обнаружил в этом недостатки, они опубликовали результаты в официальном документе « Переход от сквозной информации о пути к оптимизированной производительности CDN» :

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

Одноранговые соединения BGP.
Также, если вы начнете изучать BGP (основной протокол интернет-маршрутизации) и то, как интернет-провайдеры выбирают одноранговые соединения, вы обнаружите, что зачастую это больше касается финансов и политики, поэтому вы не всегда можете найти «лучший» маршрут в определенных географических точках в зависимости от географического местоположения. на вашем провайдере. Вы можете посмотреть, как ваш IP подключен к другим провайдерам (автономным системам) с помощью маршрутизатора с зеркалом . Вы также можете воспользоваться специальным сервисом whois :

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

Также интересно исследовать их как пиринги с помощью графического инструмента, такого как linkrank , он дает вам представление об интернете вокруг вас.

Кайл Брандт
источник
согласитесь, скорость света по прямой линии - лучшее, что вы можете сделать. Кстати, отличный ответ, это именно то, что я искал. Спасибо.
Джефф Этвуд
4
Для любопытных фактическая математика такова: 3000 миль / с = 16,1 мс
Тайлер
15
В вакууме фотон может перемещаться по экватору примерно за 134 мс. Тот же самый фотон в стекле займет около 200 мс. На 3000 миль куска волокна приходится 24 мс. задержки без каких-либо устройств.
dbasnett
11
Это напоминает мне о случае 500-мильной электронной почты .
Багамат
42

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

Трансатлантический путь
Нью-Йорк 78 Лондон
Wash 87 Франкфурт
Транстихоокеанский путь
SF 147 Гонконг
Транс-США Путь
SF 72 NY

сетевая задержка по парам городов мира

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

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

Они были измерены с помощью инструментов разработчика Google Chrome.

Рич Адамс
источник
2
классный график! Нью-Йорк в SF в настоящее время 71 msна нем, так что вы правы - мы не можем ожидать, что будет лучше, чем это.
Джефф Этвуд
Благодарю. Это мне очень помогло. Это еще один источник для поиска сетевых задержек между разными точками
Саджиб Махмуд,
10

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

Исходя из ответа Рича Адамса и использования сайта, который он рекомендовал, вы можете видеть, что для магистрали AT & T требуется 72 мсек, чтобы трафик ICMP перемещался между конечными точками SF и NY. Это справедливое число, но вы должны помнить, что это сеть, которая полностью контролируется AT & T. При этом не учитывается переход к домашней или офисной сети.

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

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

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

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

Михаил Горсух
источник
7

Некоторые из ответов здесь используют 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 обычно обеспечивают избыточное количество соединений, что делает буферизацию в каждом маршрутизаторе маловероятной. Также обратите внимание на длинный физический путь, более длинный, чем от побережья к побережью, хотя он явно отражает реальный трафик.

Мичиган-> Вашингтон, округ Колумбия, Атланта-> Хьюстон, Лос-Анджелес, Стэнфорд

Дэн Приттс
источник
6

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

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

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

Трассировка на сервер

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.

Проследить к карьере

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 прыжков, а затем заканчивается.

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

Lasse Vågsæther Karlsen
источник
1
Да, ожидается, что датацентр на восточном побережье будет более дружественным для нашей европейской аудитории - вы видите, что время, затрачиваемое на преодоление ширины США, составляет + 200 мс. Должно быть только ~ 80 мс для других ответов, хотя?
Джефф Этвуд
похоже, что он согласован на уровне около 200 мс, я обновил обновление 20-30 раз на обоих (но не в одно и то же время), а сайт serverfault выглядит так, как будто он завис на 200 мс +/- больше, чем на другом , Я попробовал traceroute, но на всех он встречается со звездами, поэтому, возможно, наши ИТ-администраторы что-то заблокировали.
Lasse Vågsæther Karlsen
2

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

Было бы интересно увидеть, где вы получаете задержку - попробуйте такой инструмент, как traceroute уровня 4 (lft). Скорее всего, многое получено на «последней миле» (т. Е. У вашего местного широкополосного провайдера).

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

BrianEss
источник
2

Просто для удовольствия, когда я играл в онлайн-игру Lineage 2 NA, выпущенную из Европы:

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

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

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

Оскар Дювеборн
источник
2

у всех здесь есть кое-что действительно хорошее. и правы в своем собственном POV.

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

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

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

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

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

В результате были получены значения задержек от 88 до 100 мс от двери до двери в офисах. Это не включало какие-либо номера задержки между офисами сети.

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

Джим Адкокс
источник
1

Нью-Йорк Таймс:

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
Том Риттер
источник