Perché le velocità WireGuard VPN diminuiscono con latenza elevata

Introduzione

Molti utenti sono sorpresi quando si collegano da un altro paese al server WireGuard del router GL.iNet e trovano velocità molto inferiori alla connessione gigabit simmetrica di casa o a quella altrettanto veloce all'estero, per esempio in un Airbnb. Spesso la colpa è dell'ISP sul lato server o client. Ma la latenza viene spesso ignorata, pur avendo un impatto reale e notevole sul throughput, cioè velocità di download/upload. Questo articolo stabilisce aspettative realistiche e spiega perché le velocità calano con latenza alta, visibile nei risultati del ping.

Che cos'è la latenza e perché conta?

La latenza è il tempo tra dispositivo e server VPN e ritorno, in millisecondi (ms). Da router GL.iNet in Vietnam a VPN Texas, RTT può arrivare facilmente a 250-300 ms.

Anche se Internet è tecnicamente veloce, la latenza alta limita fortemente download e upload reali, soprattutto con protocolli TCP come HTTPs, trasferimenti di file o molte app. Ricorda: WireGuard usa UDP, ma il traffico nel tunnel VPN, web, streaming ecc., spesso è TCP. WireGuard incapsula questi dati TCP in UDP e li invia su Internet.

Collo di bottiglia TCP: capacità legata alla latenza

Ecco la formula chiave che determina le prestazioni TCP:

Finestra TCP = capacità x RTT
Prima alcune definizioni:

• Dimensione finestra TCP è la quantità di dati che il sistema consente di mantenere "in transito" (senza conferma) prima di richiedere una conferma.
• Velocità effettiva è la velocità effettiva, cioè la quantità di dati che puoi inviare o ricevere al secondo.
• RTT (Round-Trip Time) è il ritardo tra l'invio e la ricezione dei pacchetti.

Un esempio reale da un membro del subreddit GL.iNet

Supponiamo che tu sia in Vietnam e ti colleghi al server WireGuard VPN a casa in Texas, in esecuzione su un router GL.iNet Flint 2.

• Posizione del server: Texas, USA
  
  • Velocità locali (fibra simmetrica) 700 Mbps download / 940 Mbps upload
• Posizione client: Vietnam
  
  • Velocità locali, senza VPN: 455 Mbps in download / 634 Mbps in upload
    
  • Velocità locali (con client WireGuard VPN attivo): 47.3 Mbps download / 12.1 Mbps upload, ping 288 ms

Per prima cosa, identifichiamo alcuni limiti comuni a ogni connessione di rete:

1. Variazioni delle prestazioni dell'ISP e congestione nella zona: la velocità può variare anche di centinaia (100) di Mbps
2. Prestazioni Wi-Fi: molto variabili secondo ambiente fisico, interferenze da altri dispositivi wireless, capacità del client e natura intrinsecamente half-duplex del Wi-Fi (rispetto a Ethernet full-duplex)
   • Per una spiegazione approfondita delle prestazioni Wi-Fi realistiche, leggi qui: https://www.wiisfi.com/ Il 1° limite è fuori dal tuo controllo. Anche il 2° lo è in gran parte, ma potrebbe essere eliminato con connessioni Ethernet cablate quando possibile.

Prodotto banda-ritardo

A prima vista i test VPN lato client potrebbero deludere, ma sono buoni considerando la latenza. Ecco perché, usando la formula precedente:
Finestra TCP = 47.3 Mbps x 0.288 secondi
　 　 　 　    = 13.6 Mb, o ~1.7 MB

Una finestra TCP di 1.7 MB è piuttosto grande: ottenerla con latenza 288 ms indica che TCP funziona abbastanza bene. Come è possibile se il campo originale della finestra TCP è limitato a 65,535 byte, circa 64 KB?

Scalatura della finestra TCP per prestazioni migliori

La risposta è TCP Window Scaling, introdotto per reti moderne con banda e latenza elevate. Come spiega Microsoft, il campo della finestra TCP ha solo 16 bit e limita la finestra non scalata a 65,535 byte. L'opzione RFC 7323 permette di spostarla a sinistra fino a 14 bit, aumentando il massimo a 1 GB. Il fattore si negozia nell'handshake TCP a tre passaggi e moltiplica la finestra originale. Gli algoritmi di congestione del sistema client determinano continuamente il valore corretto. In alcuni casi, come Microsoft Windows, l'auto-tuning della finestra massimizza il download particolarmente male.

Esempio di finestra TCP negoziata dall'OS ed effetto latenza sulla capacità Fonte: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Perché non puoi aumentare all'infinito la dimensione della finestra TCP

La dimensione della finestra TCP dipende dalla larghezza di banda disponibile e dal tempo di andata e ritorno. Tuttavia, aumentarla non basta necessariamente a ottenere più throughput. Oltre un certo punto, finestre maggiori richiedono più memoria e potenza di elaborazione sia al mittente sia al destinatario, sovraccaricando dispositivi e reti e causando più perdita di pacchetti e prestazioni inferiori.

Nel caso precedente, una finestra TCP di circa 1.7 MB è normale e indica buona connessione data la latenza alta. Il limite superiore generale di circa 2 MB può fungere da limite pratico per molti sistemi moderni, bilanciando throughput e uso delle risorse. Con una finestra di 2 MB e latenza di 288 ms, il throughput teorico massimo sarebbe circa 55.5 Mbps. Questo spiega perché superarlo è difficile anche con connessioni Internet molto più veloci a entrambe le estremità, server e client. Riorganizzando l'equazione precedente per calcolare il throughput, con latenza di 80 ms e finestra di 2 MB potremmo teoricamente raggiungere circa 200 Mbps. Purtroppo le leggi della fisica impediscono tale latenza a causa della distanza, Texas <-> Vietnam.

Conclusione

Speriamo che la spiegazione dia aspettative più realistiche su download e upload della VPN WireGuard all'estero. Ricorda che i router gestiscono molte sessioni TCP insieme. GL.iNet Flint 2 ha RAM DDR4 1 GB, ma il router client collegato a Flint 2 può averne molta meno e limitare la scala della finestra TCP.

Per informazioni e consigli sulla configurazione WireGuard VPN e diagnosi, vedi il post GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Presentiamo i router domestici GL.iNet