Warum WireGuard-VPN-Geschwindigkeiten bei hoher Latenz sinken

Einleitung

Viele Nutzer sind überrascht, wenn sie aus einem anderen Land eine Verbindung zum WireGuard- Server ihres GL.iNet-Routers her und stellen fest, dass die Internetgeschwindigkeit deutlich unter der symmetrischen Gigabit-Geschwindigkeit zu Hause oder ähnlich schnellem Internet an ihrem ausländischen Aufenthaltsort (z. B. Airbnb) liegt. Häufig ist der Internetanbieter am Server- oder Client-Ende dafür verantwortlich. Latenz wird jedoch oft übersehen, obwohl sie sich sehr real und deutlich auf den Durchsatz, also die Download-/Upload-Geschwindigkeit, auswirkt. Dieser Beitrag soll realistische Erwartungen vermitteln und erklären, warum die Geschwindigkeit bei hoher Latenz (d. h. hohen Ping-Werten) sinkt.

Was ist Latenz und warum ist sie wichtig?

Latenz ist die Zeit, die Daten benötigen, um von Ihrem Gerät zum VPN-Server und zurück zu gelangen. Sie wird häufig in Millisekunden (ms) gemessen. Wenn sich Ihr GL.iNet-Router beispielsweise in Vietnam mit einem VPN-Server in Texas verbindet, kann die Round-Trip-Time (RTT) leicht 250-300 ms betragen.

Selbst wenn Ihre Internetgeschwindigkeit technisch gesehen „schnell“ ist, kann hohe Latenz die tatsächliche Download- und Upload-Leistung stark begrenzen, insbesondere bei TCP-basierten Protokollen (z. B. HTTPS, Dateiübertragungen oder den meisten Apps). Obwohl WireGuard selbst UDP verwendet, basiert der durch den VPN-Tunnel laufende Datenverkehr (Webdaten, Streaming usw.) häufig auf TCP. Diese TCP-Daten werden von WireGuard in UDP gekapselt und über das Internet übertragen.

Der TCP-Engpass: Der Durchsatz hängt von der Latenz ab

Dies ist die maßgebliche Formel für die TCP-Leistung:

TCP Window Size = Throughput x RTT
Zunächst einige Definitionen:

• TCP-Fenstergröße ist die Datenmenge, die Ihr System ohne Bestätigung „unterwegs“ sein lässt, bevor eine Bestätigung erforderlich ist.
• Durchsatz ist Ihre effektive Geschwindigkeit bzw. die Datenmenge, die Sie pro Sekunde senden oder empfangen können.
• RTT (Round-Trip-Time) ist die Verzögerung zwischen dem Senden und Empfangen von Paketen.

Ein konkretes Beispiel eines GL.iNet-Subreddit-Mitglieds

Angenommen, Sie befinden sich in Vietnam und verbinden sich mit Ihrem WireGuard- VPN-Server zu Hause in Texas, der auf einem GL.iNet Flint 2 läuft.

• Serverstandort: Texas, USA
  
  • Lokale Geschwindigkeiten (symmetrische Glasfaser): 700 Mbit/s Download / 940 Mbit/s Upload
• Clientstandort: Vietnam
  
  • Lokale Geschwindigkeiten (ohne VPN): 455 Mbit/s Download / 634 Mbit/s Upload
    
  • Lokale Geschwindigkeiten (mit aktiviertem WireGuard-VPN-Client): 47.3 Mbit/s Download / 12.1 Mbit/s Upload, 288 ms Ping

Sehen wir uns zunächst einige häufige Einschränkungen jeder Netzwerkverbindung an:

1. Schwankende ISP-Leistung und Überlastung in Ihrer Nachbarschaft: Die Geschwindigkeit kann um bis zu Hunderte Mbit/s schwanken.
2. Wi-Fi-Leistung: Sie hängt stark von der physischen Umgebung, Störungen durch andere drahtlose Geräte, den Fähigkeiten des Clientgeräts und der inhärenten Halbduplex-Natur von Wi-Fi (im Gegensatz zu Vollduplex-Ethernet) ab.
   • Eine ausführliche Erklärung zur realistischen Wi-Fi-Leistung finden Sie hier: https://www.wiisfi.com/ Die erste Einschränkung können Sie nicht beeinflussen. Auch die zweite liegt größtenteils außerhalb Ihrer Kontrolle, lässt sich aber möglicherweise durch kabelgebundene Ethernet-Verbindungen vermeiden.

Das Bandbreiten-Verzögerungs-Produkt

