VPS w Nowym Jorku: czy warto wybrać tę lokalizację?

Co faktycznie zapewnia VPS w Nowym Jorku

Serwer VPS zlokalizowany w Nowym Jorku znajduje się w jednym z dwóch głównych węzłów wymiany ruchu na wschodnim wybrzeżu Stanów Zjednoczonych. Drugim takim węzłem jest Ashburn w stanie Wirginia. Zakup takiej usługi zapewnia krótki czas odpowiedzi (round trip) dla użytkowników przebywających między Bostonem a Waszyngtonem oraz najkrótszą trasę światłowodową z Ameryki Północnej do Europy. Jeśli użytkownicy są równomiernie rozproszeni po całym kontynencie, zazwyczaj lepszym rozwiązaniem jest lokalizacja centralna. Rozróżnienie tych dwóch przypadków powinno opierać się na pomiarach, a nie na przypuszczeniach.

Dlaczego hosting VPS w Nowym Jorku to w większości hosting w New Jersey

Manhattan mieści tzw. carrier hotels. Najsłynniejszym z nich jest 60 Hudson Street: budynek w stylu art déco w Tribeca, ukończony w 1930 roku, w którym znajduje się ponad 300 operatorów i dostawców chmurowych oraz punkty wymiany ruchu obsługujące region, w tym DE-CIX New York i NYIIX. 32 Avenue of the Americas pełni tę samą funkcję kilka przecznic dalej, a 165 Halsey Street w Newark jest odpowiednikiem po stronie New Jersey.

W tych budynkach spotykają się sieci. Nie jest to jednak miejsce, w którym znajduje się duża moc obliczeniowa, ponieważ energia elektryczna i powierzchnia na Manhattanie są drogie i trudne do rozbudowy. Wielkie hale serwerowe znajdują się po drugiej stronie rzeki Hudson, w Secaucus, Weehawken, Carteret, Piscataway i Newark. Dostawca sprzedający VPS z lokalizacją "New York" niemal zawsze oznacza szafę rackową w tym pierścieniu, w promieniu około 40 km od Midtown. Dodatkowe opóźnienie wynikające z przesyłu światłowodowego wynosi znacznie poniżej jednej milisekundy, więc obciążenie typu web nigdy tego nie odczuje. O konkretny budynek należy pytać tylko wtedy, gdy wymagane jest połączenie typu cross-connect z konkretną siecią.

Co przyciągnęło przepustowość do tej metropolii

Cztery czynniki, z których każdy wzmacnia pozostałe.

• Kable transatlantyckie kończą się tuż obok. Wall Township i Manasquan na wybrzeżu New Jersey to najbardziej obciążony klaster w kraju. Kabel Havfrue, sprzedawany jako AEC-2, biegnie z Wall do Blaabjerg w Danii, z odgałęzieniami do Irlandii i Norwegii. Seabras-1 łączy tę samą stację z Brazylią, a TGN Atlantic prowadzi do Europy. Apollo dociera do Manasquan z Bude w Anglii oraz Lannion we Francji. Kabel Grace Hopper należący do Google kończy się w Bellport na Long Island i od września 2022 roku przesyła ruch do Bude.
• Węzły wymiany ruchu opuściły Wall Street. Silnik dopasowujący NYSE działa w Mahwah, Nasdaq w Carteret, a Cboe w Secaucus. Traderzy nazywają te lokalizacje trójkątem kapitałowym. Firmy potrzebujące danych rynkowych w czasie liczonym w mikrosekundach muszą wynająć przestrzeń obok jednego z nich, a ten popyt sfinansował światłowody, z których korzystamy obecnie wszyscy.
• Media i reklama są tutaj. Aukcja w modelu real-time bidding musi zwrócić odpowiedź, zanim strona zakończy ładowanie, dlatego giełdy reklamowe powstały obok sieci agencji, którym sprzedają swoje usługi.
• Sieci podążają tam, gdzie już są inne sieci. Gdy kilkuset operatorów współdzieli jeden budynek, kolejny zyskuje tańszy tranzyt i lepszy peering, dołączając do nich, zamiast budować infrastrukturę w innym miejscu.

