TCP dentro de SSTP: por que a retransmisión ocorre dúas veces

O boca a boca chega antes que o protocolo. Pregunte por aí e SSTP é o lento, a opción que se evita a menos que algo o obrigue. Esa reputación describe un único modo de fallo nun único tipo de ruta.

O mecanismo é real. Tamén é condicional, algo que a reputación nunca menciona.

Dous fluxos fiables nunha soa ruta

SSTP envolve o seu túnel dentro dunha sesión HTTPS. HTTPS funciona sobre TCP, e ese fluxo externo garante a entrega ordenada. Por iso un só segmento perdido detén todo o que fai cola detrás del. Os bytes posteriores que pertencen a outras conversas internas esperan de todos os xeitos.

Os fluxos TCP internos manteñen a súa propia orde e control de conxestión. Non poden ver a recuperación externa, así que o único que observan é unha pausa. Unha pausa é o sinal que lles di que a ruta está conxestionada.

Agora ambas as capas retroceden ao mesmo tempo. Esa é toda a interacción, e un só segmento perdido abonda para iniciarse.

Onde aparece o efecto e onde non

Nunha ruta limpa, o fluxo externo raramente recupera algo. A interacción nunca se activa, e SSTP transporta tráfico interactivo perfectamente ben. A afirmación xeral falla exactamente neste punto.

O efecto aparece cando a perda ou a reordenación chegan á ruta subxacente. Unha ligazón Wi-Fi conxestionada ou unha conexión móbil con latencia variable crean as condicións. Unha cola externa bloqueada convértese entón nun atraso visible dentro do túnel.

Tamén escala coa carga de traballo. Moitos fluxos paralelos enchen a cola e empeoran o bloqueo de cabeza de liña. Unha soa sesión interactiva pola mesma ruta pode parecer aceptable.

Que non adoita ser o síntoma

Non toda sesión lenta é este problema. Unha taxa baixa e constante desde o primeiro paquete apunta a capacidade, modelado ou un límite do servidor. As pausas que coinciden con conxestión local apuntan a colas na ligazón de acceso.

Os remedios son distintos, e por iso o diagnóstico vai primeiro. Axustar os buffers non fai nada por unha ligazón modelada. Cambiar de protocolo non fai nada por un servidor que quedou sen capacidade. Os 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

Faga a medición mentres ocorre o problema. Unha captura tomada durante un minuto saudable non demostra nada sobre o bucle que se executa durante o minuto malo.

Unha comparación na que paga a pena confiar

Se realmente hai outro transporte dispoñible, compáreo baixo control. Mesmo host, mesma rede, mesmo destino e mesma tarefa. Ambas as execucións deben caber dentro dos mesmos dez minutos para que coincidan as condicións da ruta.

Cambiar un porto non cambia un protocolo. Importar un perfil non relacionado nun cliente SSTP non crea un transporte alternativo. A comparación só ten sentido cando o servidor ofrece a segunda opción.

Manteña a verificación TLS activa en todo momento. O traballo de rendemento non é razón para aceptar un certificado non verificado. Se as pausas aparecen sobre todo mentres a ligazón ascendente está saturada, mire as colas antes de culpar as capas.