Warum zwei VPN-Geschwindigkeitstests im selben Tunnel nicht übereinstimmen

Zwei Läufe, ein Tunnel, und die Zahlen unterscheiden sich um den Faktor drei. Der Tunnel hat sich zwischen ihnen nicht geändert. Geändert hat sich die Messung: eine Testseite, die einen Server anhand deines scheinbaren Standorts wählt, eine Streamanzahl, die entscheidet, ob ein langsamer Start oder sechs die Leitung füllen, und eine Dauer, die kurz genug ist, um zu enden, bevor der Pfad überhaupt richtig genutzt wird. Geschwindigkeitstests sind nicht falsch, aber sie beantworten eine engere Frage als die, die man ihnen stellt.

Eine neue Ausgangsadresse ändert das Testziel

Die meisten Testseiten wählen einen Messserver automatisch, und sie wählen ihn teilweise danach, woher deine Verbindung scheinbar kommt. Schalte den Tunnel ein, und dein scheinbares Land ändert sich, also ändert sich der gewählte Server, und der Vergleich umfasst nun zwei verschiedene Routen zu zwei verschiedenen Hosts.

Das Ergebnis ist überhaupt keine VPN-Messung. Es ist eine Messung deines Pfads zu einem Server, den du nicht gewählt hast, und der Unterschied zwischen den beiden Läufen kann vom Peering dieses Servers bestimmt werden statt von allem, was der Tunnel getan hat.

Fixiere das Ziel, bevor du irgendetwas anderes änderst. Jedes seriöse Werkzeug lässt dich einen Server ausdrücklich wählen, und wenn nicht, nennt die Ergebnisseite meist den verwendeten, was genügt, um zu bemerken, dass die beiden Läufe nicht vergleichbar sind. Bestätige, was die Seite gesehen hat, bevor du ihrer Wahl vertraust:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Hat sich das Land zwischen den Läufen geändert, hat sich auch alles geändert, was der Test danach gewählt hat. Schreib den beobachteten Ausgang neben jedes Ergebnis, und die Verwirrung verschwindet weitgehend.

Langsamer Start endet erst nach dem Ende der meisten kurzen Tests

Eine TCP-Verbindung beginnt nicht mit der Leitungsrate. Sie beginnt mit einem kleinen Überlastfenster, verdoppelt es etwa pro Roundtrip und erreicht die Kapazität des Pfads erst nach mehreren Roundtrips. Ein Test von zehn Sekunden auf einem Pfad mit hoher Latenz kann einen erheblichen Teil seiner Laufzeit in diesem Anlauf verbringen.

Deshalb schneidet ein Tunnel mit höherer Latenz in einem kurzen Test schlechter ab, als er verdient, und deshalb meldet ein längerer Lauf oft eine höhere Zahl ohne jede Konfigurationsänderung. Das Durchsatzrahmenwerk RFC 6349 behandelt dies ausdrücklich, und deshalb laufen ernsthafte Messungen lange genug, um einen stationären Zustand zu erreichen. Ein Lauf von fünf Sekunden auf einem Satellitenpfad misst den Beschleuniger, nicht die Straße.

Sieh dir die Verbindungsphasen an, statt einer einzigen Zahl zu vertrauen. Curl meldet jede Phase getrennt, sodass du siehst, ob Zeit in den Handshake, den Anlauf oder die Übertragung geht:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Lass es zweimal hintereinander auf dasselbe Ziel laufen. Ist der zweite Lauf viel schneller, hast du den Anlauf gemessen, nicht den Pfad, und jeder Vergleich, der nur den ersten Lauf nutzte, ist verdächtig.

Ein Stream und sechs Streams messen verschiedene Dinge

Ein einzelner TCP-Stream ist durch das Fenster begrenzt, das er in Flug halten kann, also grob die Roundtrip-Zeit multipliziert mit der Rate. Auf einem langen Pfad übersteigt dieses Produkt, was ein Stream nutzen wird, sodass ein einzelner Download die vorhandene Kapazität unterschätzt. Sechs parallele Streams füllen die Lücke und ergeben eine größere Zahl.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Beide Zahlen sind wahr. Die Einzelstream-Zahl sagt, was ein Download leisten wird, was ein Browsertab normalerweise bekommt. Die parallele Zahl sagt, was der Pfad insgesamt tragen kann, was ein Torrent oder ein mehrteiliger Download nutzen kann. Eine davon zu zitieren, als wäre sie die andere, ist der Weg, auf dem ein gesunder Tunnel ohne Grund ersetzt wird.

Ein paralleles Ergebnis mit einem Einzelstream-Ergebnis zu vergleichen, ist der häufigste Weg, auf dem Leute folgern, ein VPN habe ihre Geschwindigkeit halbiert. Gleiche die Methode an, dann vergleiche. Die Spur im dritten Befehl ergänzt den fehlenden Kontext: Ein Pfad mit hohem Jitter liefert in beiden Modi inkonsistente Ergebnisse, und keine Streamanzahl behebt das.

Verschlüsselung kostet Prozessorzeit, Kapselung kostet Bytes

Auf jedem Paket laufen zwei Mechanismen, egal wie schnell die Leitung ist. Verschlüsselung verbraucht CPU pro Byte, und Kapselung fügt Header-Bytes hinzu, die die Leitung trotzdem tragen muss. Beide zeigen sich als Obergrenze, und sie haben verschiedene Symptome.

Die Prozessorgrenze zeigt sich als Plateau: Der Durchsatz steigt nicht mehr, egal wie viele Streams du hinzufügst, und der Prozessor der Maschine ist beschäftigt, während die Leitung es nicht ist. Auf einem kleinen Router oder einem Telefon ist das oft die echte Grenze, und deshalb kann eine schnelle Leitung immer noch einen bescheidenen Tunnel liefern.

Die Byte-Kosten sind kleiner, aber konstant. Zusätzliche Header bedeuten weniger Nutzlast pro Paket, und auf einem Pfad mit fester maximaler Übertragungseinheit können sie auch Fragmentierung oder ein schwarzes Loch auslösen, das sich als Stocken bei großen Übertragungen zeigt statt als langsamer Durchschnitt.

Diese drei werden oft verwechselt, weil Nutzer sie alle als „das VPN ist langsam“ beschreiben. Nur das erste reagiert auf eine größere Maschine, nur das zweite reagiert auf eine kleinere MTU, und nur das dritte reagiert auf Warteschlangenverwaltung.

Schreib die Methode in den Datensatz

Ein Ergebnis, das es wert ist, behalten zu werden, nennt Gerät, Zugangsnetz, Ausgang, Messserver, Richtung, Streamanzahl und Dauer. Ohne diese lassen sich zwei Zahlen nicht vergleichen, und ein Ticket mit einer Zahl ist eigentlich eine Stimmung.

Behalte auch die schlechten Läufe. Eine Reihe, in der ein Ausgang jedes Mal ein Stocken erzeugt, ist weit aussagekräftiger als ein Durchschnitt, und die Stockungen sind genau das, was Durchschnitte verbergen.

Teste dann das, was dir wirklich wichtig ist. Wenn ein großer Download das Ziel ist, lade die Datei herunter. Wenn ein Anruf das Ziel ist, miss die Latenz unter Last statt den Leerlaufdurchsatz, denn ein Tunnel kann in einem Geschwindigkeitstest gut abschneiden und trotzdem jedes Meeting unerträglich machen.