Eine Übertragung, die über die Büroverbindung kriecht, ist über den Tunnel manchmal schnell fertig, und die zusätzliche Kapselung lässt das unmöglich erscheinen. Das scheinbare Paradox entsteht durch den Vergleich der falschen Dinge. Der Tunnel fügt Arbeit hinzu und ändert zugleich welchen Netzwerkpfad der Verkehr nimmt, welche Adresse das Ziel sieht und manchmal, welcher Server überhaupt antwortet. Eine Entscheidung zwischen den beiden Routen verlangt, diese drei Effekte zu trennen, bevor irgendein Schluss über die Geschwindigkeit fällt.

Drei Dinge, die der Tunnel ändern kann

Das erste ist der Transit. Internet-Routing folgt der Politik der Betreiber und Geschäftsbeziehungen, nicht der gemessenen Latenz, daher kann der Weg über einen VPN-Anbieter andere Netze durchqueren als die direkte Route. Er kann einen überlasteten Austauschpunkt meiden oder auf einem besser angebundenen landen, und er kann genauso leicht schlechter sein.

Das zweite ist das Ziel. Ein Wechsel der Ausgangsadresse ändert oft die DNS-Antwort, und ein Content-Netzwerk kann Ihnen einen anderen Cache oder eine andere Region zuweisen. Ein Teil der Verbesserung gehört dann dem neuen Server und nicht dem Tunnel. Derselbe Hostname kann auf einem näheren oder weniger ausgelasteten Server landen, ohne dass sich beim Client etwas ändert.

Das dritte ist das Transportverhalten. Kapselung verändert die effektive Paketgröße, und ein Tunnel, der ein verlustbehaftetes Mittelstück meidet, kann einen TCP-Fluss sein Fenster vergrößern lassen, statt immer wieder zurückzufallen. Nichts davon ist ein universeller Beschleunigungsmechanismus; jedes ist eine Bedingung, die beobachtet werden muss. Sie zu trennen macht aus einer Kuriosität einen Befund.

Was er nicht ändern kann

Nichts am Tunnel fügt der Strecke zwischen Gerät und Netz Kapazität hinzu. Ein gesättigter Wi-Fi-Kanal, eine überlastete letzte Meile oder ein gedrosselter Mobilfunktarif begrenzen beide Wege gleichermaßen, und ein Geschwindigkeitstest durch den Tunnel kann diese Obergrenze nicht überschreiten. Dieselbe Strecke trägt die gekapselten Pakete, Kapselung kann Kapazität verbrauchen, aber niemals erzeugen. Was sich ändert, ist der Weg der Pakete, nachdem sie diese Strecke verlassen. Deshalb hat ein schnelles Tunnelergebnis immer eine Erklärung oberhalb des ersten Hops.

Grenzen auf der Serverseite sind ebenso gleichgültig. Dient der entfernte Host langsam, liefert ein besserer Pfad die langsame Antwort nur effizienter, und der Nutzer wartet weiterhin. Eine gemeinsam genutzte Quelle unter Last wirkt im selben Moment auf beiden Wegen langsam.

Vergleichen Sie die Wege richtig

Halten Sie Anwendung, Richtung, Dauer und Parallelität gleich und ändern Sie nur den Weg. Führen Sie jeden Test mehr als einmal zur selben Tageszeit aus und notieren Sie die Ausgangsadresse und die Antwort des Resolvers neben dem Durchsatz. Ein Lauf ist eine Stichprobe und keine Messung, und ein einzelner schneller Download kann ein Cache-Treffer sein, der über die Route nichts aussagt. Schreiben Sie die Bedingungen vor den Ergebnissen auf, denn die Zahlen lassen sich hinterher schwer deuten.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Die Antwort des Resolvers ist das Detail, das die meisten Vergleiche weglassen, und sie erklärt „Verbesserungen“, die verschwinden, wenn derselbe Server erzwungen wird. Unterscheidet sich die Adresse zwischen den Läufen, hat der Test zwei Ziele statt zwei Wege verglichen. Melden Sie Latenz und Verlust neben dem Durchsatz, denn ein Weg, der insgesamt schneller ist, aber jeder interaktiven Anfrage Verzögerung hinzufügt, ist für die Arbeitslast, die sich beschwert hat, nicht besser. Die Umlaufzeit zählt für alles, was fragt und wartet, mehr als die Massenbandbreite.

Wann der Unterschied es wert ist, behalten zu werden

Wenn ein genehmigter Tunnel eine bestimmte Arbeitslast zuverlässig verbessert, ist das eine legitime Betriebsentscheidung: Dokumentieren Sie Arbeitslast, Messung und verwendeten Ausgang. Ein brauchbarer Eintrag nennt einen Host, die vom Tunnel erzeugte Ausgangsadresse, die Antwort des Resolvers und dieselben Zahlen vom direkten Weg am selben Tag. Das genügt, damit die nächste Person den Vergleich wiederholt, statt ihn erneut auszutragen. Es ist weiterhin kein Beweis dafür, dass der Anbieter etwas drosselt, und es überträgt sich nicht auf andere Anwendungen oder andere Stunden.

Bewahren Sie den Messdatensatz zusammen mit der Konfiguration auf. Er beantwortet die nächste Frage, ob die Verbesserung noch besteht, und das ist der einzige Weg zu wissen, ob sich der Weg oder die Arbeitslast geändert hat. Ein Eintrag ohne Datum kann diese Frage überhaupt nicht beantworten.

Ähnliche Artikel