Dla nabywcy VPS nie chodzi o prestiż. Oznacza to konkurencyjny tranzyt, gęsty peering oraz krótką ścieżkę do Europy, ponieważ połączenie zaczyna się tam, gdzie kończą się kable.

Rzeczywisty koszt pełnego cyklu komunikacji

Światło w szkle porusza się z prędkością około 200 000 km na sekundę, co stanowi w przybliżeniu dwie trzecie jego prędkości w próżni. Daje to 1 ms czasu pełnego cyklu (round-trip time) na każde 100 km światłowodu, zanim jakikolwiek router przetworzy pakiet. Rzeczywiste trasy są dłuższe niż odległości na mapie, ponieważ światłowody biegną wzdłuż korytarzy przesyłowych i tras podmorskich, a nie w liniach prostych.

Koszt nie ogranicza się do jednego pełnego cyklu. Zależy on od liczby cykli wymaganych przez dany protokół. Nowe połączenie HTTPS zużywa jeden cykl na nawiązanie połączenia TCP (transmission control protocol), kolejny na uzgodnienie TLS (transport layer security) 1.3 oraz jeszcze jeden na wysłanie żądania i odebranie pierwszych bajtów danych. To łącznie trzy pełne cykle, zanim przeglądarka otrzyma jakikolwiek kod HTML. Protokół TLS 1.2 dodaje czwarty cykl.

[
  {
    "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
  }
]

Powyższe kolumny przedstawiają obliczenia, a nie pomiary: pierwszy bajt wymaga trzech pełnych cykli, a kolumna łańcucha odnosi się do strony, która wywołuje sześć zależnych od siebie zapytań API jedno po drugim. W obrębie aglomeracji przy 5 ms czas konfiguracji połączenia jest niezauważalny. Przy połączeniu transatlantyckim o wartości 78 ms ta sama strona oczekuje 234 ms na pierwszy bajt HTML, a łańcuch sześciu wywołań spędza 468 ms wyłącznie na oczekiwaniu. Na trasie z Nowego Jorku do Singapuru przy 230 ms, ten sam łańcuch kosztuje 1380 ms.

Przeanalizuj kolumnę łańcucha przed podjęciem decyzji o przeniesieniu serwera. Ponowne wykorzystanie połączeń i wznawianie sesji TLS eliminują cykle, za które płacono wielokrotnie. Przekształcenie sześciu zależnych wywołań w dwa równoległe oszczędza więcej czasu niż fizyczne zbliżenie serwera o kontynent. Przenieś serwer dopiero wtedy, gdy liczba cykli jest nie do zredukowania: na przykład w przypadku logowania lub zapisu do bazy danych, których klient nie może przetworzyć w trybie wsadowym.

Typowe czasy podróży w obie strony z VPS w obszarze metropolitalnym Nowego Jorku

[
  {
    "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
  }
]

Należy traktować te dane jako typowe wartości publikowane, a nie pomiary z konkretnej maszyny. Jest to zakres powszechnie podawany dla dobrze połączonych hostów w standardowym tranzycie, a rzeczywista ścieżka może różnić się od tych wartości. Ashburn znajduje się w odległości około 8 ms, co jest wartością wystarczająco małą, aby VPS w Nowym Jorku mógł wywoływać usługi w klastrze w Wirginii bez odczuwalnej straty wydajności. Toronto znajduje się w odległości około 14 ms. Londyn znajduje się w pobliżu 78 ms, a Frankfurt w pobliżu 88 ms. Z tego powodu serwer na wschodnim wybrzeżu może obsługiwać użytkowników z Europy w akceptowalny sposób, podczas gdy serwer na zachodnim wybrzeżu nie jest w stanie tego zapewnić.

