Perché la velocità verso i server UE è più bassa di Speedtest

Speedtest segna 290 Mbps. La velocità reale verso i server nell'UE esce invece intorno ai 38 Mbps. Un divario di circa otto volte è difficile da ignorare. Quasi sempre nasce dalla lunga rotta internazionale, non dalla tua attrezzatura e non dal nostro servizio.

In breve

Speedtest e un collegamento reale con un server lontano misurano cose diverse. Speedtest guarda la capacità grezza della tua linea su una rotta cortissima. Con i server nell'UE contano il ritardo e lo stato dei canali internazionali attraversati dal traffico. Un risultato alto di Speedtest dice solo che la linea è sana. La bassa velocità verso l'UE nasce dalla fisica dei collegamenti lunghi. E dal carico delle reti di transito.

Che aspetto ha il divario

Ecco una stessa linea misurata due volte, a pochi minuti di distanza. Prima Speedtest, contro un server che ha scelto da solo.

Due dettagli di quel pannello spiegano quasi tutto il numero. Alla voce "Connections" c'è "Multi", quindi la cifra somma più flussi insieme. E il server scelto sta nello stesso paese. Ora la stessa linea contro i server che i webinar li portano davvero. È il passo "Speed" del nostro tester di connessione.

La ricezione cala di circa otto volte. L'invio scende solo da 26 a 16, una discesa molto più dolce. Nessuna delle due cifre indica una linea guasta. Dove finisce ciascuna lo racconta il resto della pagina.

Il secondo pannello va letto con attenzione. "TO YOU" è quello che ricevi, "FROM YOU" è quello che invii. Sei tu a condurre? Allora conta proprio la cifra "FROM YOU", perché camera, microfono e condivisione dello schermo salgono verso l'alto. A un partecipante che guarda soltanto serve invece "TO YOU". Nella misura qui sopra, 15,98 Mbps in invio sono circa dieci volte quello che serve a un relatore.

Le diciture negli screenshot sono in inglese, perché l'interfaccia è ripresa nella versione inglese. In un sistema in italiano le stesse voci portano un nome italiano e stanno negli stessi punti.

Che cosa misura davvero Speedtest

Speedtest è costruito per mostrare il numero più alto possibile. Il suo risultato riflette quindi solo in parte il lavoro con i server lontani.

• Prende il server più vicino. Speedtest sceglie il nodo con il ritardo più basso, di solito dentro la rete del tuo provider o nella stessa città. Il traffico verso quel nodo fa una rotta corta e i canali internazionali non li tocca affatto.
• Apre molte connessioni insieme. Speedtest avvia più flussi TCP alla volta, di solito da 4 a 16, e ne somma la velocità. Così aggira il limite di una singola connessione sulle rotte lunghe, di cui parla la sezione dopo. I programmi veri lavorano spesso su uno o due flussi, e quella spinta non gli arriva.
• Il ritardo è minimo. Su una rotta corta il tempo di andata e ritorno, detto RTT, è di pochi millisecondi, e TCP fa in tempo a salire alla piena velocità della linea.

Speedtest mostra così la capacità da laboratorio della tua linea. Quello che otterrai scambiando dati con un server in un altro paese non lo mostra.

Prodotto banda per ritardo e finestra TCP

La maggior parte del divario si regge su un solo meccanismo.

TCP manda i dati a finestre. Il mittente spinge fuori una porzione di dati e aspetta la conferma di arrivo prima di continuare. La velocità massima di una singola connessione TCP segue una formula semplice.

Velocità = dimensione della finestra / ritardo (RTT)

Per riempire la linea del tutto, la finestra deve valere almeno quanto il prodotto banda per ritardo, detto BDP.

BDP = banda × RTT

Mettiamo i numeri di quella linea da 290 Mbps, con un ritardo verso un server nell'UE intorno ai 50 ms.

BDP = 290.000.000 bit/s × 0,05 s = 14.500.000 bit = 1,81 MB

