VPS у Нью-Йорку: що справді має значення

Що насправді дає VPS у Нью-Йорку

VPS у Нью-Йорку розміщується на одному з двох великих майданчиків взаємоз’єднання на східному узбережжі США. Інший розташований в Ашберні, штат Вірджинія. Ви отримуєте малий час проходження мережевого пакета в обидва боки для користувачів між Бостоном і Вашингтоном, а також найкоротший оптоволоконний маршрут із Північної Америки до Європи. Якщо користувачі рівномірно розподілені по континенту, центральне розташування зазвичай забезпечує кращу доступність. Визначити, який із цих двох випадків стосується вашої інфраструктури, можна лише вимірюваннями, а не припущеннями.

Чому VPS-хостинг у Нью-Йорку здебільшого означає хостинг у Нью-Джерсі

У Манхеттені розташовані carrier hotels. Найвідоміший із них — 60 Hudson Street: будівля в стилі ар-деко в Трайбеці, завершена у 1930 році. У ній розміщено понад 300 операторів зв’язку та cloud-провайдерів, а також точки обміну трафіком, що обслуговують регіон, зокрема DE-CIX New York і NYIIX. 32 Avenue of the Americas виконує таку саму функцію за кілька кварталів звідси, а 165 Halsey Street у Newark є аналогічним об’єктом із боку Нью-Джерсі.

Саме в цих будівлях мережі підключаються одна до одної. Великі обсяги обчислювальних ресурсів розміщують не там, оскільки електроенергія та площа в Манхеттені дорогі, а розширення складне. Великі машинні зали розташовані за Hudson у Secaucus, Weehawken, Carteret, Piscataway і Newark. Провайдер, який продає VPS у «Нью-Йорку», майже завжди має на увазі стійку десь у цьому кільці, приблизно в межах 40 км від Midtown. Додаткова затримка через оптичний маршрут значно менша за мілісекунду, тому вебнавантаження її не помітить. Уточнюйте конкретну будівлю лише тоді, коли вам потрібне cross-connect-підключення до певної мережі.

Що сформувало пропускну здатність цього регіону

Чотири чинники, і кожен посилює інші.

• Трансатлантичні кабелі виходять на берег поруч. Wall Township і Manasquan на узбережжі New Jersey утворюють найзавантаженіший кластер у країні. Havfrue, що продається під назвою AEC-2, пролягає від Wall до Blaabjerg у Denmark, із відгалуженнями до Ireland і Norway. Seabras-1 пролягає від тієї самої станції до Brazil, а TGN Atlantic перетинає Atlantic Ocean до Europe. Apollo виходить на берег у Manasquan після прокладання від Bude в England і Lannion у France. Кабель Google Grace Hopper виходить на берег у Bellport на Long Island і передає трафік до Bude із September 2022.
• Біржі залишили Wall Street. Matching engine NYSE працює в Mahwah, Nasdaq — у Carteret, а Cboe — у Secaucus. Трейдери називають ці майданчики equity triangle. Компанії, яким потрібні ринкові дані із затримкою в межах мікросекунд, мають орендувати місце поруч з одним із них. Саме цей попит профінансував оптоволоконну інфраструктуру, якою тепер користуємося всі.
• Тут розташовані медіа та рекламні компанії. Аукціон real-time bidding має повернути відповідь до завершення завантаження сторінки. Тому рекламні біржі будувалися поруч із агентськими мережами, яким вони продають свої послуги.
• Мережі розміщуються там, де вже є інші мережі. Коли в одній будівлі працюють кілька сотень операторів, наступному оператору вигідніше приєднатися до них. Так він отримує дешевший transit і кращий peering, ніж у разі будівництва майданчика в іншому місці.

Для покупця VPS усе це не питання престижу. Це означає конкурентний transit, щільний peering і короткий маршрут до Europe, оскільки він починається там, де виходять на берег кабелі.

Скільки насправді коштує round trip

