TCP în interiorul SSTP: de ce retransmisia are loc de două ori

Vorba din gură în gură ajunge înaintea protocolului. Întrebați în jur și SSTP este cel lent, opțiunea pe care o evitați dacă ceva nu vă obligă. Acea reputație descrie un singur mod de eșec pe un singur tip de cale.

Mecanismul este real. Este și condiționat, ceea ce reputația nu menționează niciodată.

Două fluxuri fiabile pe o singură cale

SSTP își înfășoară tunelul într-o sesiune HTTPS. HTTPS rulează peste TCP, iar acel flux exterior garantează livrarea ordonată. De aceea un singur segment lipsă reține tot ce stă la coadă în spatele lui. Biții ulteriori care aparțin altor conversații interne așteaptă oricum.

Fluxurile TCP interioare își păstrează propria ordine și control al congestionării. Nu pot vedea recuperarea exterioară, așa că singurul lucru pe care îl observă este o oprire. O oprire este semnalul care le spune că calea este congestionată.

Acum ambele straturi se retrag în același timp. Aceasta este întreaga interacțiune, iar un singur segment pierdut este suficient pentru a o porni.

Unde apare efectul și unde nu

Pe o cale curată fluxul exterior recuperează rareori ceva. Interacțiunea nu se declanșează niciodată, iar SSTP transportă trafic interactiv foarte bine. Afirmația generală eșuează exact în acest punct.

Efectul apare când pierderea sau reordonarea ajung pe calea de bază. O legătură Wi-Fi congestionată sau o conexiune mobilă cu latență variabilă creează condițiile. O coadă exterioară blocată se transformă atunci într-o întârziere vizibilă în interiorul tunelului.

Efectul crește și cu volumul de lucru. Multe fluxuri paralele umplu coada și agravează blocarea de la capul cozii. O singură sesiune interactivă pe aceeași cale poate părea acceptabilă.

Ce nu este de obicei simptomul

Nu orice sesiune lentă este această problemă. O rată scăzută constantă încă de la primul pachet indică capacitate, modelare sau o limită a serverului. Pauzele care coincid cu congestionarea locală indică cozi pe legătura de acces.

Remediile diferă, de aceea diagnosticul vine primul. Reglarea tampoanelor nu face nimic pentru o legătură modelată. Schimbarea protocoalelor nu face nimic pentru un server rămas fără capacitate. Resetările repetate indică un cu totul alt loc.

# 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

Faceți măsurătoarea în timp ce problema se manifestă. O captură făcută într-un minut sănătos nu dovedește nimic despre bucla care rulează în cel rău.

O comparație în care merită să ai încredere

Dacă un alt transport este într-adevăr disponibil, comparați-l în condiții controlate. Aceeași gazdă, aceeași rețea, aceeași destinație și aceeași sarcină. Ambele rulări trebuie să se încadreze în aceleași zece minute, astfel încât condițiile căii să corespundă.

Schimbarea unui port nu schimbă un protocol. Importarea unui profil nelegat într-un client SSTP nu creează un transport alternativ. Comparația are sens doar când serverul oferă a doua opțiune.

Păstrați verificarea TLS activă tot timpul. Munca de performanță nu este un motiv să acceptați un certificat neverificat. Dacă opririle apar mai ales când legătura ascendentă este saturată, priviți cozile înainte de a da vina pe straturi.