VPS a New York: cosa conta davvero

Cosa offre realmente un VPS a New York

Un VPS a New York si trova in uno dei due principali mercati di interconnessione sulla costa orientale degli Stati Uniti. L’altro è Ashburn, in Virginia. Il vantaggio consiste in un breve tempo di andata e ritorno per gli utenti tra Boston e Washington, oltre che nel percorso in fibra più breve dal Nord America all’Europa. Se gli utenti sono distribuiti uniformemente sul continente, una posizione centrale offre in genere prestazioni migliori. Distinguere questi due casi richiede misurazioni, non supposizioni.

Perché l’hosting VPS di New York si trova soprattutto nel New Jersey

Manhattan ospita i carrier hotel, cioè i principali punti di interconnessione tra reti. Il più noto è 60 Hudson Street: un edificio Art Déco a Tribeca, completato nel 1930, che ospita oltre 300 carrier e provider cloud, oltre agli exchange che servono la regione, tra cui DE-CIX New York e NYIIX. 32 Avenue of the Americas svolge la stessa funzione a pochi isolati di distanza, mentre 165 Halsey Street a Newark è l’equivalente sul lato del New Jersey.

È in questi edifici che le reti si interconnettono. Non è invece il luogo in cui si concentra una grande quantità di capacità di calcolo, perché a Manhattan l’energia e gli spazi tecnici sono costosi e difficili da ampliare. I grandi data hall si trovano dall’altra parte dell’Hudson, a Secaucus, Weehawken, Carteret, Piscataway e Newark. Un provider che vende un VPS di “New York” indica quasi sempre un rack situato da qualche parte in questo anello, entro circa 40 km da Midtown. Il percorso aggiuntivo sulla fibra introduce un ritardo ben inferiore a un millisecondo, quindi un’applicazione web non lo rileva. Chiedete l’edificio preciso solo se vi serve un cross-connect verso una rete specifica.

Cosa ha portato la capacità in questa area metropolitana

Quattro fattori, ognuno dei quali rafforza gli altri.

• I cavi transatlantici approdano a poca distanza. Wall Township e Manasquan, sulla costa del New Jersey, formano il cluster più trafficato degli Stati Uniti. Havfrue, commercializzato come AEC-2, collega Wall a Blaabjerg, in Danimarca, con diramazioni verso Irlanda e Norvegia. Seabras-1 parte dalla stessa stazione e arriva in Brasile, mentre TGN Atlantic attraversa l'Atlantico fino all'Europa. Apollo approda a Manasquan dopo essere partito da Bude, in Inghilterra, e da Lannion, in Francia. Il cavo Grace Hopper di Google approda a Bellport, a Long Island, e trasporta traffico verso Bude dal settembre 2022.
• I punti di scambio hanno lasciato Wall Street. Il motore di matching di NYSE si trova a Mahwah, quello di Nasdaq a Carteret e quello di Cboe a Secaucus. I trader chiamano queste sedi il triangolo azionario. Le aziende che hanno bisogno dei dati di mercato con una latenza di pochi microsecondi devono acquistare spazio accanto a una di queste sedi, e questa domanda ha finanziato la fibra che oggi condividiamo tutti.
• Qui sono presenti media e pubblicità. Un'asta di real-time bidding deve restituire una risposta prima che la pagina termini il caricamento, quindi gli ad exchange sono stati costruiti accanto alle reti delle agenzie a cui vendono.
• Le reti si concentrano dove esistono già altre reti. Quando diverse centinaia di carrier condividono lo stesso edificio, per il successivo è più conveniente ottenere transit e peering migliori unendosi a loro che costruire altrove.

Per chi acquista una VPS, tutto questo non riguarda il prestigio. Significa che il transit è competitivo, il peering è capillare e il percorso verso l'Europa è breve, perché inizia nel punto in cui approdano i cavi.

Quanto costa davvero un round trip

