Warum ein VPN-Download Ihre Direktverbindung schlagen kann

Eine Übertragung, die durch den Tunnel schneller wird, deutet meist auf eine Grenze an einem Port hin. Drei kontrollierte Vergleiche trennen einen Shaper von einer echten Beschleunigung.

Verbinden Sie den Tunnel, starten Sie einen großen Download, und er läuft mit ungefähr der doppelten Geschwindigkeit, die dieselbe Datei ohne ihn erreichte. Das klingt nach Werbung, kann aber eine echte Messung auf einem Privatanschluss sein. Die übliche Ursache ist eine Ratenbegrenzung, die an einem Port hängt: Der Tunnel trägt Ihre Übertragung dorthin, wo der Shaper nicht hinsieht, und die tatsächliche Kapazität der Leitung zeigt sich zum ersten Mal.

Die interessante Zahl ist also nicht, wie schnell das VPN war. Sondern wie viel Ihrer Leitung Sie nie bekommen haben, und warum.

Eine Grenze, die dem Port folgt, nicht der Route

Ein Zugangsanbieter kann den Durchsatz pro Teilnehmer nach Protokoll oder Zielport begrenzen, und Port 80 ist ein beliebtes Ziel, weil so viel gewöhnliches Surfen ihn nutzt. Die Grenze wird oft nicht ab dem ersten Paket angewandt: Die Übertragung beginnt nahe der Leitungsrate, verbraucht ein Burst-Kontingent und pendelt sich dann auf dem begrenzten Wert ein. Die ersten Sekunden sehen gesund aus, der Rest der Übertragung nicht.

Schicken Sie dieselben Bytes über einen anderen Port, und der Shaper auf 80 sieht sie nie. Der Tunnel scheint die Direktverbindung zu schlagen, obwohl er einen Hop, Verschlüsselung und eigenen Overhead hinzugefügt hat. Verbessert hat sich nicht der Pfad, sondern das Fehlen einer Regel.

Deshalb ist der Effekt über Dateien und Ziele hinweg so gleichförmig. Liegt die Grenze am Port, verhält sich alles, was über diesen Port läuft, gleich, egal wie groß die Datei und wer der Host ist. Ein Ziel, das eine andere Regel anzieht, zeigt eine andere Kurve, und dieser Unterschied ist für sich genommen diagnostisch.

Messen Sie das Plateau, nicht die Spitze

Eine Spitze ist der am wenigsten aussagekräftige Teil einer Übertragung, denn jede Verbindung sieht gut aus, solange ihre Puffer sich füllen. Notieren Sie, wo die Rate zur Ruhe kommt und wie lange sie dort bleibt.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Führen Sie das Paar direkt hintereinander auf derselben Maschine aus, zur selben Stunde, gegen Hosts in vergleichbaren Netzen. Eine einzelne Stichprobe beweist nichts; die Form der Kurve über je zwei Läufe ist es, die ein Burst-Kontingent von einer stabilen Grenze unterscheidet. Schreiben Sie auf, wo die Rate abflacht, statt was die erste Sekunde zeigte, denn der Burst ist genau das, was ein Shaper Ihnen gibt, bevor er zu begrenzen beginnt. Ein ruhiges Plateau, das den Rest der Übertragung hält, ist die Zahl zum Vergleichen.

Halten Sie die Datei bereits komprimiert, damit Transportkomprimierung nicht als Erklärung angeboten werden kann. Ein PDF oder ein Archiv entfernt diese Variable und verhindert außerdem, dass jemand argumentiert, der Tunnel habe die Nutzlast gestaucht. Wenn beide Übertragungen dieselbe Datei nutzen, ist der einzige verbleibende Unterschied der Pfad und der Port. Notieren Sie Werkzeug und Port neben jedem Wert, sonst ist der zweite Lauf nicht mit dem ersten vergleichbar.

Drei Vergleiche, die die Ursache isolieren

Arbeiten Sie sie der Reihe nach ab und hören Sie auf, sobald das Muster klar ist, denn jeder schließt eine andere Geschichte aus.

  1. Wiederholen Sie denselben Download über den gewöhnlichen Webpfad und über ein Übertragungswerkzeug auf einem anderen Port, von einem Host mit vergleichbarer Kapazität.
  2. Wiederholen Sie beides mit einer inkompressiblen Datei, damit Komprimierung als Kandidat ausscheidet.
  3. Wenn Sie den Tunnel-Server selbst betreiben, binden Sie ihn erneut an Port 80, passen Sie das Client-Profil an, damit beide Enden übereinstimmen, und übertragen Sie erneut. Sitzt der Tunnel jetzt auf der begrenzten Web-Rate, folgt die Beschränkung dem Port und nicht dem VPN.

Der dritte Schritt ist der entscheidende, und er ist auch der, den Leute überspringen, weil er eine Konfigurationsänderung erfordert. Ohne ihn haben Sie gezeigt, dass sich zwei Dinge unterscheiden, nicht dass der Port der Grund ist.

Was diese Messung nicht stützen kann

Sie zeigt nicht, dass der Tunnel generell schneller ist, dass er irgendetwas komprimiert oder dass andere Ports der Leitung unbeschränkt sind. Sie beschreibt diese Übertragung, auf dieser Leitung, zu dieser Stunde. Grenzen können pro Sitzung, pro Teilnehmer oder nach Tageszeit gelten, und sie können sich ohne Ankündigung ändern.

Sie beweist auch nicht, dass der direkte Pfad defekt ist. Ein begrenzter Pfad funktioniert weiterhin; er ist absichtlich begrenzt, und eine bewusste Richtlinie ist kein Fehler, der auf eine Reparatur wartet.

Und sie rechtfertigt gewiss nicht, alles durch den Tunnel zu leiten. Jede Anwendung auf Port 80 bleibt begrenzt, während alles, was Sie umleiten, nun von einem zusätzlichen Hop und einem zusätzlichen Fehlermodus abhängt.

Machen Sie aus dem Befund etwas Umsetzbares

Schreiben Sie die Beobachtung als Messung statt als Urteil: Große Übertragungen über Port 80 pendeln sich nahe der Hälfte der Rate ein, die dieselbe Datei auf einem anderen Port erreicht, zu diesen Stunden, auf dieser Leitung, mit diesen Stichproben im Anhang. Das ist eine Supportanfrage, die jemand untersuchen kann.

„Das VPN ist schneller“ ist es nicht. Es lädt zu einer Antwort über Verschlüsselungs-Overhead ein, und diese Antwort ist technisch korrekt, während sie niemandem etwas Nützliches sagt. Legen Sie Stichprobenzahl, Stunde und Port bei, damit der Leser das Muster nachvollziehen kann.

Wenn Sie sich entscheiden, weiterhin einen anderen Port für Massenübertragungen zu nutzen, notieren Sie den Vorbehalt in Ihren eigenen Aufzeichnungen: Einen Listener auf Port 80 zu verschieben kollidiert mit jedem Webserver, der dort bereits gebunden ist, und der resultierende Fehler sieht wie ein defekter Tunnel aus, nicht wie ein Portkonflikt.

Ähnliche Artikel