Kiedy wybór lokalizacji na Wschodnim Wybrzeżu jest uzasadniony

• Większość użytkowników znajduje się w korytarzu od Bostonu do Waszyngtonu. Ten obszar generuje znaczną część ruchu internetowego w Stanach Zjednoczonych, a wszystkie punkty znajdują się zaledwie kilka milisekund od metropolii.
• Obsługujesz wschodnie wybrzeże Stanów Zjednoczonych oraz Europę z jednej maszyny. Nowy Jork stanowi najtańszy kompromis, ponieważ połączenia transatlantyckie zaczynają się właśnie tam.
• Polegasz na zasobach już obecnych w metropolii: strumieniu danych rynkowych, giełdzie reklamowej lub API partnera w Secaucus bądź Ashburn.
• Potrzebujesz krótkiego połączenia z Kanadą bez konieczności hostowania tam usług. Opóźnienie do Toronto wynosi około 14 ms. Jeśli wymóg przechowywania danych w Kanadzie jest bezwzględny, decyzja wygląda inaczej, a artykuł co faktycznie ma znaczenie przy wyborze kanadyjskiego hostingu VPS szczegółowo to wyjaśnia.

Kiedy centralna lokalizacja w USA przewyższa Wschodnie Wybrzeże

Projektuj z myślą o najgorszym przypadku, a nie o średniej. Użytkownik na odległym wybrzeżu odczuje opóźnienie. Użytkownik w sąsiednim stanie nie.

[
  {
    "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
  }
]

Serwer w Nowym Jorku znajduje się w odległości 70 ms od Los Angeles. Serwer w Dallas jest oddalony o 38 ms od Nowego Jorku i 35 ms od Los Angeles, więc jego najgorszy przypadek opóźnienia w skali kraju stanowi mniej więcej połowę wyniku dla Nowego Jorku. Gdy mapa ruchu obejmuje faktycznie cały kraj, jest to korzystniejsza pozycja, a argumenty za umieszczeniem VPS w Dallas szczegółowo omawiają ten rynek. Chicago to drugie rozsądne centralne rozwiązanie, które jednak skłania się ku wschodowi.

Dwie kolejne sytuacje przemawiają przeciwko Nowemu Jorkowi. Jeśli użytkownicy są skoncentrowani w Ontario lub Quebecu, VPS w Toronto obsłuży ich bezpośrednio, zamiast dodawać przeskok o wartości 14 ms z Nowego Jorku. Jeśli natomiast niemal cały ruch odbywa się między własnymi serwerami, należy utrzymać je w jednym regionie i przestać brać pod uwagę geografię, ponieważ przeskok międzyregionalny zniweluje wszelkie zyski wynikające z lokalizacji blisko użytkowników.

Mierz, nie ufaj mapom marketingowym

Mapa zasięgu wskazuje lokalizację budynku. Nie informuje jednak, w jaki sposób pakiety docierają do tego budynku, a ścieżka ta zależy od umów tranzytowych i porozumień peeringowych, a nie od odległości. Dlatego należy dokonywać pomiarów z miejsca, w którym znajdują się użytkownicy. Laptop w domowej sieci szerokopasmowej jest lepszą sondą niż sam VPS, który znajduje się po „dobrej” stronie sieci.

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

Zacznij od zwykłego pomiaru czasu obiegu (round trip) i wyślij dwadzieścia sond zamiast czterech. Zastąp nazwę hosta adresem własnego serwera.

ping -c 20 your-server.example.com

Ostatni wiersz raportuje rtt min/avg/max/mdev. Średnia jest tam najmniej użyteczną wartością. mdev to jitter; wysoki jitter przerywa połączenia głosowe i sesje interaktywne, nawet jeśli średnia wygląda poprawnie. Na ścieżce przewodowej każda utrata pakietów powyżej zera jest usterką, a nie szumem.

Następnie sprawdź, gdzie tracony jest czas.