Circa 1,8 MB di dati devono quindi stare in transito a ogni istante, altrimenti la linea non si satura. Una delle due parti è ferma su una finestra limitata, cioè i classici 64 KB senza scalatura della finestra? Allora il tetto di una singola connessione viene così.

Velocità = 65.536 byte × 8 bit / 0,05 s ≈ 10,5 Mbps

Ecco perché una singola connessione verso un server lontano si ferma tra 10 e 20 Mbps. Vale anche quando la linea è tarata per centinaia di megabit. Su una rotta corta con RTT di 2 ms la stessa finestra darebbe oltre 260 Mbps. Per questo in Speedtest il problema non salta mai fuori. Più alto è il ritardo, più forte è l'effetto. Non c'è niente di rotto, il protocollo funziona così.

Il ritardo e la fisica dei collegamenti lunghi

Il ritardo su una rotta lunga si compone di più parti, e alcune non si tolgono affatto.

La luce corre nella fibra ottica a circa 200.000 km/s. Va molto più piano che nel vuoto, per via dell'indice di rifrazione del vetro. Ogni mille chilometri di rotta aggiungono circa 5 ms in un senso, cioè circa 10 ms sul giro. E rotte dritte quasi non ne esistono. Il percorso reale supera di solito la distanza geografica.

Poi c'è il ritardo su ogni nodo intermedio. Il router elabora il pacchetto, lo mette in coda e lo manda avanti. Verso un server nell'UE questi nodi, detti hop, sono di solito da 10 a 20. Ognuno aggiunge la sua parte. Più alto è l'RTT finale, più basso è il tetto di una singola connessione secondo la formula qui sopra.

La perdita di pacchetti e il suo effetto su TCP

Anche una perdita piccola su un canale internazionale taglia di netto la velocità finale. TCP legge un pacchetto perso come segno di congestione, quindi rallenta e poi risale. Il legame lo descrive la formula di Mathis.

Velocità ≈ MSS / (RTT × √p)

MSS è la dimensione massima del segmento, di solito intorno ai 1460 byte. RTT è il ritardo, p è la quota di pacchetti persi. La velocità scende come l'inverso della radice quadrata della quota di perdita. E dipende direttamente dal ritardo.

Nella pratica i numeri fanno impressione. Con RTT di 50 ms e un MSS normale, anche lo 0,1 percento di perdita tiene una singola connessione intorno ai 7 Mbps. L'uno percento la porta verso 2,3 Mbps, il due percento sotto 1,7 Mbps. Sulle lunghe rotte di transito una perdita dall'1 al 2 percento nelle ore di punta è del tutto normale. Dove arriva a quei valori morde più forte del limite della finestra. Da qui la rotta che al mattino è solo lenta e alla sera diventa inservibile.

Instradamento e peering

Il percorso del tuo traffico verso un server nell'UE non è diretto. Passa per una catena di operatori e per il protocollo di instradamento BGP. E quel protocollo sceglie la strada su basi commerciali e tecniche, non sulla distanza più breve.

Da qui nascono alcuni guai tipici. La rotta può passare per un terzo paese pur esistendo un percorso più corto. Salgono allora sia il ritardo sia il rischio di perdita. Il traffico attraversa poi le giunzioni tra le reti, cioè i punti di peering e i canali di transito. Una giunzione intasata è esattamente dove la velocità crolla. È comune anche l'instradamento asimmetrico, con i pacchetti che escono da una strada e tornano da un'altra. La diagnosi si legge molto peggio. E la capacità internazionale si compra. Al provider che ha comprato con il contagocce, nelle ore di punta manca.

La congestione sui canali internazionali del tuo provider