Світло у волокні поширюється зі швидкістю приблизно 200,000 км за секунду, тобто близько двох третин швидкості у вакуумі. Це 1 ms round-trip time на кожні 100 км волокна, ще до того, як пакет потрапить до будь-якого маршрутизатора. Реальні маршрути довші за відстань на карті, оскільки волокно прокладають уздовж смуг відведення та маршрутів на морському дні, а не по прямій.

Враховується не один round trip. Враховується кількість round trip, потрібних протоколу. Нове HTTPS-з’єднання витрачає один round trip на TCP (transmission control protocol) handshake, ще один — на TLS (transport layer security) 1.3 handshake і ще один — на надсилання запиту та отримання перших байтів у відповіді. Отже, браузер отримує будь-який HTML лише після трьох round trip. TLS 1.2 додає четвертий.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

У цих стовпцях наведено розрахунки, а не результати вимірювань: first byte — це три round trip, а стовпець chain показує сторінку, яка послідовно виконує шість залежних API-викликів. У межах міської мережі за 5 ms налаштування з’єднання непомітне. Через Atlantic за 78 ms та сама сторінка очікує 234 ms до отримання першого байта HTML, а ланцюжок із шести викликів витрачає 468 ms лише на очікування. Від New York до Singapore за 230 ms цей ланцюжок коштує 1380 ms.

Перш ніж переносити сервер, перегляньте стовпець chain. Повторне використання з’єднання та TLS session resumption усувають round trip, за які ви щоразу платили знову. Перетворення шести залежних викликів на два паралельні заощаджує більше часу, ніж перенесення сервера ближче на цілий континент. Переносьте сервер, коли round trip неможливо усунути: наприклад, під час login або database write, який клієнт не може об’єднати в один пакет.

Типові значення round trip time для VPS у нью-йоркській агломерації

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

Вважайте ці значення типовими опублікованими показниками, а не вимірюваннями з конкретної машини. Це діапазон, який зазвичай наводять для добре підключених хостів зі звичайним транзитом, а ваш власний маршрут може мати як меншу, так і більшу затримку. До Ashburn приблизно 8 мс — це достатньо близько, щоб VPS у Нью-Йорку міг звертатися до сервісів у кластері у Virginia без помітних втрат. До Toronto приблизно 14 мс. До London близько 78 мс, а до Frankfurt — близько 88 мс. Тому один сервер на східному узбережжі може прийнятно обслуговувати користувачів у Європі, тоді як сервер на західному узбережжі — ні.

Коли розміщення на Східному узбережжі є правильним вибором

• Більшість ваших користувачів перебуває в коридорі між Бостоном і Вашингтоном. У цьому регіоні зосереджена значна частка інтернет-трафіку Сполучених Штатів, і всі ці користувачі знаходяться за кілька мілісекунд від агломерації.
• Ви обслуговуєте східну частину Сполучених Штатів і Європу з однієї машини. Нью-Йорк є найдешевшим компромісом, оскільки трансатлантична ділянка маршруту починається саме тут.
• Ви залежите від сервісу, який уже працює в агломерації: каналу ринкових даних, рекламної біржі або партнерського API у Секакусі чи Ашберні.
• Вам потрібен короткий маршрут до Канади без розміщення сервера там. До Торонто приблизно 14 мс. Якщо резидентність даних у Канаді є обов’язковою вимогою, це вже інше рішення, і що насправді важливо під час вибору канадського VPS-хостингу допоможе його прийняти.

Коли центральне розташування в США краще за східне узбережжя

Проєктуйте систему для найгіршого випадку, а не для середнього показника. Користувач на віддаленому узбережжі відчуває затримку. Користувач у сусідньому штаті — ні.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