La luce nella fibra viaggia a circa 200.000 km al secondo, cioè a circa due terzi della velocità che raggiunge nel vuoto. Questo equivale a 1 ms di round trip ogni 100 km di fibra, prima che un router elabori il pacchetto. I percorsi reali sono più lunghi della distanza sulla mappa, perché la fibra segue diritti di passaggio e rotte sottomarine, invece di procedere in linea retta.

Il costo non corrisponde a un solo round trip. Dipende dal numero di round trip richiesti dal protocollo. Una nuova connessione HTTPS utilizza un round trip per l'handshake TCP (transmission control protocol), un altro per l'handshake TLS (transport layer security) 1.3 e un altro ancora per inviare la richiesta e ricevere i primi byte. Prima che il browser visualizzi l'HTML servono quindi tre round trip. TLS 1.2 ne aggiunge un quarto.

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

Queste colonne sono calcoli, non misurazioni: first byte corrisponde a tre round trip, mentre la colonna chain rappresenta una pagina che esegue in sequenza sei chiamate API dipendenti. All'interno dell'area metropolitana, con 5 ms, il tempo di configurazione della connessione è trascurabile. Attraverso l'Atlantico, con 78 ms, la stessa pagina attende 234 ms prima di ricevere il primo byte dell'HTML, mentre la catena di sei chiamate trascorre 468 ms senza fare altro che attendere. Da New York a Singapore, con 230 ms, questa catena costa 1380 ms.

Leggi la colonna chain prima di spostare un server. Il riutilizzo della connessione e la ripresa della sessione TLS eliminano round trip che altrimenti pagheresti ripetutamente. Trasformare sei chiamate dipendenti in due chiamate parallele fa risparmiare più tempo che avvicinare il server di un continente. Sposta il server quando i round trip sono inevitabili: per esempio per un login o per una scrittura sul database che il client non può raggruppare.

Tempi tipici di andata e ritorno da un VPS nell’area metropolitana di New York

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

Considerali valori pubblicati tipici, non misurazioni effettuate da una macchina specifica. Rappresentano l’intervallo comunemente indicato per host ben connessi tramite normali reti di transito; il percorso effettivo può produrre valori superiori o inferiori. Ashburn dista circa 8 ms, una distanza abbastanza ridotta da consentire a un VPS di New York di raggiungere i servizi nel cluster della Virginia senza una penalizzazione significativa. Toronto si trova a circa 14 ms. Londra è a circa 78 ms e Francoforte a circa 88 ms. Per questo un server sulla costa orientale può servire gli utenti europei con prestazioni accettabili, mentre un server sulla costa occidentale non può farlo.

Quando la costa orientale è la scelta giusta

• La maggior parte degli utenti si trova nel corridoio tra Boston e Washington. Questa fascia concentra una quota significativa della domanda Internet degli Stati Uniti e tutti gli utenti sono a pochi millisecondi di distanza dall'area metropolitana.
• Servi gli Stati Uniti orientali e l'Europa da un'unica macchina. New York è il compromesso più economico, perché la tratta transatlantica inizia qui.
• Dipendi da un servizio già presente nell'area metropolitana: un feed di dati di mercato, un ad exchange o un'API di un partner a Secaucus o Ashburn.
• Vuoi un percorso breve verso il Canada senza ospitare il servizio in Canada. Toronto dista circa 14 ms. Se la residenza dei dati in Canada è un requisito vincolante, la decisione è diversa; cosa conta davvero nella scelta di un VPS canadese lo spiega.

Quando una posizione nel centro degli Stati Uniti è preferibile alla costa orientale

Progetta per il caso peggiore, non per la media. Un utente sulla costa opposta nota la latenza. Un utente nello Stato confinante no.

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

