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

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

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

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

Имеет смысл, что Корваллис, штат Орегон, географически ближе к моему местоположению в Беркли, Калифорния, поэтому я ожидаю, что соединение будет немного быстрее .. но я вижу увеличение задержки на +100 мс, когда я выполняю тот же тест в Нью-Йорке сервер. Мне это кажется чрезмерным. Тем более что время, затрачиваемое на передачу фактических данных, увеличилось только на 10%, а задержка увеличилась на 100%!

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

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

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

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

Скорость света:
Вы не собираетесь превзойти скорость света как интересный академический момент. Эта ссылка работает из Стэнфорда в Бостон за ~ 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

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

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

Трансатлантический путь
NY      78    London
Wash    87    Frankfurt

Транстихоокеанский путь
SF     147    Hong Kong

Трансамериканский путь
SF      72    NY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я вижу стойкие различия и сижу в Норвегии:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Время в Нью-Йорке:

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