Waarom WireGuard-VPN-snelheden dalen bij hoge latentie

Inleiding

Veel gebruikers verbinden vanuit het buitenland met de WireGuard-server op hun GL.iNet-router en zijn verbaasd dat de snelheid veel lager is dan de symmetrische gigabitverbinding thuis of het snelle internet op hun verblijfplaats, bijvoorbeeld Airbnb. Vaak krijgt de provider aan server- of clientzijde de schuld. Latentie wordt echter vaak vergeten, terwijl die een grote invloed op doorvoer en download-/uploadsnelheden heeft. Dit artikel helpt realistische verwachtingen te vormen en legt uit waarom hoge latentie, zichtbaar in pingresultaten, snelheden verlaagt.

Wat is latentie en waarom is het belangrijk?

Latentie is de tijd die gegevens nodig hebben om van uw apparaat naar de VPN-server en terug te gaan, meestal gemeten in milliseconden (ms). Als uw GL.iNet-router in Vietnam met een VPN-server in Texas verbindt, kan de retourtijd (RTT) gemakkelijk 250-300 ms zijn.

Zelfs als uw internet technisch “snel” is, kan hoge latentie de werkelijke download en upload sterk beperken, vooral bij TCP-gebaseerde protocollen zoals HTTPs, bestandsoverdracht en de meeste apps. WireGuard gebruikt zelf UDP, maar het verkeer in de VPN-tunnel is vaak TCP. WireGuard verpakt die TCP-gegevens in UDP en verzendt ze over internet.

Het TCP-knelpunt: doorvoer hangt samen met latentie

De belangrijkste formule voor TCP-prestaties:

TCP-venstergrootte = Doorvoer x RTT
Eerst enkele definities:

• TCP-venstergrootte is de hoeveelheid nog niet bevestigde gegevens die onderweg mag zijn voordat uw systeem een bevestiging vereist.
• Doorvoer is uw effectieve snelheid: hoeveel gegevens u per seconde verzendt of ontvangt.
• RTT (Round-Trip Time) is de vertraging tussen het verzenden en ontvangen van pakketten.

Een praktijkvoorbeeld van een GL.iNet-subredditlid

Stel dat u in Vietnam met uw WireGuard-VPN-server thuis in Texas verbindt, die op een GL.iNet Flint 2 draait.

• Serverlocatie: Texas, VS
  
  • Lokale snelheden (symmetrische glasvezel) 700 Mbps download / 940 Mbps upload
• Clientlocatie: Vietnam
  
  • Lokale snelheden (zonder VPN): 455 Mbps download / 634 Mbps upload
    
  • Lokale snelheden (met WireGuard-VPN-client): 47.3 Mbps download / 12.1 Mbps upload, 288 ms ping

Laten we eerst enkele algemene beperkingen bekijken:

1. Variatie in providerprestaties en congestie in uw buurt: snelheden kunnen met 100'en Mbps variëren
2. Wi-Fi-prestaties: sterk wisselend, afhankelijk van de fysieke omgeving, interferentie van andere draadloze apparaten, de mogelijkheden van het clientapparaat en het inherente halfduplexkarakter van Wi-Fi (in tegenstelling tot full-duplex ethernet)
   • Lees hier een uitgebreide uitleg over realistische Wi-Fi-prestaties: https://www.wiisfi.com/ De 1e beperking ligt buiten uw controle. De 2e grotendeels ook, behalve dat u deze mogelijk wegneemt door waar mogelijk bekabeld Ethernet te gebruiken.

Het bandbreedte-vertragingsproduct

De VPN-snelheid aan de clientkant lijkt misschien teleurstellend, maar is gezien de latentie eigenlijk goed. Dat volgt uit de eerdere formule:
TCP-venstergrootte = 47.3 Mbps x 0.288 seconden
　 　 　 　    = 13.6 Mb, of ~1.7 MB

Een TCP-venster van 1.7 MB is behoorlijk groot. Dat halen over een verbinding met 288 ms latentie betekent dat TCP redelijk presteert. Maar hoe kan dat als het oorspronkelijke TCP-vensterveld maar 65,535 bytes, ongeveer 64 KB, toelaat?

TCP Window Scaling voor betere prestaties

Het antwoord is TCP Window Scaling, ontwikkeld voor moderne netwerken met hoge bandbreedte en latentie. Zoals Microsoft in dit artikel beschrijft, is het vensterveld 16 bits, waardoor het zonder schaling maximaal 65,535 bytes bevat. RFC 7323 introduceerde daarom de schaaloptie, waarmee het venster tot 14 bits naar links kan worden verschoven en maximaal 1 GB wordt. De schaalfactor wordt tijdens de TCP three-way handshake afgesproken. Daarna vermenigvuldigen eindpunten het oorspronkelijke venster. Congestiealgoritmen op het clientbesturingssysteem bepalen voortdurend de juiste schaling. In sommige gevallen, zoals Microsoft Windows, maximaliseert automatische vensteraanpassing de downloaddoorvoer bijzonder slecht.

Voorbeeld van een door het besturingssysteem afgesproken TCP-venster en de invloed van latentie op doorvoer Bron: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Waarom u het TCP-venster niet onbeperkt vergroot

De TCP-venstergrootte hangt af van beschikbare bandbreedte en retourtijd. Meer doorvoer krijgen is echter niet zo eenvoudig als het venster vergroten. Vanaf een bepaald punt vragen grotere vensters meer geheugen en rekenkracht bij verzender en ontvanger, wat apparaten en netwerken kan overbelasten en pakketverlies en prestatieverlies kan geven.

In dit scenario is een venster van ongeveer 1.7 MB dus normaal en past het bij een goed presterende verbinding met hoge latentie. De algemene bovengrens van ongeveer 2 MB kan voor veel moderne systemen als praktische bovengrens dienen, waarbij doorvoer en gebruik van middelen in balans blijven. Met een venster van 2 MB en 288 ms latentie zou de maximale theoretische doorvoer ongeveer 55.5 Mbps zijn. Dat verklaart waarom hogere snelheden moeilijk te behalen zijn, ondanks veel snellere gewone internetverbindingen aan beide kanten (server en client). Als we de variabelen in de eerdere formule herschikken om de doorvoer te berekenen, zien we dat we met 80 ms latentie en een venstergrootte van 2 MB theoretisch ongeveer 200 Mbps zouden kunnen halen. Helaas verhinderen de natuurwetten dat we die latentie bereiken vanwege de fysieke afstand (Texas <-> Vietnam).

Conclusie

Hopelijk heeft dit artikel u een uitleg gegeven waarmee u de volgende keer dat u uw WireGuard VPN in het buitenland gebruikt realistischere verwachtingen hebt van de download- en uploadsnelheden. Vergeet tot slot niet dat routers veel TCP-sessies tegelijk afhandelen. Hoewel de geliefde GL.iNet Flint 2 een royale 1 GB DDR4 RAM heeft, kan de clientrouter die met die Flint 2 is verbonden veel minder RAM hebben en daardoor de beperkende factor vormen bij het schalen van de TCP-venstergrootte.

Voor meer informatie en tips over WireGuard-probleemoplossing raadpleegt u dit GL.iNet-forumbericht: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Maak kennis met GL.iNet-thuisrouters