Warum ein Download über das VPN schneller ist als direkt

Sie starten einen großen Download, die ersten Sekunden sehen normal aus, und dann pendelt sich die Rate bei etwa der Hälfte dessen ein, was die Leitung liefern sollte. Sie verbinden den Tunnel, wiederholen denselben Download, und er hält über die ganze Datei eine höhere Rate. Das ist eine echte Messung und zugleich ein irreführender Schluss, denn der Tunnel hat den Pfad nicht schneller gemacht. Er hat Ihren Datenverkehr von einem Port wegbewegt, den etwas auf dem Weg begrenzte.

Die Form der Kurve verrät es

Beobachten Sie die Übertragung statt der Endzahl. Ein gedrosselter Pfad beginnt meist nahe der Leitungsrate, verbraucht sein Burst-Kontingent und pendelt sich dann am Limit ein, sodass der Durchschnitt davon abhängt, wie lange Sie zugesehen haben. Ein Tunnel, der den Pfad wirklich verbessert hätte, würde ab der ersten Sekunde eine bessere Rate zeigen und sie halten. Das Plateau ist der Fingerabdruck, und man übersieht es leicht, wenn man nur die Spitze notiert.

Zwei Läufe derselben Datei, einer direkt und einer durch den Tunnel, genügen, um zu sehen, ob es ein Plateau gibt.

Notieren Sie, wann das Plateau beginnt, wie lange es dauert und welche Rate es hält. Diese drei Werte unterscheiden einen Shaper von einem überlasteten Pfad, denn Überlastung lässt die Rate wandern, während ein Shaper sie auf eine Zahl festnagelt. Wenn der direkte Lauf allmählich nachlässt und der Tunnellauf stabil bleibt, sehen Sie Politik und nicht Physik.

Drei Vergleiche, je eine Variable

Ändern Sie pro Lauf eine Sache, sonst lernen Sie nichts. Holen Sie dieselbe Datei über den gewöhnlichen Webpfad, dann über ein Übertragungswerkzeug, das einen anderen Port nutzt, von einem Host mit vergleichbarer Kapazität und zur selben Stunde. Halten Sie den Client-Rechner fest, denn ein Laptop, der zwischen Netzen wechselt, bringt eine Variable ins Spiel, die Sie nicht kontrollieren können.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Verwenden Sie eine bereits komprimierte Datei, etwa ein Datenträgerabbild, damit Transportkompression den Unterschied nicht erklären kann. Wenn Sie den Server kontrollieren, verschieben Sie dann seinen Listener auf den Port, den Sie im Verdacht haben, aktualisieren Sie das Client-Profil und wiederholen Sie den Lauf. Sollte der Tunnel nun auf die gedrosselte Rate fallen, folgt die Grenze dem Port und nicht dem Tunnel, und die Frage ist geklärt. Führen Sie jeden Vergleich zweimal aus und behalten Sie die Plateauwerte, nicht die Spitzen.

Notieren Sie auch die Stunde, denn ein Shaper kann zeitbasiert sein, und ein Abendtest kann einem Morgentest widersprechen. Zwei Läufe zur selben Stunde sind mehr wert als zehn über den Tag verteilte.

Was diese Messung nicht stützen kann

Sie zeigt nicht, dass der Tunnel generell schneller ist, dass er irgendetwas komprimiert oder dass andere Ports ungedrosselt sind. Sie beschreibt eine Übertragung auf einer Leitung während einer Stunde. Grenzen können pro Sitzung, pro Teilnehmer oder zeitbasiert sein, und ein Betreiber kann sie ändern, ohne es anzukündigen.

Sie zeigt auch nicht, dass der direkte Pfad fehlerhaft ist. Ein gedrosselter Pfad funktioniert genau wie vorgesehen, er ist lediglich durch Politik begrenzt.

Dieser Unterschied zählt, wenn Sie es aufschreiben. Ein Fehler lädt zu einem Reparaturticket ein, eine Politik dagegen zu einer Frage zum Vertrag oder zu der Entscheidung, sie zu umgehen. Eine Drosselung als Fehler zu bezeichnen erzeugt ein Supportgespräch, das von der falschen Prämisse ausgeht. Sie als Politik zu bezeichnen erlaubt eine konkrete Frage, die eine konkrete Antwort hat.

Machen Sie aus dem Befund eine Supportanfrage

Verwenden Sie die Zahlen und lassen Sie die Schlussfolgerung weg. Eine Anfrage, die besagt, dass große Übertragungen über Port 80 in diesen Stunden bei etwa der Hälfte der erwarteten Rate bleiben, mit den Plateauwerten im Anhang, ist umsetzbar. Eine Anfrage, die sagt, das VPN sei schneller, ist es nicht, weil sie als Behauptung über den Tunnel statt als Beobachtung über die Leitung gelesen wird. Fügen Sie beide Läufe und ihre Zeitstempel bei und lassen Sie dann den Betreiber die Politik beschreiben.

Schieben Sie nicht jede Anwendung in den Tunnel, nur um dieser Zahl nachzujagen.

Der Tunnel kostet Sie weiterhin einen zusätzlichen Hop, Verschlüsselung und einen neuen Satz Fehlermodi, während der begrenzte Port für alles andere, was ihn nutzt, begrenzt bleibt. Wenn große Übertragungen zuverlässig fertig werden müssen, notieren Sie selbst, welcher Port die Grenze trägt. Einen Listener auf Port 80 zu verschieben kollidiert außerdem mit jedem Webserver, der bereits daran gebunden ist, und das erzeugt einen neuen Ausfall statt einer Lösung.