Il traffico locale, dentro la città e dentro il paese, ha capacità in avanzo presso quasi tutti i provider. Ecco perché Speedtest verso un server vicino mostra sempre un numero alto. I canali internazionali costano di più e si comprano in volume limitato. Nel picco della sera diventano il collo di bottiglia. Questo spiega perché la velocità verso l'UE oscilla parecchio nell'arco della giornata. Lo Speedtest locale invece resta alto in modo costante.

Altri fattori tecnici

Oltre alle cause principali, sulla velocità verso un server lontano pesano ancora alcune cose.

MTU e frammentazione. Se l'MTU lungo la rotta è più piccolo del previsto, i pacchetti si frammentano e l'efficienza cala. Un PMTUD configurato male, cioè la scoperta dell'MTU sul percorso, porta a buchi neri e trasferimenti bloccati.

Bufferbloat. Buffer sovradimensionati sui nodi intermedi alzano il ritardo sotto carico. Confondono anche gli algoritmi di controllo del flusso di TCP, e la velocità reale scende ancora.

Shaping e priorità, ovvero QoS. Alcuni provider strozzano di proposito il traffico internazionale, o un suo tipo particolare. E la cosa si vede subito nella velocità.

Il peso dei protocolli. Le intestazioni di TCP, di IP e della cifratura si mangiano una parte della banda. Su una rotta corta non si vede. Insieme a perdita e ritardo su una rotta lunga, invece, si somma.

Il tuo ambiente locale. Wi-Fi invece del cavo, un router di casa sovraccarico, un antivirus o una VPN sul dispositivo abbassano la velocità reale. Escludili prima di cercare il guasto lontano.

Perché non è un problema di attrezzatura o di servizio

Un risultato alto di Speedtest prova che la tua attrezzatura e la tua linea locale sono sane. Danno la velocità che devono. Il calo con i server nell'UE arriva da un'altra parte. La colpa è del ritardo sulla rotta lunga e del limite della finestra su una singola connessione TCP. Poi ci sono la perdita di pacchetti e lo stato dei canali internazionali del tuo provider. Tutto questo sta fuori dal nostro servizio e fuori dalla tua attrezzatura. Sta sul tratto di rete tra il tuo provider e gli operatori di dorsale.

Una cosa da tenere a mente prima di rincorrere i numeri. A un webinar serve molto meno che a un trasferimento di file. Quindi 20 Mbps verso l'UE per noi non sono affatto un problema. A un relatore servono circa 1,6 Mbit/s in invio, o 3,2 mentre condivide lo schermo. A un partecipante serve banda per ogni relatore in onda, e i requisiti tecnici spiegano tutto per intero. Qui la stabilità conta più della velocità grezza. Se i tuoi eventi filano lisci, il divario con Speedtest è una curiosità, non un guasto da riparare.

Come verificarlo da solo

Qualche controllo inchioda la causa.

• Lancia Speedtest a mano e scegli un server in Germania o in Finlandia. Tutti i nostri server stanno nell'UE, tra Germania, Francia, Paesi Bassi e Finlandia, ma il traffico dei webinar lo portano proprio le macchine tedesche e finlandesi. Quelle olandesi e francesi mandano le email di invito agli eventi in arrivo, quindi misurare contro quelle due racconta una rotta che i tuoi webinar non fanno mai. Germania e Finlandia mostrano la velocità reale sulla rotta usata nella pratica, non quella verso il server locale più vicino.
• Traccia la rotta. Il comando tracert su Windows, o traceroute su macOS e Linux, verso il nostro server dà la catena di nodi con il ritardo su ognuno. Perdita e ritardo si vedono meglio con l'utilità mtr, su Windows WinMTR, da lasciare in funzione qualche minuto nelle ore di punta.
• Confronta una connessione con più connessioni. Il download a più flussi è veloce e a flusso singolo è lento? Questo conferma il limite della finestra TCP sulla rotta lunga.
• Hai la possibilità tecnica? Misura la capacità verso il nodo lontano direttamente con iperf3, prima con un flusso e poi con più flussi.