Сервер у New York розташований за 70 мс від Los Angeles. Сервер у Dallas розташований за 38 мс від New York і за 35 мс від Los Angeles, тому його найгірший показник для з’єднань через усю країну приблизно вдвічі кращий, ніж у New York. Якщо карта вашого трафіку справді охоплює всю країну, це сильніша позиція, а аргументи на користь розміщення VPS у Dallas детально розглядають переваги цього регіону. Chicago — ще один доцільний центральний варіант, але він більше орієнтований на схід.

Є ще дві ситуації, коли варто обрати не New York. Якщо ваші користувачі зосереджені в Ontario або Quebec, VPS у Toronto обслуговує їх безпосередньо, не додаючи 14 мс переходу через New York. Якщо ж майже весь ваш трафік проходить між власними серверами, розмістіть їх в одному регіоні й не зважайте на географію, оскільки перехід між регіонами нівелює будь-який виграш від розташування ближче до користувачів.

Вимірюйте, а не покладайтеся на маркетингову карту

Карта покриття показує, де розташована будівля. Вона не показує, яким маршрутом пакети дістаються до цієї будівлі. Цей маршрут визначають транзитні контракти та угоди про піринг, а не відстань. Тому вимірюйте з мережі, де перебувають ваші користувачі. Ноутбук із домашнім broadband — кращий probe, ніж сам VPS, який розташований у сприятливій частині мережі.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

Почніть зі звичайного round trip і надішліть двадцять probe замість чотирьох. Замініть hostname на адресу власного сервера.

ping -c 20 your-server.example.com

В останньому рядку наведено rtt min/avg/max/mdev. Середнє значення тут найменш корисне. mdev — це jitter. Високий jitter порушує роботу голосових та інтерактивних сесій, навіть якщо середнє значення виглядає нормальним. У дротовому маршруті будь-яка втрата пакетів понад нуль означає несправність, а не шум.

Потім визначте, де саме витрачається час.

mtr -rwzbc 100 your-server.example.com

mtr надсилає 100 probe до кожного hop і виводить втрати та затримку для кожного hop. -z додатково показує номер AS (autonomous system), щоб можна було визначити, якій мережі належить кожен hop. Втрата, зафіксована на проміжному hop, але відсутня на наступних hop, не є реальною втратою. Цей маршрутизатор обмежує частоту ICMP-відповідей, які він генерує сам, і це не впливає на ваш трафік. Втрата, яка починається на одному hop і триває на всіх наступних hop, є реальною.

ICMP також не підходить для оцінювання web-сервісу, оскільки багато мереж надають цьому протоколу низький пріоритет. Вимірюйте час роботи саме того сервісу, який ви надаєте.

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

Кожне значення — це сукупний час у секундах від початку, тому для аналізу потрібно виконувати віднімання. time_connect мінус time_namelookup — це один round trip. time_appconnect мінус time_connect — це TLS handshake. time_starttransfer мінус time_appconnect — це ще один round trip плюс час, який вашому застосунку знадобився для відповіді. Саме останнє віднімання дає змогу визначити причину. Якщо результат близький до одного round trip, обмеженням є мережа, і ближчий сервер допоможе. Якщо результат у кілька разів перевищує round trip, ваш застосунок працює повільно, і його перенесення нічого не змінить.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

Виконайте той самий тест для trial instance у кожній потенційній локації, перш ніж остаточно обрати одну з них. Повний метод тестування VPS також охоплює диск і CPU разом із мережею, тому ви не обиратимете сервер лише за показником затримки.

Що ще змінюється у разі адреси в New York

Ціна — це перша зміна. Електроенергія та площа в дата-центрах агломерації New York коштують дорожче, ніж у Texas або на Середньому Заході. Деякі провайдери перекладають ці витрати в окрему доплату за локацію, а інші усереднюють їх по всій інфраструктурі. Станом на August 2026 єдиного правила немає. Перш ніж припускати наявність такої доплати, порівняйте однакову конфігурацію для двох локацій на сторінці замовлення самого провайдера. У матеріалі Скільки насправді коштує VPS на місяць розглянуто решту витрат.