Un server a New York dista 70 ms da Los Angeles. Un server a Dallas dista 38 ms da New York e 35 ms da Los Angeles, quindi il suo caso peggiore attraverso il Paese è circa la metà di quello di New York. Quando la tua mappa del traffico è realmente nazionale, questa è la posizione più favorevole; la scelta di collocare un VPS a Dallas analizza in dettaglio i vantaggi di quella piazza. Chicago è l'altra posizione centrale sensata e offre un vantaggio maggiore verso est.

Altre due situazioni fanno propendere per una posizione diversa da New York. Se gli utenti sono concentrati in Ontario o Québec, un VPS a Toronto li serve direttamente, senza aggiungere il collegamento di 14 ms da New York. Se invece quasi tutto il traffico passa tra i tuoi server, mantienili nella stessa regione e non considerare la geografia: un collegamento tra regioni annullerà qualsiasi vantaggio ottenuto dalla vicinanza agli utenti.

Misurare, non fidarsi della mappa commerciale

Una mappa di copertura indica dove si trova un edificio. Non indica come arrivano i pacchetti a quell'edificio. Il percorso dipende dai contratti di transito e dagli accordi di peering, non dalla distanza. Misurare quindi dal punto in cui si trovano gli utenti. Un laptop collegato alla banda larga domestica è una sonda migliore dello stesso VPS, che si trova sul lato più favorevole della rete.

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

Iniziare con un semplice round trip e inviare venti probe invece di quattro. Sostituire l'hostname con quello del proprio server.

ping -c 20 your-server.example.com

L'ultima riga riporta rtt min/avg/max/mdev. La media è il valore meno utile. mdev è il jitter. Un jitter elevato compromette le comunicazioni vocali e le sessioni interattive anche quando la media sembra buona. Su un percorso cablato, qualsiasi perdita di pacchetti superiore a zero indica un problema, non rumore.

Individuare quindi dove viene impiegato il tempo.

mtr -rwzbc 100 your-server.example.com

mtr invia 100 probe a ogni hop e mostra la perdita e la latenza per ogni hop. -z aggiunge il numero AS (autonomous system), così è possibile vedere quale rete gestisce ogni hop. Una perdita segnalata da un hop intermedio, ma assente negli hop successivi, non è reale: quel router limita la frequenza delle risposte ICMP che deve generare localmente, senza alcun costo per il traffico. Una perdita che inizia a un hop e continua in tutti gli hop successivi è reale.

ICMP non è inoltre il protocollo corretto per valutare un servizio web, perché molte reti gli assegnano una bassa priorità. Misurare il servizio effettivamente pubblicato.

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/

Ogni valore indica i secondi cumulativi dall'inizio, quindi bisogna calcolare le differenze. time_connect meno time_namelookup è un round trip. time_appconnect meno time_connect è l'handshake TLS. time_starttransfer meno time_appconnect è un ulteriore round trip più il tempo impiegato dall'applicazione per rispondere. Quest'ultima differenza fornisce la diagnosi. Se è vicina alla durata di un round trip, il limite è nella rete e un server più vicino sarà utile. Se è diverse volte superiore alla durata del round trip, l'applicazione è lenta e spostarla non cambia nulla.

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'

Eseguire lo stesso test su un'istanza di prova in ogni località candidata prima di scegliere. Il metodo completo per valutare un VPS considera anche disco e CPU oltre alla rete, così la scelta non si basa soltanto sulla latenza.

Che cosa cambia con un indirizzo di New York

Il prezzo è il primo aspetto. L'energia elettrica e lo spazio in rack nell'area metropolitana di New York costano più che in Texas o nel Midwest. Alcuni provider trasferiscono questa differenza al cliente sotto forma di sovrapprezzo per la località. Altri la distribuiscono sull'intera infrastruttura. Ad agosto 2026 non esiste una regola unica. Prima di presumere l'esistenza di una maggiorazione, confronta la stessa configurazione in due località nella pagina d'ordine del provider. Quanto costa davvero un VPS al mese illustra le altre voci del conto.

