TCP in SSTP: Warum Retransmission zweimal passiert

Mundpropaganda ist schneller als das Protokoll. Fragt man herum, ist SSTP das langsame, die Option, die man meidet, wenn einen nichts dazu zwingt. Dieser Ruf beschreibt einen Fehlermodus auf einer Art von Pfad.

Der Mechanismus ist real. Er ist auch bedingt, was der Ruf nie erwähnt.

Zwei zuverlässige Streams auf einem Pfad

SSTP verpackt seinen Tunnel in einer HTTPS-Sitzung. HTTPS läuft über TCP, und dieser äußere Stream garantiert geordnete Zustellung. Ein einzelnes fehlendes Segment hält daher alles zurück, was dahinter in der Warteschlange steht. Spätere Bytes, die zu anderen inneren Gesprächen gehören, warten ohnehin.

Innere TCP-Flüsse behalten ihre eigene Reihenfolge und Überlastkontrolle. Sie können die äußere Wiederherstellung nicht sehen, also beobachten sie nur einen Stillstand. Ein Stillstand ist das Signal, das ihnen sagt, dass der Pfad überlastet ist.

Jetzt ziehen sich beide Schichten gleichzeitig zurück. Das ist die ganze Wechselwirkung, und ein verlorenes Segment reicht aus, um sie auszulösen.

Wo der Effekt auftritt und wo nicht

Auf einem sauberen Pfad stellt der äußere Stream selten etwas wieder her. Die Wechselwirkung wird nie ausgelöst, und SSTP überträgt interaktiven Verkehr völlig problemlos. Die pauschale Behauptung scheitert genau an diesem Punkt.

Der Effekt tritt auf, wenn Verlust oder Umsortierung den zugrunde liegenden Pfad erreichen. Eine überlastete Wi-Fi-Verbindung oder eine Mobilfunkverbindung mit schwankender Latenz schafft die Bedingungen. Eine blockierte äußere Warteschlange wird dann zu sichtbarer Verzögerung im Tunnel.

Er skaliert auch mit der Arbeitslast. Viele parallele Flüsse füllen die Warteschlange und verschlimmern die Blockierung am Kopf der Schlange. Eine einzelne interaktive Sitzung über denselben Pfad kann akzeptabel wirken.

Was das Symptom meistens nicht ist

Nicht jede langsame Sitzung ist dieses Problem. Eine gleichmäßig niedrige Rate ab dem ersten Paket deutet auf Kapazität, Shaping oder ein Serverlimit hin. Pausen, die mit lokaler Überlastung zusammenfallen, deuten auf Warteschlangen am Zugangs-Link hin.

Die Abhilfen unterscheiden sich, deshalb kommt die Diagnose zuerst. Puffertuning bewirkt nichts bei einem geformten Link. Der Wechsel des Protokolls bewirkt nichts bei einem Server, dessen Kapazität erschöpft ist. Wiederholte Resets deuten auf etwas ganz anderes hin.

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

Führe die Messung durch, während das Problem auftritt. Eine Aufzeichnung aus einer gesunden Minute beweist nichts über die Schleife, die in der schlechten läuft.

Ein Vergleich, dem man trauen kann

Wenn ein anderer Transport wirklich verfügbar ist, vergleiche ihn unter kontrollierten Bedingungen. Derselbe Host, dasselbe Netz, dasselbe Ziel und dieselbe Aufgabe. Beide Läufe müssen in dieselben zehn Minuten fallen, damit die Pfadbedingungen übereinstimmen.

Einen Port zu ändern ändert kein Protokoll. Ein fremdes Profil in einen SSTP-Client zu importieren erzeugt keinen alternativen Transport. Der Vergleich bedeutet nur etwas, wenn der Server die zweite Option anbietet.

Lass die TLS-Prüfung durchgehend aktiviert. Performance-Arbeit ist kein Grund, ein ungeprüftes Zertifikat zu akzeptieren. Wenn die Aussetzer vor allem auftreten, während der Uplink gesättigt ist, schau dir das Queuing an, bevor du die Schichten beschuldigst.