Welche Warnzeichen deuten darauf hin, dass ein Tunnel-Relay den Durchsatz begrenzt?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

What Are the Warning Signs That a Tunnel Relay Is Limiting Throughput? - Zima Store Online

Ein Relay begrenzt wahrscheinlich den Durchsatz, wenn die Verbindung über ein Relay läuft und sich bei einem direkten oder näheren Pfad deutlich verbessert, während beide Endpunkte unterausgelastet bleiben.

Overlay-VPNs und ausgehende Tunnel fallen oft auf ein gemeinsames oder selbst gehostetes Relay zurück, wenn NAT-Traversal keinen Peer-to-Peer-Pfad herstellen kann. Das Relay kann die Konnektivität erhalten, fügt jedoch eine weitere Netzwerketappe, Warteschlange, TCP- oder TLS-Schicht, geografische Umleitung, Fairness-Begrenzung und einen Verarbeitungspunkt hinzu. Eine zuverlässige Diagnose vergleicht Relay-Status, Latenz, Jitter, Richtung, CPU der Endpunkte und eine Direktpfad-Kontrolle, anstatt Verschlüsselung oder das NAS für eine langsame Dateiübertragung verantwortlich zu machen.

Bestätigen, dass der Datenpfad tatsächlich über ein Relay läuft

Überprüfen Sie den Peer-Status des Tunnel-Clients während aktiven Datenverkehrs. Notieren Sie, ob der Pfad direkt, über ein Relay, proxybasiert oder im Wechsel zwischen Modi ist, sowie die ausgewählte Relay-Region oder den Host.

Ein Tailscale-Problem dokumentiert, dass Mobilfunk-Clients auf DERP verbleiben mit Latenzen von 200 bis 900 Millisekunden. Ein verbundener Status beweist daher Erreichbarkeit, nicht aber einen effizienten Datenpfad.

Wenn der Client während des langsamen Tests durchgehend direkte Konnektivität meldet, sollte das Relay nicht als Ursache bezeichnet werden. Fahren Sie mit Tests zu CPU der Endpunkte, Tunnel-Offloads, MTU, ISP-Upload, WLAN und Speicher fort.

Vergleichen Sie Relay- und Direktpfade mit denselben Endpunkten

Führen Sie einen reinen Netzwerk-Durchsatztest zwischen demselben Client und Heimserver durch, während die Verbindung über ein Relay läuft, und wiederholen Sie ihn nach Herstellung eines direkten Peer-Pfads oder eines temporären port-erreichbaren Testnetzwerks. Protokoll, Richtung und Endgeräte-Hardware sollten unverändert bleiben.

Ein veröffentlichter Peer-Relay-Fall zeigte sowohl eine große Latenzreduzierung als auch eine 12,5-fache Steigerung des Durchsatzes nach nur einer Änderung der Relay-Topologie.

Eine große und wiederholbare Verbesserung nach Entfernung oder Verlagerung des Relays ist ein starkes Indiz. Eine kleine Veränderung bedeutet, dass das Relay möglicherweise nicht der dominierende Engpass ist, besonders wenn der Upload zu Hause oder das entfernte WLAN bereits eine niedrigere Grenze setzt.

Achten Sie auf hohe Latenz, Jitter und geografische Umwege

Messen Sie minimale, mittlere und hohe Perzentil-Latenz zum Peer und zur Relay-Region. Notieren Sie Jitter und Paketverlust während Leerlaufphasen und bei anhaltender Übertragung.

Ein unabhängiger Diagnosebericht erfasste einen Relay-Pfad mit durchschnittlicher Latenz über 400 ms, erheblichem Jitter und messbarem Paketverlust – eine Kombination, die TCP-Dateiübertragungen und interaktiven Zugriff zum Zusammenbruch bringen kann, selbst wenn der Tunnel bestehen bleibt.

Wenn das Relay geografisch weit von beiden Endpunkten entfernt ist oder die Latenz unter Last stark schwankt, testen Sie eine näher gelegene Region, ein selbst gehostetes Relay oder ein Peer-Relay. Stabile niedrige Relay-Latenz bei schlechtem Durchsatz deutet eher auf Kapazität, Fairness, CPU oder Transportverhalten hin.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Prüfen Sie, ob das Relay eine konstante Durchsatzgrenze hat

Führen Sie mehrere große Übertragungen zu unterschiedlichen Zeiten und in beide Richtungen durch. Eine Relay-Grenze zeigt sich oft als stabiles Plateau, das nicht ansteigt, wenn die Internetgeschwindigkeit der Endpunkte, NAS-Speicher oder das WLAN des Clients verbessert werden.

Benchmark-Arbeiten zu Relay-Implementierungen zeigen, dass Weiterleitungskapazität, CPU-Effizienz und gleichzeitige Last den Tunnel-Durchsatz maßgeblich beeinflussen. Ein aktuelles DERP-kompatibles Projekt veröffentlicht Multi-Load-Relay-Benchmarks über CPU-Größen und Verkehrslevel.

Wenn ein Stream ein Plateau erreicht, fügen Sie einen zweiten kontrollierten Stream hinzu und beobachten Sie den Gesamtdurchsatz. Eine feste gemeinsame Grenze deutet auf Relay- oder Pfadkapazität hin; unveränderter niedriger Durchsatz bei Leerlauf-CPU des Relays spricht für RTT, Paketverlust, Staukontrolle oder Endpunktbeschränkungen.

Trennen Sie Relay-Grenzen von CPU der Endpunkte und ISP-Upload

Überwachen Sie CPU, Soft-Interrupts, Verschlüsselungsprozesse, NIC-Auslastung und Festplattenaktivität an beiden Endpunkten und dem selbst gehosteten Relay. Vergleichen Sie die langsame Richtung mit der gemessenen Upload- und Download-Kapazität der Heimverbindung.

Ein Relay kann nur so schnell weiterleiten wie seine langsamste eingehende oder ausgehende Verbindung. Das Relay auf einem Low-Tier-VPS, in einer entfernten Region, einem eingeschränkten Container oder einem geteilten Heim-Uplink zu betreiben, kann dieselben Symptome wie eine Managed-Relay-Begrenzung verursachen.

Erreicht die CPU des Endpunkts oder Relays die Auslastungsgrenze, optimieren oder tauschen Sie diesen Knoten aus, bevor Sie die Relay-Geografie ändern. Ist die CPU niedrig, aber eine ISP-Richtung voll ausgelastet, zeigt das Relay die Zugangslink-Grenze an, erzeugt sie aber nicht.

Ändern Sie das Relay-Design an der Stop-Grenze

Ersetzen Sie den Relay-Pfad, wenn er für normalen Verkehr ausgewählt bleibt, unakzeptable Latenz oder Jitter verursacht, den anhaltenden Durchsatz unter die Arbeitslastanforderung begrenzt und ein direkter oder näherer Relay-Kontrollpfad beweist, dass der Rest des Pfads besser performen kann.

Der ZimaSpace-Leitfaden zu CGNAT-Remote-Access-Alternativen erklärt, warum ein Relay notwendig sein kann, auch wenn es nicht der schnellste Pfad ist.

Wählen Sie ein näheres Peer-Relay, besser positionierten VPS, verbesserte NAT-Traversal oder einen Workflow mit geringerem Bandbreitenbedarf, anstatt den einzigen erreichbaren Pfad ohne Ersatz zu deaktivieren. Validieren Sie das neue Design mit der ursprünglichen Remote-Datei-, Medien- oder Synchronisationsarbeitslast, nicht nur mit einem kurzen Ping.