TCP binnen SSTP: waarom herverzending twee keer gebeurt

Mond-tot-mond komt voor het protocol. Vraag rond en SSTP is de langzame, de optie die je vermijdt tenzij iets je dwingt. Die reputatie beschrijft één faalmodus op één soort pad.

Het mechanisme is echt. Het is ook voorwaardelijk, wat de reputatie nooit noemt.

Twee betrouwbare stromen op één pad

SSTP wikkelt zijn tunnel in een HTTPS-sessie. HTTPS draait over TCP, en die buitenste stroom garandeert geordende aflevering. Eén ontbrekend segment houdt daarom alles tegen dat erachter in de rij staat. Latere bytes die bij andere binnenste gesprekken horen, wachten toch.

Binnenste TCP-stromen houden hun eigen ordening en congestiebeheersing. Ze kunnen het buitenste herstel niet zien, dus het enige dat ze waarnemen is een stilstand. Een stilstand is het signaal dat hun zegt dat het pad overbelast is.

Nu trekken beide lagen zich tegelijk terug. Dat is de hele wisselwerking, en één verloren segment is genoeg om die te beginnen.

Waar het effect optreedt en waar niet

Op een schoon pad herstelt de buitenste stroom zelden iets. De wisselwerking wordt nooit geactiveerd, en SSTP draagt interactief verkeer prima. De algemene bewering faalt precies op dit punt.

Het effect treedt op wanneer verlies of herordening het onderliggende pad bereikt. Een overbelaste Wi-Fi-verbinding of een mobiele verbinding met wisselende latency schept de omstandigheden. Een geblokkeerde buitenste wachtrij wordt dan zichtbare vertraging in de tunnel.

Het schaalt ook met de werkbelasting. Veel parallelle stromen vullen de wachtrij en verergeren blokkering aan de kop van de rij. Eén interactieve sessie over hetzelfde pad kan acceptabel aanvoelen.

Wat het symptoom meestal niet is

Niet elke trage sessie is dit probleem. Een gelijkmatig lage snelheid vanaf het eerste pakket wijst op capaciteit, shaping of een serverlimiet. Pauzes die samenvallen met lokale congestie wijzen op wachtrijen op de toegangslink.

De remedies verschillen, daarom komt de diagnose eerst. Buffertuning doet niets voor een gevormde link. Van protocol wisselen doet niets voor een server zonder capaciteit. Herhaalde resets wijzen ergens heel anders heen.

# 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

Voer de meting uit terwijl het probleem zich voordoet. Een opname uit een gezonde minuut bewijst niets over de lus die in de slechte draait.

Een vergelijking die vertrouwen verdient

Als er echt een ander transport beschikbaar is, vergelijk het dan onder controle. Dezelfde host, hetzelfde netwerk, dezelfde bestemming en dezelfde taak. Beide runs moeten binnen dezelfde tien minuten vallen zodat de padomstandigheden overeenkomen.

Een poort wijzigen wijzigt geen protocol. Een ongerelateerd profiel in een SSTP-client importeren maakt geen alternatief transport. De vergelijking zegt alleen iets wanneer de server de tweede optie biedt.

Houd TLS-verificatie de hele tijd aan. Prestatiewerk is geen reden om een ongeverifieerd certificaat te accepteren. Als de stiltes vooral optreden terwijl de uplink verzadigd is, kijk dan naar wachtrijen voordat je de lagen de schuld geeft.