La legge non dipende dalla posizione del server. Lo SHIELD Act di New York impone obblighi di notifica delle violazioni e di adozione di misure di sicurezza ragionevoli a chiunque detenga informazioni private su un residente di New York, indipendentemente dal luogo in cui tali dati sono archiviati. Spostare il server a Dallas non elimina questo obbligo. Spostarlo a Manhattan non lo crea. Lo stesso vale per il GDPR (regolamento generale sulla protezione dei dati) e per i tuoi utenti europei. La posizione è rilevante quando un contratto o una normativa di settore indica un paese. Questo accade spesso nel settore sanitario e in alcuni servizi finanziari.

Il rischio legato all'alimentazione elettrica e alle inondazioni merita un paragrafo separato. Quando l'uragano Sandy colpì la zona nell'ottobre 2012, diversi edifici dei carrier a Lower Manhattan persero il servizio perché le pompe del combustibile nei seminterrati furono sommerse e i generatori ai piani superiori rimasero senza carburante. Un singolo sito in qualsiasi area metropolitana costituisce un singolo punto di guasto. Conserva i backup su una rete elettrica diversa e ripristinali almeno una volta in un'altra sede, così verifichi che il ripristino funzioni.

FAQ

Un VPS a New York è più veloce per gli utenti europei rispetto a uno negli Stati Uniti centrali?

Sì, e con un margine prevedibile. Londra dista circa 78 ms dall'area metropolitana di New York, perché i cavi transatlantici approdano sulla costa del New Jersey e su Long Island. Un server a Dallas raggiunge Londra passando prima dalla costa orientale, quindi aggiunge al percorso circa i 38 ms della tratta da Dallas a New York. Se una macchina deve servire sia gli Stati Uniti orientali sia l'Europa, New York è il compromesso meno costoso.

Perché il mio VPS "a New York" si trova in realtà nel New Jersey?

Perché lì sono disponibili spazio e alimentazione elettrica. Gli edifici di Manhattan, come 60 Hudson Street, sono hub di interconnessione e non grandi sale per l'elaborazione; per questo i rack si trovano a Secaucus, Weehawken, Carteret, Piscataway o Newark. La fibra aggiuntiva introduce molto meno di un millisecondo, un valore che nessun carico web percepisce. Chiedi la struttura esatta solo quando ti serve un cross-connect verso una rete specifica all'interno di un determinato edificio.

Come faccio a capire se il problema è davvero la latenza?

Esegui l'analisi dei tempi curl e fai la sottrazione. La differenza tra time_appconnect e time_starttransfer corrisponde a un round trip di rete più il tempo di elaborazione del server. Se questa differenza è molto maggiore del round trip misurato con ping, il ritardo è interno all'applicazione e un data center più vicino non lo risolverà. Se la differenza è vicina a un round trip ma la pagina continua a sembrare lenta, conta quante richieste la pagina esegue in sequenza, perché ciascuna paga di nuovo il round trip.

L'hosting a New York cambia le leggi sulla privacy che si applicano al mio caso?

Nella maggior parte dei casi, no. Normative come lo SHIELD Act di New York e il GDPR dipendono dai dati che detieni, non dal luogo in cui si trova il disco. La posizione del server diventa decisiva quando un contratto o una normativa di settore indica un paese specifico, come accade spesso nel settore sanitario e in alcune aree dei servizi finanziari. Leggi il requisito effettivo prima di scegliere una posizione per soddisfarlo.

Un CDN può sostituire un VPS posizionato correttamente?

Per i file statici, sì. Un CDN (content delivery network) memorizza nella cache immagini e script vicino agli utenti e riduce la distanza per la maggior parte di queste richieste. Non può memorizzare nella cache una dashboard autenticata o una scrittura nel database, quindi queste richieste devono comunque raggiungere il server origin e percorrere l'intero round trip. Posiziona l'origin vicino agli utenti che scrivono dati e lascia che il CDN gestisca il resto.