La latenza di rete è il tempo che un pacchetto di dati impiega per andare da un punto A a un punto B e tornare indietro. Si misura in millisecondi (ms) e il valore di andata e ritorno si chiama round trip time (RTT). Più la latenza è bassa, più i sistemi remoti rispondono in fretta.
Il motivo per cui ci riguarda è che la latenza si vede a occhio nudo, da chiunque, tutti i giorni. Pensiamo alla videocall che si blocca per mezzo secondo mentre il collega sta parlando, o al terminale di cassa che aspetta la risposta del gestionale prima di stampare lo scontrino. Questi ritardi dipendono da quanti millisecondi servono perché la richiesta arrivi al server e la risposta torni indietro.
In questo articolo, Milano e Padova saranno i punti di riferimento perché ospitano i due principali hub di interscambio internet del Nord Italia, il MIX e il VSIX. Qui le reti degli operatori si scambiano il traffico. La distanza che conta, quando si sceglie dove ospitare un servizio, non è solo quella tra la sede aziendale e il Data Center sulla carta geografica, ma anche quella tra il Data Center e questi snodi, e da lì verso il resto del mondo.
Mettiamo in fila i numeri reali e vediamo cosa cambiano in concreto per i sistemi aziendali.
Da cosa dipende la latenza: le tre componenti
La latenza totale di un collegamento è la somma di tre fattori.
La distanza fisica
La luce nella fibra ottica viaggia a circa 200.000 km al secondo, due terzi della velocità nel vuoto. Significa che ogni 100 km di fibra costano circa 1 millisecondo di andata e ritorno. È un limite fisico che nessuna tecnologia elimina. Milano e Francoforte distano oltre 500 km in linea d’aria, e il percorso reale della fibra è sempre più lungo di quello geografico.
Il numero di salti sulla rete
Ogni pacchetto attraversa router, switch e punti di interscambio tra operatori. Ogni apparato aggiunge tempo di elaborazione e, nei momenti di congestione, tempo di coda. Un percorso con molti salti e molti passaggi tra reti diverse accumula ritardo anche su distanze brevi. Su questo torneremo più avanti, perché è il fattore meno raccontato e quello su cui un operatore con rete proprietaria può fare la differenza maggiore.
La qualità dell’infrastruttura
Apparati datati e tratte sature si traducono in millisecondi aggiuntivi e, soprattutto, in variabilità. Una rete ben dimensionata dà valori bassi e li mantiene stabili nel tempo. La stabilità, come vedremo parlando di VoIP, conta quanto la velocità.
I numeri reali: quanti ms tra gli hub del Nord Italia e le principali destinazioni
La tabella riporta valori di round trip time indicativi dagli hub di interscambio di Milano e Padova verso le destinazioni più rilevanti per un’azienda italiana.[1]
| Tratta | RTT indicativo | Note |
| Milano (MIX) ↔ Padova (VSIX) | 3-6 ms | Percorso diretto in fibra, circa 250 km: è la dorsale interna del Nord Italia |
| Milano ↔ Francoforte | 15-25 ms | Le misure oscillano a seconda dell’instradamento attivo |
| Milano ↔ Dublino | 35-40 ms | Valore misurato: circa 36 ms |
| Milano ↔ Virginia, USA (area Ashburn) | 90-105 ms | Tratta transatlantica; valore misurato verso Washington: circa 93 ms |
Vale la pena soffermarsi su due aspetti. Un servizio ospitato in un Data Center italiano ben collegato agli hub risponde con 15-25 ms di vantaggio rispetto allo stesso servizio a Francoforte, su ogni singola richiesta. Pochi per un’applicazione che interroga il server ogni tanto, molti per una che lo fa centinaia di volte in sequenza, come vedremo con l’ERP. La tratta verso gli Stati Uniti, invece, costa da sola circa 100 ms: qualsiasi servizio su cloud USA East parte con questo handicap per gli utenti italiani, prima ancora che il server inizi a elaborare la richiesta.
C’è poi la forbice sulla tratta Milano-Francoforte, che nelle stesse settimane e sullo stesso collegamento oscilla tra 14 e 25 ms. I chilometri non sono cambiati, il percorso sì. Su questo punto torniamo tra poco.
Cosa cambia per il tuo ERP
I gestionali client-server sono applicazioni per i quali una singola operazione utente, come salvare un ordine o aprire una scheda articolo, può generare decine di round trip verso il database. E ogni round trip paga per intero la latenza della tratta.
Facciamo un esempio con numeri semplici. Un’azienda multi-sede ha il database dell’ERP in un Data Center e le filiali collegate da remoto. Un’operazione tipica richiede 20 interrogazioni sequenziali al database. Con il database a 5 ms di latenza, per un totale di 100ms, l’operatore non percepisce nulla. Con il database a 35 ms (per esempio in un Data Center estero raggiunto con instradamento non ottimale) si hanno 700 ms di latenza. Oltre mezzo secondo di attesa a ogni salvataggio. Su una giornata lavorativa di centinaia di operazioni per addetto, il costo in produttività diventa misurabile.
Il conto vale anche in termini di throughput, ovvero la quantità di lavoro, dati o prodotti che un sistema riesce a elaborare o trasferire con successo in un determinato intervallo di tempo.
Per fissare delle soglie pratiche di orientamento possiamo dire che:
- Sotto i 10 ms un ERP client-server lavora come se il database fosse in sede.
- Tra 10 e 30 ms la lentezza inizia a farsi sentire sulle operazioni più complesse.
- Oltre i 50 ms l’esperienza degrada in modo evidente e conviene ripensare l’architettura. Ad esempio, ospitare il database più vicino agli utenti oppure passare a un’interfaccia web progettata per ridurre i round trip.
Cosa cambia per VoIP e Unified Communications
In questi casi al centro c’è la voce, che ha soglie note e codificate. In linea di massima, 150 ms è il limite di ritardo bocca-orecchio entro cui la conversazione resta naturale per la quasi totalità degli utenti. Tra 150 e 300 ms la qualità degrada progressivamente e gli interlocutori iniziano a sovrapporsi e a rubarsi il turno di parola. Oltre i 300 ms la conversazione diventa faticosa.[2]
Attenzione a un punto: in quei 150 ms c’è tutto il percorso, non solo la rete. Codifica, pacchettizzazione e buffer di riproduzione consumano ciascuno la propria quota. La componente di rete deve quindi restare ben al di sotto della soglia complessiva. Nella pratica, per una qualità voce solida, si punta a tenerla sotto i 50 ms.
C’è poi il jitter, cioè la variabilità della latenza tra un pacchetto e il successivo. La soglia di riferimento comunemente adottata è un jitter sotto i 30 ms.
Cosa cambia per videosorveglianza e IoT
Un impianto di videosorveglianza moderno trasmette decine di flussi video simultanei verso piattaforme di analisi che riconoscono eventi in tempo reale, come un varco attraversato fuori orario o un mezzo fermo dove non dovrebbe.
Qui la latenza incide su due piani. Il primo è la banda moltiplicata per la distanza: trasportare 50 flussi video fino a un Data Center lontano costa in capacità di rete e ogni ritrasmissione dovuta a perdita di pacchetti aggrava il ritardo. Il secondo è il tempo di reazione: se tra l’evento ripreso e la notifica all’operatore passano secondi, il valore dell’analisi real-time si riduce.
Per questo la tendenza del settore è avvicinare l’elaborazione alle telecamere. La prima analisi avviene in un Data Center di prossimità, mentre verso il cloud centrale viaggiano solo gli eventi e i metadati anziché i flussi grezzi. Lo stesso schema vale per l’IoT industriale.
Il fattore meno raccontato: i salti, non solo i chilometri
L’intuizione comune dice che il server più vicino risponde prima. È vera solo a metà, perché i pacchetti seguono i percorsi delle reti e i loro punti di interscambio, che raramente coincidono con la linea d’aria.
Facciamo anche qui un esempio pratico. Un’azienda interroga un server ospitato in un Data Center a 100 km dalla sede. Se il suo operatore non ha un collegamento diretto con la rete che ospita quel server, il traffico può salire fino a un punto di interscambio, passare per due o tre reti intermedie e ridiscendere. Risultato: 15-20 ms per un server “dietro l’angolo”. La stessa azienda potrebbe raggiungere un server a oltre 500 km di distanza, in tempi simili, semplicemente perché il percorso è diretto.
Chi controlla il percorso controlla la latenza. È il motivo per cui i Data Center Planetel sono interconnessi in fibra ottica proprietaria a entrambi gli hub di interscambio del Nord Italia, il MIX di Milano e il VSIX di Padova. Da qualsiasi Data Center della nostra rete, il traffico dei clienti raggiunge gli snodi principali senza attraversare reti terze, con un numero di salti ridotto e, soprattutto, costante nel tempo. Meno variabili nel percorso significa latenza più bassa e più prevedibile, ovunque sia ospitato il servizio.
Quando vale la pena spostare un servizio
Non tutto deve stare a pochi millisecondi dagli utenti. Per decidere, conviene incrociare due domande: quanto è critico il servizio per l’operatività? E quanto è sensibile alla latenza?
| Bassa sensibilità alla latenza | Alta sensibilità alla latenza | |
| Bassa criticità | Backup, archivi e ambienti di test. Possono stare ovunque: decide il costo. | Strumenti di collaborazione secondari. Vale la pena avvicinarli se il costo è simile. |
| Alta criticità | Posta, portali documentali e applicazioni web ben progettate. Il cloud remoto funziona; serve però ridondanza. | ERP client-server, VoIP, analisi video e database transazionali. Vanno ospitati vicino agli utenti, su percorsi di rete controllati. |
Il quadrante in basso a destra è quello che merita l’analisi più attenta. Prima di migrare un servizio critico e sensibile è opportuno fare un semplice test di ping e traceroute dalla sede verso la destinazione candidata, ripetuto in orari diversi per qualche giorno. Se i valori superano le soglie viste nelle sezioni precedenti, la destinazione va riconsiderata.
Domande frequenti
Su un percorso in fibra ottimizzato tra i punti di interscambio VSIX di Padova e MIX di Milano, il round trip time indicativo è di 3-6 ms. Su instradamenti non ottimizzati, che passano per più reti intermedie, il valore può superare i 10-15 ms.
Per gli utenti italiani, in genere sì: la tratta tra il Nord Italia e Francoforte aggiunge indicativamente 15-25 ms di round trip time rispetto a un Data Center italiano ben collegato agli hub di interscambio. Il vantaggio effettivo dipende però dal percorso di rete: un Data Center italiano raggiunto con molti salti può rispondere peggio di uno tedesco raggiunto con un collegamento diretto.
Lo strumento più semplice è il comando ping, che invia un pacchetto verso una destinazione e misura il tempo di andata e ritorno (round trip time). Il comando traceroute mostra invece i singoli salti del percorso e il tempo di ciascuno, utile per capire dove si accumula il ritardo. Per valutazioni serie conviene ripetere le misure in orari e giorni diversi.
Il jitter è la variazione della latenza tra pacchetti consecutivi. Se i pacchetti arrivano a intervalli irregolari, le applicazioni real-time come la voce e il video ne risentono anche quando la latenza media è buona. Per il VoIP si considera accettabile un jitter inferiore a 30 ms.
La raccomandazione ITU-T G.114 indica 150 ms di ritardo bocca-orecchio (solo andata) come soglia entro cui la conversazione resta naturale; tra 150 e 300 ms la qualità degrada progressivamente, oltre i 300 ms la conversazione diventa difficile. Poiché la soglia include codifica e buffer oltre alla rete, in pratica si punta a mantenere la componente di rete sotto i 50 ms.
Perché scegliere Planetel
I nostri 7 Data Center sono interconnessi in fibra ottica proprietaria al MIX di Milano e al VSIX di Padova, i due principali hub di interscambio del Nord Italia. Il traffico raggiunge gli snodi con un numero di salti ridotto e latenza prevedibile.
Inoltre, con l’Edge Data Center che stiamo realizzando a Padova, porteremo la capacità di calcolo ancora più vicino alle aziende.
Se vuoi saperne di più e avere maggiori informazioni, i nostri specialisti sono a tua disposizione al numero 035 204461 o all’indirizzo [email protected].
[1] I dati provengono da misurazioni pubbliche (WonderNetwork Global Ping Statistics, rilevazioni di luglio 2026 dal nodo di Milano); la tratta Milano-Padova è stimata su percorso in fibra ottimizzato. I valori effettivi dipendono dall’operatore e dall’instradamento.
[2] Raccomandazione ITU-T G.114