TCP dins de SSTP: per què la retransmissió passa dues vegades

La veu popular arriba abans que el protocol. Pregunteu i SSTP és el lent, l'opció que eviteu tret que alguna cosa us hi obligui. Aquesta reputació descriu un sol mode de fallada en un sol tipus de camí.

El mecanisme és real. També és condicional, cosa que la reputació mai no esmenta.

Dos fluxos fiables en un sol camí

SSTP embolcalla el seu túnel dins d'una sessió HTTPS. HTTPS funciona sobre TCP, i aquest flux extern garanteix l'entrega ordenada. Per tant, un sol segment perdut atura tot el que fa cua darrere seu. Els bytes posteriors que pertanyen a altres converses internes esperen igualment.

Els fluxos TCP interns mantenen el seu propi ordre i control de congestió. No poden veure la recuperació externa, així que tot el que observen és una aturada. Una aturada és el senyal que els diu que el camí està congestionat.

Ara totes dues capes retrocedeixen alhora. Aquesta és tota la interacció, i un sol segment perdut n'hi ha prou per començar-la.

On apareix l'efecte i on no

En un camí net, el flux extern poques vegades recupera res. La interacció mai s'activa, i SSTP transporta trànsit interactiu perfectament bé. L'afirmació general falla exactament en aquest punt.

L'efecte apareix quan la pèrdua o la reordenació arriben al camí subjacent. Un enllaç Wi-Fi congestionat o una connexió mòbil amb latència variable creen les condicions. Una cua externa bloquejada es converteix llavors en un retard visible dins del túnel.

També escala amb la càrrega de treball. Molts fluxos paral·lels omplen la cua i empitjoren el bloqueig de cap de línia. Una sola sessió interactiva pel mateix camí pot semblar acceptable.

Què no sol ser el símptoma

No tota sessió lenta és aquest problema. Una taxa baixa constant des del primer paquet apunta a capacitat, modelatge o un límit del servidor. Les pauses que coincideixen amb congestió local apunten a cues a l'enllaç d'accés.

Els remeis són diferents, i per això el diagnòstic va primer. L'ajust dels búfers no fa res per a un enllaç modelat. Canviar de protocol no fa res per a un servidor que s'ha quedat sense capacitat. Els reinicis repetits apunten a un lloc completament diferent.

# 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

Feu el mesurament mentre el problema passa. Una captura presa durant un minut saludable no demostra res sobre el bucle que funciona durant el minut dolent.

Una comparació en què val la pena confiar

Si realment hi ha un altre transport disponible, compareu-lo sota control. Mateix amfitrió, mateixa xarxa, mateixa destinació i mateixa tasca. Totes dues execucions han de cabre dins dels mateixos deu minuts perquè les condicions del camí coincideixin.

Canviar un port no canvia un protocol. Importar un perfil no relacionat en un client SSTP no crea un transport alternatiu. La comparació té sentit només quan el servidor ofereix la segona opció.

Mantingueu la verificació TLS activa en tot moment. La feina de rendiment no és una raó per acceptar un certificat no verificat. Si les aturades apareixen principalment mentre l'enllaç ascendent està saturat, mireu les cues abans de culpar les capes.