Наскільки затримка мережі "типова" для східно-західного узбережжя США?


106

На даний момент ми намагаємося вирішити, чи перенести наш центр обробки даних із західного узбережжя на східне.

Однак я бачу деякі тривожні затримки від мого розташування на західному узбережжі до східного узбережжя. Ось зразок результату, витягнення невеликого .png-логотипу в Google Chrome та використання інструментів розробника, щоб дізнатися, скільки часу займає запит:

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

Має сенс, що Корваліс, АБО географічно ближче до мого місця розташування в Берклі, штат Каліфорнія, тому я очікую, що зв’язок буде трохи швидшим .., але я бачу збільшення затримки + 100 мс, коли я виконую те саме тест до Нью-Йорку сервер. Це здається мені надмірним. Тим більше, що час, витрачений на передачу фактичних даних, лише збільшився на 10%, але затримка зросла на 100%!

Це відчуває ... неправильно ... для мене.

Тут я знайшов кілька посилань, які були корисними (через Google не менше!) ...

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

Отже, це нормально? Це не нормально. Яку "типову" затримку я повинен очікувати при переміщенні мережевих пакетів із східного узбережжя <--> західного узбережжя США?


10
Будь-яке вимірювання в мережах, якими ви не керуєте, здається майже безглуздим. Занадто часто в таких типах мережевих дискусій здається, що ми забуваємо, що тимчасовий компонент пов'язаний з кожним пакетом. Якщо ви проходили тест неодноразово 24 х 7 і прийшли до якогось висновку, це одне. Якщо ви пройшли тест двічі, то пропоную вам ще трохи пройти його. А тим, хто виступає за використання ping як певного показника продуктивності, не варто. У всіх основних мережах, над якими я коли-небудь працював, ми встановлювали ICMP-трафік як найнижчий пріоритет. Ping означає лише одне, і це не;) про продуктивність.
dbasnett

З того місця, де я живу, Джефферсон Сіті, штат Міссурі, часи схожі.
dbasnett

4
Як бічна примітка: світло займає ~ 14 мс, щоб подорожувати від Нью-Йорка до СФ по прямій лінії (зважаючи на волокно на всьому шляху).
Шадок

Світло у волокні рухається з коефіцієнтом швидкості .67 (еквівалентно показнику заломлення) ~ 201 000 км / с, тож принаймні 20 мс.
Zac67

Відповіді:


114

Швидкість світла:
Ви не збираєтеся бити швидкість світла як цікавий академічний момент. Це посилання працює в Стенфорд - Бостон в найкращий час ~ 40 мс. Коли ця людина зробила підрахунок, він вирішив, що Інтернет працює приблизно з «двома швидкостями світла», тому час передачі становить близько ~ 85 мс.

Розмір вікна TCP:
Якщо у вас виникають проблеми зі швидкістю передачі, можливо, вам доведеться збільшити розмір tcp вікна прийому. Можливо, вам також знадобиться включити масштабування вікон, якщо це з'єднання з високою пропускною здатністю з високою затримкою (називається "довга жирна труба"). Отже, якщо ви переносите великий файл, вам потрібно мати достатньо велике вікно прийому, щоб заповнити трубу, не чекаючи оновлень вікна. Я детально розказав, як обчислити це у своїй відповіді Налаштування слона .

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

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

BGP Peerings:
Крім того, якщо ви почнете вивчати 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

Це також цікаво досліджувати їх як пірінг з інструментом gui, як linkrank , він дає вам уявлення про Інтернет навколо вас.


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

4
Для допитливих фактична математика: 3000 ми / с = 16,1 мс
tylerl

15
У вакуумі фотон може подорожувати екватором приблизно за 134 мс. Цей же фотон у склі зайняв би близько 200 мс. Шматочок волокна на 3000 миль має 24 мс. затримки без будь-яких пристроїв.
dbasnett


42

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

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

затримка мережі мережами світових пар

Ось мої таймінги (я в Лондоні, Англія, тому час мого Західного узбережжя вище, ніж Східний). Я отримую різницю затримки в 74 мс, яка, здається, підтримує цінність цього сайту.

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

Вони були виміряні за допомогою інструментів розробки Google Chrome.


2
класна діаграма! NY до SF зараз 71 msна цьому, тому ви маєте рацію - ми не можемо розраховувати, що зробимо краще.
Джефф Етвуд

Дякую. Це мені дуже допомогло. Це ще одне джерело для пошуку затримок у мережі між різними місцями світу - dotcom-monitor.com/WebTools/network_latency.aspx
Sajib Mahmood

10

Спочатку поміркуйте за допомогою ICMP, якщо це можливо. Як правило, протоколи ICMP зазвичай використовують дуже невелику корисну навантаження, не використовують тристоронній рукостискання та не повинні взаємодіяти з іншим додатком у стеку, як це робить HTTP. У будь-якому випадку, надзвичайно важливо, щоб результати HTTP не змішувалися з результатами ICMP. Це яблука та апельсини.