mtr -rwzbc 100 your-server.example.com

mtr wysyła 100 sond do każdego przeskoku (hop) i drukuje utratę oraz opóźnienie dla każdego z nich, a -z dodaje numer AS (autonomous system), dzięki czemu widać, która sieć jest właścicielem danego przeskoku. Utrata zgłoszona na środkowym przeskoku, która znika na kolejnych, nie jest rzeczywista: router ogranicza szybkość odpowiedzi ICMP, które musi wygenerować samodzielnie, co nie wpływa na Twój ruch. Utrata, która zaczyna się na jednym przeskoku i utrzymuje się na wszystkich kolejnych, jest rzeczywista.

ICMP jest również niewłaściwym protokołem do oceny usług internetowych, ponieważ wiele sieci nadaje mu niski priorytet. Mierz czas usługi, którą faktycznie udostępniasz.

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/

Każda wartość jest skumulowaną liczbą sekund od początku, więc aby ją odczytać, należy wykonać odejmowanie. time_connect minus time_namelookup to jeden pełny obieg. time_appconnect minus time_connect to uzgadnianie TLS. time_starttransfer minus time_appconnect to kolejny obieg plus czas, jakiego aplikacja potrzebowała na odpowiedź. To ostatnie odejmowanie jest diagnozą. Jeśli wynik jest zbliżony do jednego obiegu, ograniczeniem jest sieć i pomoże przeniesienie serwera bliżej. Jeśli wynik jest wielokrotnością czasu obiegu, aplikacja działa wolno i jej przeniesienie nic nie zmieni.

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'

Przed podjęciem decyzji wykonaj ten sam test na instancji próbnej w każdej z rozważanych lokalizacji. Pełna metoda benchmarkingu VPS obejmuje testy dysku i procesora obok sieci, dzięki czemu wybór nie opiera się wyłącznie na opóźnieniach.

Co jeszcze zmienia się wraz z adresem w Nowym Jorku

Cena jest pierwszą kwestią. Koszty energii i powierzchni w obszarze metropolitalnym Nowego Jorku są wyższe niż w Teksasie czy na Środkowym Zachodzie. Niektórzy dostawcy przenoszą te koszty na klienta w formie dodatkowej opłaty za lokalizację, podczas gdy inni uśredniają je dla całej infrastruktury. Według stanu na sierpień 2026 roku nie istnieje jedna zasada, dlatego przed założeniem istnienia kary należy wycenić tę samą specyfikację w dwóch lokalizacjach na stronie zamówienia dostawcy. Ile faktycznie kosztuje VPS miesięcznie omawia pozostałe składniki rachunku.

Prawo nie podąża za serwerem. Nowojorska ustawa SHIELD Act nakłada obowiązki powiadamiania o naruszeniach oraz stosowania uzasadnionych zabezpieczeń na każdego, kto przechowuje prywatne informacje o mieszkańcu Nowego Jorku, niezależnie od tego, gdzie te dane się znajdują. Przeniesienie serwera do Dallas nie znosi tego obowiązku, a przeniesienie go na Manhattan go nie tworzy. To samo dotyczy RODO (ogólnego rozporządzenia o ochronie danych) w odniesieniu do użytkowników europejskich. Lokalizacja ma znaczenie, gdy umowa lub przepisy sektorowe wskazują konkretny kraj, co jest częste w opiece zdrowotnej oraz niektórych usługach finansowych.

Kwestie zasilania i ryzyka powodziowego wymagają osobnego omówienia. Gdy huragan Sandy uderzył w październiku 2012 roku, kilka budynków operatorskich na Dolnym Manhattanie straciło łączność, ponieważ pompy paliwowe w piwnicach zostały zalane, a generatory na wyższych piętrach wyczerpały zapasy paliwa. Pojedyncza lokalizacja w dowolnej metropolii stanowi pojedynczy punkt awarii. Kopie zapasowe należy przechowywać w innej sieci energetycznej, a procedurę odtwarzania należy przynajmniej raz przetestować w innej lokalizacji, aby mieć pewność, że przywracanie danych działa.

