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


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

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

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

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

Это кажется ... неправильным ... для меня.

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

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

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


98
2018-04-30 11:26


Источник


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


Ответы:


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

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

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

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

BGP Peerings:
Также, если вы начнете изучать протокол BGP (основной протокол интернет-маршрутизации) и как провайдеры выбирают peerings, вы обнаружите, что он часто больше связан с финансами и политикой, поэтому вы не всегда можете получить «лучший» маршрут в определенные географические местоположения в зависимости от вашего провайдера , Вы можете посмотреть, как ваш 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

Это также интересно изучить их как peerings с помощью инструмента gui, например linkrank, он дает вам изображение интернета вокруг вас.


108
2018-04-30 12:03



согласитесь, скорость света, поскольку ворона - это лучшее, что вы можете сделать. Действительно отличный ответ, кстати, это именно то, что я искал. Спасибо. - Jeff Atwood
Для любопытных фактическая математика: 3000 миль / с = 16,1 мс - tylerl
В вакууме фотон может перемещаться по экватору примерно в 134 мс. Тот же фотон в стекле займет около 200 мс. У 3 000-миллиметровой части волокна есть 24 мс. задержки без каких-либо устройств. - dbasnett
Это напоминает мне Случай с 500-мильной электронной почтой, - bahamat


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

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

network latency by world city pairs

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

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

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


40
2018-04-30 11:45



крутой график! NY в SF в настоящее время 71 ms на этом, так что вы правы - мы не можем рассчитывать на улучшение. - Jeff Atwood
Благодарю. Это мне очень помогло. Это еще один источник для поиска латентности сети между разными местами мира - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


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

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

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

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

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

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


10
2018-04-30 17:34





Некоторые из ответов здесь используют ping и traceroute для их объяснений. Эти инструменты имеют свое место, но они не являются надежными для измерения производительности сети.

В частности, (по крайней мере, некоторые) маршрутизаторы Juniper отправляют обработку ICMP-событий на плоскость управления маршрутизатора. Это МНОГО медленнее, чем плоскость пересылки, особенно в магистральном маршрутизаторе.

Существуют и другие обстоятельства, при которых ответ ICMP может быть намного медленнее, чем фактическая производительность пересылки маршрутизатора. Например, представьте себе универсальный маршрутизатор (без специализированного оборудования для переадресации), который находится на 99% от емкости ЦП, но он все еще движет штрафом. Вы хотите, чтобы он потратил много циклов обработки ответов traceroute или пересылки трафика? Таким образом, обработка ответа является сверхнизким приоритетом.

В результате, ping / traceroute дают вам разумные верхние границы - все идет по крайней мере так быстро, - но они на самом деле не говорят вам, как быстро идет реальный трафик.

В любом случае -

Вот пример 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). сетевой путь идет сначала, чтобы мыть, а затем в atla. мытье занимает 50-100 мс для ответа, atla занимает около 28 мс. Ясно, что атла еще далеко, но результаты ее трассировки показывают, что он ближе.

Видеть http://www.internet2.edu/performance/ для большого количества информации о измерении сети. (отказ от ответственности, я использовал для работы в Интернете2). Также см: https://fasterdata.es.net/

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

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

michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford


7
2017-08-15 15:46





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

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

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

Traceroute to 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 для моего размещенного сервера для их выполнения


6
2018-04-30 11:43



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


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

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

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


2
2018-04-30 11:42





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

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

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

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


2
2018-04-30 12:52





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

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

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

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

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

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

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

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


2
2017-09-09 15:43





NYC Сроки:

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

1
2018-04-30 12:10