Auf den ersten Blick mögen die VPN-Geschwindigkeitstests auf der Clientseite enttäuschend wirken. Angesichts der vorhandenen Latenz sind sie in Wirklichkeit jedoch ziemlich gut. Das zeigt die bereits verwendete Formel:
TCP-Fenstergröße = 47.3 Mbit/s x 0.288 seconds
　 　 　 　    = 13.6 Mb, or ~1.7 MB

Eine TCP-Fenstergröße von 1.7 MB ist tatsächlich recht groß. Dass dieser Wert über eine Verbindung mit 288 ms Latenz erreicht wird, zeigt, dass TCP recht gut arbeitet. Doch wie ist das möglich, wenn das ursprüngliche Feld für die TCP- Fenstergröße auf nur 65,535 Byte (etwa 64 KB) begrenzt ist?

TCP Window Scaling für bessere Leistung

Die Antwort ist eine Funktion namens TCP Window Scaling, die zur Unterstützung moderner Netzwerke mit hoher Bandbreite und hoher Latenz eingeführt wurde. Wie Microsoft in diesem Artikel beschreibt, ist das Feld für die TCP-Fenstergröße nur 16 Bit groß und begrenzt das nicht skalierte Fenster auf 65,535 Byte. Um dieses Problem zu lösen, wurde mit RFC 7323 die TCP-Window-Scale-Option eingeführt. Sie erlaubt eine Verschiebung der Fenstergröße um bis zu 14 Bit nach links und erhöht die maximale Fenstergröße effektiv auf 1 GB. Der Skalierungsfaktor wird während des TCP-Drei-Wege-Handshakes ausgehandelt. Nach der Aktivierung können Endpunkte die ursprüngliche Fenstergröße multiplizieren. Algorithmen zur Überlastungssteuerung in den Betriebssystemen der Clientgeräte bestimmen laufend die passende Skalierung. In manchen Fällen, etwa unter Microsoft Windows, maximiert die automatische Fensteranpassung („Auto-Tuning“) den Download-Durchsatz besonders schlecht.

Beispiel für die Auswirkung der vom Betriebssystem ausgehandelten TCP-Fenstergröße und Latenz auf den Durchsatz Source: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Warum Sie die TCP-Fenstergröße nicht einfach immer weiter erhöhen können

Letztlich hängt die TCP-Fenstergröße von der verfügbaren Bandbreite und der Round-Trip-Time ab. Es ist jedoch nicht so einfach, die Fenstergröße für mehr Durchsatz immer weiter zu erhöhen. Ab einem bestimmten Punkt benötigen größere Fenster auf Sender- und Empfängerseite mehr Speicher und Rechenleistung. Das kann Geräte und Netzwerke überlasten und zu mehr Paketverlusten und geringerer Leistung führen.

Daher ist im vorherigen Szenario eine TCP-Fenstergröße von etwa 1.7 MB angesichts der hohen Latenz völlig normal und ein Zeichen für eine leistungsfähige Verbindung. Die allgemeine Obergrenze von etwa 2 MB kann für viele moderne Systeme als praktische Grenze dienen, die Durchsatz und Ressourcenverbrauch ausbalanciert. Bei einem 2-MB-Fenster und 288 ms Latenz läge der maximal mögliche theoretische Durchsatz bei ungefähr 55.5 Mbit/s. Das erklärt, warum höhere Werte trotz deutlich schnellerer Internetverbindungen an beiden Enden (Server und Client) schwer zu erreichen sind. Wenn wir die Variablen der vorherigen Gleichung nach dem Durchsatz umstellen, sehen wir, dass bei 80 ms Latenz und einer Fenstergröße von 2 MB theoretisch etwa 200 Mbit/s möglich wären. Die Gesetze der Physik hindern uns jedoch aufgrund der räumlichen Entfernung (Texas <-> Vietnam) daran, diese Latenz zu erreichen.

Fazit

Hoffentlich hilft Ihnen dieser Artikel dabei, bei der nächsten Nutzung Ihres WireGuard-VPNs im Ausland realistischere Erwartungen an die Download-/Upload- Geschwindigkeiten zu haben. Denken Sie zuletzt daran, dass Router viele gleichzeitige TCP-Sitzungen verarbeiten. Der beliebte GL.iNet Flint 2 verfügt zwar über großzügige 1 GB DDR4-RAM, doch der Client-Router, der mit diesem Flint 2 verbunden ist, hat möglicherweise deutlich weniger RAM und kann dadurch der begrenzende Faktor für die Skalierung der TCP-Fenstergröße sein.

Weitere Informationen und Tipps zur Fehlerbehebung und zum Verständnis Ihrer WireGuard-VPN-Konfiguration finden Sie im folgenden GL.iNet-Forenbeitrag: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

GL.iNet-Heimrouter im Überblick