TCP inne i SSTP: hvorfor gjensending skjer to ganger

SSTP bærer tunnelen i en TCP-strøm over TLS. Når veien mister pakker, trekker ytre og indre gjenoppretting seg tilbake samtidig.

Munn-til-munn kommer før protokollen. Spør deg rundt, og SSTP er den trege, alternativet du unngår med mindre noe tvinger deg. Det ryktet beskriver én feilmodus på én type vei.

Mekanismen er reell. Den er også betinget, noe ryktet aldri nevner.

To pålitelige strømmer på én vei

SSTP pakker tunnelen sin inn i en HTTPS-økt. HTTPS går over TCP, og den ytre strømmen garanterer levering i rekkefølge. Ett manglende segment holder derfor tilbake alt som står i kø bak det. Senere byte som tilhører andre indre samtaler venter uansett.

Indre TCP-strømmer beholder sin egen rekkefølge og overbelastningskontroll. De kan ikke se den ytre gjenopprettingen, så det eneste de observerer, er en stans. En stans er signalet som forteller dem at veien er overbelastet.

Nå trekker begge lag seg tilbake samtidig. Det er hele samspillet, og ett tapt segment er nok til å starte det.

Hvor effekten vises, og hvor den ikke gjør det

På en ren vei gjenoppretter den ytre strømmen sjelden noe. Samspillet utløses aldri, og SSTP bærer interaktiv trafikk helt fint. Den generelle påstanden svikter nettopp på dette punktet.

Effekten vises når tap eller omorganisering når den underliggende veien. En overbelastet Wi-Fi-lenke eller en mobilforbindelse med variabel latens skaper forholdene. En blokkert ytre kø blir da til synlig forsinkelse inne i tunnelen.

Den skalerer også med arbeidsbelastningen. Mange parallelle strømmer fyller køen og gjør blokkering i køens front verre. Én interaktiv økt over samme vei kan føles akseptabel.

Hva symptomet vanligvis ikke er

Ikke hver treg økt er dette problemet. En jevn lav hastighet fra første pakke peker på kapasitet, forming eller en servergrense. Pauser som sammenfaller med lokal overbelastning, peker på køer på tilgangslenken.

Rådene er forskjellige, og derfor kommer diagnosen først. Bufferjustering gjør ingenting for en formet lenke. Bytte av protokoller gjør ingenting for en server som har brukt opp kapasiteten. Gjentatte tilbakestillinger peker et helt annet sted.

# 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

Utfør målingen mens problemet skjer. Et opptak tatt i et friskt minutt beviser ingenting om løkken som kjører i det dårlige.

En sammenligning det er verdt å stole på

Hvis en annen transport faktisk er tilgjengelig, sammenlign den under kontrollerte forhold. Samme vert, samme nettverk, samme destinasjon og samme oppgave. Begge kjøringene må ligge innenfor de samme ti minuttene, slik at veiforholdene stemmer.

Å endre en port endrer ikke en protokoll. Å importere en uvedkommende profil i en SSTP-klient skaper ikke en alternativ transport. Sammenligningen betyr bare noe når serveren tilbyr det andre alternativet.

Hold TLS-verifiseringen på hele tiden. Ytelsesarbeid er ikke en grunn til å godta et uverifisert sertifikat. Hvis stansene hovedsakelig oppstår mens oppstrømslenken er mettet, se på køingen før du klandrer lagene.

Relaterte artikler