Varför WireGuard VPN-hastigheter sjunker vid hög latens

Introduktion

Många blir förvånade när de ansluter till sin GL.iNet-routers WireGuard-server från ett annat land och får betydligt lägre internethastigheter än den symmetriska gigabitanslutningen hemma eller den lika snabba anslutningen utomlands, till exempel på ett Airbnb. Ofta kan internetleverantören på server- eller klientsidan vara orsaken. Men latens förbises ofta trots dess stora och konkreta påverkan på genomströmningen, alltså ned- och uppladdningshastigheterna. Det här inlägget vill ge realistiska förväntningar och förklara varför hastigheten försämras vid hög latens, det vill säga höga pingvärden.

Vad är latens och varför spelar den roll?

Latens är tiden det tar för data att färdas från din enhet till VPN-servern och tillbaka. Den mäts ofta i millisekunder (ms). Om din GL.iNet-router i Vietnam ansluter till en VPN-server i Texas kan rundturstiden (RTT) till exempel lätt bli 250-300 ms.

Även om internetanslutningen tekniskt sett är ”snabb” kan hög latens kraftigt begränsa faktiska ned- och uppladdningshastigheter, särskilt med TCP-baserade protokoll som HTTPs, filöverföringar och de flesta appar. Kom ihåg att även om WireGuard självt använder UDP är trafiken i VPN-tunneln, som webbtrafik och strömning, ofta TCP-baserad. WireGuard kapslar in TCP-data i UDP och skickar dem över internet.

TCP-flaskhalsen: genomströmningen är kopplad till latensen

Här är den viktiga formeln som styr TCP-prestandan:

TCP Window Size = Throughput x RTT
Först några definitioner:

• TCP-fönsterstorlek är mängden data som systemet tillåter att vara på väg utan mottagningsbekräftelse innan en bekräftelse krävs.
• Genomströmning är din faktiska hastighet, alltså hur mycket data per sekund du kan skicka eller ta emot.
• RTT (Round-Trip Time) är fördröjningen mellan att paket skickas och tas emot.

Ett verkligt exempel från en medlem i GL.iNets subreddit

Anta att du befinner dig i Vietnam och ansluter till din WireGuard VPN-server hemma i Texas på en GL.iNet Flint 2-router.

• Serverplats: Texas, USA
  
  • Lokala hastigheter (symmetrisk fiber) 700 Mbps nedladdning / 940 Mbps uppladdning
• Klientplats: Vietnam
  
  • Lokala hastigheter (utan VPN): 455 Mbps nedladdning / 634 Mbps uppladdning
    
  • Lokala hastigheter (med WireGuard VPN-klient aktiverad): 47.3 Mbps nedladdning / 12.1 Mbps uppladdning, 288 ms ping

Först några vanliga begränsningar för alla nätverksanslutningar:

1. Variationer i internetleverantörens prestanda och överbelastning i området: hastigheten kan variera med 100-tals Mbps
2. Wi-Fi-prestanda: varierar kraftigt med den fysiska miljön, störningar från andra trådlösa enheter, klientenhetens kapacitet och Wi-Fis halvduplexfunktion jämfört med Ethernet med full duplex
   • En djupare förklaring av realistisk Wi-Fi-prestanda finns här: https://www.wiisfi.com/ Den 1:a begränsningen ligger utanför din kontroll. Den 2:a gör det också till stor del, men kan eventuellt elimineras genom kabelanslutningar via Ethernet där det är möjligt.

Bandbredds- och fördröjningsprodukten

Vid första anblick kan klientens VPN-hastighetstest verka nedslående, men med tanke på latensen är resultaten faktiskt ganska bra. Här är förklaringen med formeln ovan:
TCP Window Size = 47.3 Mbps x 0.288 seconds
　 　 　 　    = 13.6 Mb, eller ~1.7 MB

Ett TCP-fönster på 1.7 MB är faktiskt ganska stort. Att uppnå det över en anslutning med 288 ms latens visar att TCP fungerar rimligt bra. Men hur är det möjligt när det ursprungliga fältet för TCP-fönsterstorlek är begränsat till 65,535 bytes (ungefär 64 KB)?

TCP Window Scaling ger bättre prestanda

Svaret finns i funktionen TCP Window Scaling, som infördes för moderna nätverk med hög bandbredd och latens. Som Microsoft beskriver i artikeln är fältet för TCP-fönsterstorlek bara 16 bitar, vilket begränsar det oskalade fönstret till 65,535 bytes. För att övervinna det infördes TCP-fönsterskalning i RFC 7323, så att fönsterstorleken kan vänsterförskjutas med upp till 14 bitar och därmed öka till högst 1 GB. Skalningsfaktorn förhandlas fram under TCP:s trevägshandskakning. När funktionen är aktiverad kan ändpunkterna multiplicera den ursprungliga fönsterstorleken. Överbelastningsalgoritmer i klientenhetens operativsystem arbetar ständigt för att bestämma rätt skalning av fönsterstorleken. I vissa fall, till exempel i Microsoft Windows, gör fönstrets ”auto-tuning” ett särskilt dåligt jobb med att maximera nedladdningshastigheten.

Exempel på operativsystemförhandlad TCP-fönsterstorlek och latensens påverkan på genomströmningen Källa: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Varför du inte bara kan fortsätta öka TCP-fönsterstorleken

I slutänden beror TCP-fönsterstorleken på tillgänglig bandbredd och rundturstiden. Men det är inte så enkelt som att öka fönstret för högre genomströmning. Efter en viss punkt kräver större fönster mer minne och processorkraft hos både sändare och mottagare. Det kan överbelasta enheter och nätverk och leda till större paketförlust och sämre prestanda.

I det tidigare exemplet är ett TCP-fönster på omkring 1.7 MB alltså ganska normalt och visar en välfungerande anslutning med tanke på den höga latensen. En allmän övre gräns på omkring 2 MB kan fungera som ett praktiskt tak i många moderna system genom att balansera genomströmning och resursanvändning. Med ett fönster på 2 MB och 288 ms latens blir den teoretiska maximala genomströmningen ungefär 55.5 Mbps. Det förklarar varför högre hastigheter är svåra att uppnå trots mycket snabbare råa internetanslutningar i båda ändar, server och klient. Om vi ordnar om variablerna i formeln för att lösa ut genomströmningen ser vi att 80 ms latens och ett 2 MB-fönster teoretiskt kan ge omkring 200 Mbps. Tyvärr gör fysikens lagar att vi inte kan uppnå denna latens på grund av det fysiska avståndet (Texas <-> Vietnam).

Slutsats

Förhoppningsvis har artikeln förklarat varför du bör ha mer realistiska förväntningar på ned- och uppladdningshastigheter nästa gång du använder WireGuard VPN utomlands. Kom också ihåg att routrar hanterar många TCP-sessioner samtidigt. Den populära GL.iNet Flint 2 har generösa 1 GB DDR4 RAM, men klientroutern som ansluter till denna Flint 2 kan ha mycket mindre RAM och därmed begränsa skalningen av TCP-fönsterstorleken.

Mer information och felsökningstips för din WireGuard VPN-konfiguration finns i följande inlägg på GL.iNets forum: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Vi presenterar GL.iNets hemroutrar