TCP dentro de SSTP: por qué la retransmisión ocurre dos veces

El boca a boca llega antes que el protocolo. Pregunte por ahí y SSTP es el lento, la opción que se evita a menos que algo le obligue. Esa reputación describe un único modo de fallo en un único tipo de ruta.

El mecanismo es real. También es condicional, cosa que la reputación nunca menciona.

Dos flujos fiables en una sola ruta

SSTP envuelve su túnel dentro de una sesión HTTPS. HTTPS funciona sobre TCP, y ese flujo externo garantiza la entrega ordenada. Por eso un solo segmento perdido frena todo lo que está en cola detrás de él. Los bytes posteriores que pertenecen a otras conversaciones internas esperan de todos modos.

Los flujos TCP internos mantienen su propio orden y control de congestión. No pueden ver la recuperación externa, así que lo único que observan es una pausa. Una pausa es la señal que les dice que la ruta está congestionada.

Ahora ambas capas retroceden al mismo tiempo. Esa es toda la interacción, y un solo segmento perdido basta para iniciarla.

Dónde aparece el efecto y dónde no

En una ruta limpia, el flujo externo rara vez recupera algo. La interacción nunca se activa, y SSTP transporta tráfico interactivo perfectamente bien. La afirmación general falla exactamente en este punto.

El efecto aparece cuando la pérdida o la reordenación llegan a la ruta subyacente. Un enlace Wi-Fi congestionado o una conexión móvil con latencia variable crean las condiciones. Una cola externa bloqueada se convierte entonces en un retraso visible dentro del túnel.

También escala con la carga de trabajo. Muchos flujos paralelos llenan la cola y empeoran el bloqueo de cabeza de línea. Una sola sesión interactiva por la misma ruta puede parecer aceptable.

Qué no suele ser el síntoma

No toda sesión lenta es este problema. Una tasa baja y constante desde el primer paquete apunta a capacidad, modelado o un límite del servidor. Las pausas que coinciden con congestión local apuntan a colas en el enlace de acceso.

Los remedios son distintos, y por eso el diagnóstico va primero. Ajustar los búferes no hace nada por un enlace modelado. Cambiar de protocolo no hace nada por un servidor que se ha quedado sin capacidad. Los reinicios repetidos apuntan a un lugar completamente distinto.

# 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

Realice la medición mientras ocurre el problema. Una captura tomada durante un minuto saludable no demuestra nada sobre el bucle que se ejecuta durante el minuto malo.

Una comparación en la que vale la pena confiar

Si realmente hay otro transporte disponible, compárelo bajo control. Mismo host, misma red, mismo destino y misma tarea. Ambas ejecuciones deben caber dentro de los mismos diez minutos para que coincidan las condiciones de la ruta.

Cambiar un puerto no cambia un protocolo. Importar un perfil no relacionado en un cliente SSTP no crea un transporte alternativo. La comparación solo significa algo cuando el servidor ofrece la segunda opción.

Mantenga la verificación TLS activa en todo momento. El trabajo de rendimiento no es motivo para aceptar un certificado no verificado. Si las pausas aparecen sobre todo mientras el enlace ascendente está saturado, mire las colas antes de culpar a las capas.