Nel nostro tester dell'attrezzatura c'è anche un collegamento a una prova dedicata alla qualità di internet. Riporta velocità, ping e jitter. È un modo rapido per fissare lo stato della linea in un dato momento.

Cosa fare

I tuoi controlli mostrano ritardo alto o perdita di pacchetti sulla tratta internazionale? Vai dal provider con dati concreti, cioè la traccia della rotta e una lettura di mtr con l'ora annotata. Correggere la rotta o allargare la connettività internazionale è lavoro suo. Da parte nostra ti diamo gli indirizzi dei nostri server per una diagnosi mirata. E ti aiutiamo a leggere i risultati. Scrivici nella chat online e te li mandiamo.

In conclusione

Un risultato Speedtest vicino ai 290 Mbps conferma che la tua linea è sana. Il calo sotto i 40 Mbps con i server nell'UE è previsto. Si regge sul ritardo della rotta lunga e sul limite della finestra di una singola connessione TCP. Contano anche la perdita di pacchetti e il carico dei canali internazionali del tuo provider. Quelle cause stanno nella rete tra te e noi, non nella tua attrezzatura e non nel nostro servizio. Una semplice diagnosi della rotta mostrerà quale delle quattro sta facendo il danno.

Domande frequenti

Devo pagare una linea più veloce per risolvere?

No, perché a un webinar serve molto meno che a un trasferimento di file. E 20 Mbps verso l'UE per noi non sono affatto un problema. A un relatore servono circa 1,6 Mbit/s in invio, o 3,2 mentre condivide lo schermo. Tutte le cifre le danno i requisiti tecnici. Qui la stabilità conta più della velocità grezza. Se i tuoi eventi filano lisci, il divario con Speedtest è una curiosità, non un guasto da riparare.

La ricezione è calata di otto volte e l'invio quasi non si è mosso. Quale conta?

L'invio, se sei tu a condurre, perché camera, microfono e condivisione dello schermo salgono verso l'alto. È la cifra "FROM YOU". A un partecipante che guarda soltanto serve invece "TO YOU". La stessa misura si legge quindi in modo diverso a seconda del ruolo che hai all'evento. Nella lettura qui sopra l'invio è sceso solo da 26 a 16 Mbps, circa dieci volte quello che serve a un relatore.

Quale server Speedtest scegliere per un confronto onesto?

Uno in Germania o in Finlandia. Tutti i nostri server stanno nell'UE, tra Germania, Francia, Paesi Bassi e Finlandia. Ma il traffico dei webinar lo portano proprio le macchine tedesche e finlandesi. Quelle olandesi e francesi mandano le email di invito agli eventi in arrivo. Misurare contro quelle due racconta una rotta che i tuoi webinar non fanno mai.

C'è qualcosa che posso sistemare da solo?

Parti dal tuo lato. Wi-Fi invece del cavo, un router di casa sovraccarico, un antivirus o una VPN sul dispositivo abbassano la velocità reale. Qui è tutto pulito e i controlli mostrano comunque ritardo alto o perdita sulla tratta internazionale? Allora la soluzione spetta al provider. Vai da lui con dati concreti, cioè la traccia della rotta e una lettura di mtr con l'ora annotata. Gli indirizzi dei nostri server per una diagnosi mirata te li diamo noi, scrivici nella chat online.

Perché la rotta al mattino va bene e alla sera è inservibile?

I canali internazionali si comprano in volume limitato e nel picco della sera diventano il collo di bottiglia. Il traffico locale invece ha capacità in avanzo. Ecco perché Speedtest verso un server vicino resta alto tutto il giorno. La perdita di pacchetti segue la stessa curva. Una perdita dall'1 al 2 percento sulle lunghe rotte di transito nelle ore di punta è del tutto normale. Con RTT di 50 ms, l'uno percento tiene una singola connessione intorno ai 2,3 Mbps. Ed è questo che trasforma una rotta solo lenta in una inservibile.