Переходячи до відповіді Річ Адамса та користуючись сайтом, який він рекомендував, ви можете побачити, що на магістралі AT&T для переміщення між їх кінцевими точками SF та NY потрібно 72 мс. Це досить велика кількість, але ви повинні мати на увазі, що це в мережі, яка повністю контролюється AT&T. Він не враховує перехід до вашої домашньої або офісної мережі.

Якщо ви робите пінг із careers.stackoverflow.com зі своєї вихідної мережі, вам слід побачити щось не надто далеко за 72 мс (можливо, +/- 20 мс). Якщо це так, то, ймовірно, ви можете припустити, що мережевий шлях між вами двома в порядку і проходить у звичайних діапазонах. Якщо ні, не впадайте в паніку і міряйтеся з кількох інших місць. Це може бути ваш провайдер.

Припустимо, що це пройшло, наступним кроком є ​​вирішення рівня додатків та визначення того, чи є щось не так із додатковими накладними витратами, які ви бачите зі своїми HTTP-запитами. Це може відрізнятися від додатка до додатка через апаратне забезпечення, ОС та стек додатків, але оскільки у вас є приблизно однакове обладнання як на Східному, так і на Західному узбережжі, ви могли б користувачі Східного узбережжя потрапляти на сервери Західного узбережжя, а користувачі Західного узбережжя потрапляють на Схід узбережжя. Якщо обидва сайти налаштовані належним чином, я б розраховував, що всі цифри будуть менш рівними, і тому я продемонструю, що те, що ви бачите, в значній мірі відповідає рівним.

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

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


7

Деякі відповіді тут використовують ping та traceroute для своїх пояснень. Ці інструменти мають своє місце, але вони не є надійними для вимірювання продуктивності мережі.

Зокрема, (принаймні деякі) маршрутизатори ялівцю направляють обробку подій ICMP в площину управління маршрутизатора. Це набагато повільніше, ніж площина пересилання, особливо в магістральному маршрутизаторі.

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

Як результат, 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/ для отримання великої кількості інформації про вимірювання мережі. (відмова, я працював для Internet2). Також дивіться: https://fasterdata.es.net/

Щоб додати деяку специфічну відповідність оригінальному питанню ... Як ви бачите, у мене було 83 мс для пінг-порту до Стенфорда, тому ми знаємо, що мережа може пройти принаймні так швидко.

Зауважте, що шлях до дослідницької та освітньої мережі, який я взяв на цю послідовність, швидше за все, буде швидшим, ніж товарний Інтернет. Мережі науково-дослідних робіт в основному надмірно забезпечують свої з'єднання, що робить буферизацію кожного маршрутизатора малоймовірною. Також відзначте довгий фізичний шлях, довший, ніж узбережжя до узбережжя, хоча чітко відображає реальний рух.

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


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 на свій розміщений сервер, щоб виконати їх


1
вірно, очікується, що центр обробки даних східного узбережжя буде більш прихильним до нашої європейської аудиторії - ви бачите приблизно 200 мс часу, необхідного для подолання ширини США. Чи має бути лише ~ 80 мс за іншими відповідями?
Джефф Етвуд

схоже, що це відповідає приблизно 200 мс, я натиснув оновлення приблизно 20-30 разів зараз на обох (не одночасно, хоча), і сервер за замовчуванням виглядає так, що він зависає приблизно на 200 мс +/- більше, ніж на іншому . Я спробував traceroute, але він містить зірки на всьому, тому, можливо, наші ІТ-адміністратори щось заблокували.
Lasse Vågsæther Karlsen

2

Я бачу приблизно 80-90 мс затримки на добре прокладених, добре виміряних зв’язках між Східним та Західним берегами.

Було б цікаво побачити, де ви набираєте затримку - спробуйте такий інструмент, як траєкторія шару чотири (lft). Швидше за все, це багато що отримується на "останній милі" (тобто у вашого місцевого широкосмугового провайдера).

На те, що час передачі було незначно вплинуло, слід очікувати - втрата пакету та тремтіння є більш корисними вимірюваннями, які слід розглядати при дослідженні різниць часу перенесення між двома локаціями.


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.

І все це зводиться до того, що тут немає реальної точної відповіді, тому що існує стільки змінної, що будь-яка відповідь завжди може бути доведена неправильною, просто змінивши одну зі ста змінних.

Як і затримка 72ms NY до SF - це затримка від PoP до PoP носія пакету. Це не враховує жодних інших чудових моментів, які деякі вказували тут щодо перевантаженості, втрати пакетів, якості обслуговування, пакетів, що не вийшли з ладу, чи розміру пакету, або перенаправлення мережі просто між ідеальним світом PoP до PoP .

І тоді, коли ви додасте в останню милю (як правило, багато миль) від PoP до вашого фактичного місця розташування в двох містах, де всі ці змінні стають набагато більш текучими, річ починає експоненціально зростати з розумних здогадок!

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

Одночасно я контролював кількість постачальників схем в Інтернеті.

Результатами були затримки від 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.