Законодавчі вимоги не залежать від розташування сервера. Закон New York SHIELD Act встановлює обов’язки щодо повідомлення про витік даних і застосування належних заходів захисту для всіх, хто зберігає приватну інформацію про жителя New York, незалежно від місця зберігання цих даних. Перенесення сервера до Dallas не скасовує цей обов’язок, а перенесення до Manhattan не створює його. Те саме стосується GDPR (general data protection regulation) і ваших користувачів з Європи. Розташування має значення, якщо країну прямо зазначено в договорі або галузевих вимогах. Це поширено у сфері охорони здоров’я та в деяких фінансових сервісах.

Ризики, пов’язані з електроживленням і повенями, заслуговують на окремий абзац. Коли Hurricane Sandy обрушився на регіон у October 2012, кілька телекомунікаційних будівель у Lower Manhattan втратили зв’язок, оскільки паливні насоси в підвалах затопило, а генератори нагорі залишилися без пального. Один майданчик у будь-якій агломерації є єдиною точкою відмови. Зберігайте резервні копії в іншій електромережі та хоча б один раз відновіть їх в іншому місці, щоб перевірити працездатність відновлення.

FAQ

Чи швидший New York VPS для користувачів у Європі, ніж VPS у центральній частині США?

Так, і різниця передбачувана. Від Лондона до агломерації New York приблизно 78 мс, оскільки трансатлантичні кабелі виходять на берег на узбережжі New Jersey та на Long Island. Сервер у Dallas спочатку передає трафік до східного узбережжя, тому додатково має приблизно 38 мс на ділянці між Dallas і New York. Якщо одна машина має обслуговувати і східну частину США, і Європу, New York є компромісом із найменшою затримкою.

Чому мій VPS у «New York» насправді розміщений у New Jersey?

Тому що саме там доступні площі та електроживлення. Будівлі Manhattan, зокрема 60 Hudson Street, є вузлами взаємоз’єднання, а не великими обчислювальними майданчиками, тому стійки розміщують у Secaucus, Weehawken, Carteret, Piscataway або Newark. Додаткова оптоволоконна ділянка додає значно менше 1 мс, і жоден вебзастосунок цього не помітить. Уточнюйте точний майданчик лише тоді, коли вам потрібне пряме з’єднання з певною мережею в конкретній будівлі.

Як визначити, чи справді проблема пов’язана із затримкою?

Запустіть розклад розрахунку часу curl і виконайте віднімання. Різниця між time_appconnect і time_starttransfer — це один мережевий обмін «запит-відповідь» плюс час обробки на самому сервері. Якщо ця різниця значно більша за час обміну, виміряний за допомогою ping, затримка виникає всередині вашого застосунку, і ближчий дата-центр її не усуне. Якщо різниця близька до часу одного обміну, але сторінка все одно працює повільно, порахуйте, скільки запитів сторінка виконує послідовно, оскільки кожен із них знову додає час обміну.

Чи змінює розміщення хостингу в New York те, які закони про приватність до мене застосовуються?

Переважно ні. Такі правила, як New York SHIELD Act і GDPR, залежать від того, чиї дані ви зберігаєте, а не від місця розташування диска. Розташування сервера стає визначальним, коли контракт або галузеве правило вимагає розміщення в певній країні. Так часто буває у сфері охорони здоров’я та в окремих сегментах фінансових послуг. Перш ніж обирати локацію для виконання вимоги, ознайомтеся з її точним формулюванням.

Чи може CDN замінити правильно розміщений VPS?

Для статичних файлів — так. CDN (мережа доставки вмісту) кешує зображення та скрипти поблизу ваших користувачів і усуває більшу частину відстані для таких запитів. CDN не може кешувати панель для авторизованих користувачів або операцію запису в базу даних, тому ці запити все одно проходять до вашого origin-сервера та сплачують повний час мережевого обміну. Розмістіть origin поблизу користувачів, які записують дані, а решту запитів передайте CDN.