FAQ

Czy VPS w Nowym Jorku jest szybszy dla użytkowników z Europy niż serwer w centrum USA?

Tak, i to o przewidywalną wartość. Londyn znajduje się w odległości około 78 ms od obszaru metropolitalnego Nowego Jorku, ponieważ transatlantyckie kable światłowodowe wychodzą na ląd na wybrzeżu New Jersey oraz na Long Island. Serwer w Dallas łączy się z Londynem, najpierw przesyłając dane na wschodnie wybrzeże, co dodaje około 38 ms opóźnienia wynikającego z trasy Dallas – Nowy Jork. Jeśli jedna maszyna musi obsługiwać zarówno wschodnie wybrzeże Stanów Zjednoczonych, jak i Europę, Nowy Jork jest kompromisem generującym najniższe koszty opóźnień.

Dlaczego mój VPS "w Nowym Jorku" znajduje się w rzeczywistości w New Jersey?

Ponieważ to tam znajduje się odpowiednia powierzchnia techniczna i zasilanie. Budynki na Manhattanie, takie jak 60 Hudson Street, pełnią funkcję węzłów wymiany ruchu, a nie dużych hal obliczeniowych, dlatego szafy serwerowe znajdują się w Secaucus, Weehawken, Carteret, Piscataway lub Newark. Dodatkowe włókna światłowodowe zwiększają opóźnienie o znacznie mniej niż jedną milisekundę, co jest niezauważalne dla jakiegokolwiek obciążenia webowego. O dokładną lokalizację obiektu należy pytać tylko wtedy, gdy wymagane jest fizyczne połączenie (cross-connect) z konkretną siecią wewnątrz danego budynku.

Skąd mam wiedzieć, czy opóźnienie sieciowe rzeczywiście stanowi problem?

Należy wykonać analizę czasową curl i przeprowadzić odejmowanie. Różnica między time_appconnect a time_starttransfer to czas jednego pełnego cyklu sieciowego (round trip) powiększony o czas przetwarzania przez serwer. Jeśli ta różnica jest znacznie większa niż czas cyklu zmierzony za pomocą ping, opóźnienie wynika z działania aplikacji i zmiana centrum danych na bliższe nie rozwiąże problemu. Jeśli różnica jest zbliżona do czasu jednego cyklu, a strona nadal działa wolno, należy policzyć, ile żądań sekwencyjnych wykonuje strona, ponieważ każde z nich ponownie generuje pełny czas cyklu.

Czy hosting w Nowym Jorku zmienia przepisy dotyczące prywatności, którym podlegam?

Zasadniczo nie. Przepisy takie jak New York SHIELD Act czy RODO odnoszą się do tego, czyje dane są przetwarzane, a nie do tego, gdzie fizycznie znajdują się dyski. Lokalizacja serwera staje się czynnikiem decydującym, gdy umowa lub regulacje sektorowe wskazują konkretny kraj, co często zdarza się w sektorze opieki zdrowotnej oraz w niektórych obszarach usług finansowych. Przed wyborem lokalizacji w celu spełnienia wymogów prawnych należy zapoznać się z treścią konkretnych przepisów.

Czy CDN może zastąpić dobrze zlokalizowany serwer VPS?

W przypadku plików statycznych – tak. CDN (content delivery network) buforuje obrazy i skrypty w pobliżu użytkowników, eliminując większość dystansu dla tych żądań. CDN nie może jednak buforować spersonalizowanego panelu użytkownika ani operacji zapisu do bazy danych, dlatego te żądania nadal muszą dotrzeć do serwera źródłowego (origin), co wiąże się z pełnym czasem cyklu sieciowego. Serwer źródłowy należy umieścić w pobliżu użytkowników, którzy zapisują dane, a obsługę pozostałego ruchu powierzyć sieci CDN.