TCP dentro do SSTP: por que a retransmissão acontece duas vezes

O boca a boca chega antes do protocolo. Pergunte por aí e o SSTP é o lento, a opção que se evita a menos que algo obrigue. Essa reputação descreve um único modo de falha num único tipo de caminho.

O mecanismo é real. Também é condicional, o que a reputação nunca menciona.

Dois fluxos confiáveis num único caminho

SSTP envolve o seu túnel numa sessão HTTPS. O HTTPS funciona sobre TCP, e esse fluxo externo garante a entrega ordenada. Por isso um único segmento perdido retém tudo o que está na fila atrás dele. Os bytes posteriores pertencentes a outras conversas internas esperam de qualquer forma.

Os fluxos TCP internos mantêm a sua própria ordem e controlo de congestão. Não conseguem ver a recuperação externa, por isso a única coisa que observam é uma paragem. Uma paragem é o sinal que lhes diz que o caminho está congestionado.

Agora ambas as camadas recuam ao mesmo tempo. É toda a interação, e um único segmento perdido basta para a iniciar.

Onde o efeito aparece e onde não aparece

Num caminho limpo, o fluxo externo raramente recupera algo. A interação nunca é acionada, e o SSTP transporta tráfego interativo perfeitamente bem. A afirmação genérica falha exatamente neste ponto.

O efeito aparece quando a perda ou a reordenação chegam ao caminho subjacente. Uma ligação Wi-Fi congestionada ou uma ligação móvel com latência variável criam as condições. Uma fila externa bloqueada transforma-se então num atraso visível dentro do túnel.

Também escala com a carga de trabalho. Muitos fluxos paralelos enchem a fila e agravam o bloqueio no início da fila. Uma única sessão interativa no mesmo caminho pode parecer aceitável.

O que o sintoma geralmente não é

Nem toda a sessão lenta é este problema. Uma taxa baixa e constante desde o primeiro pacote aponta para capacidade, modelação ou um limite do servidor. As pausas que coincidem com congestão local apontam para filas na ligação de acesso.

Os remédios diferem, e é por isso que o diagnóstico vem primeiro. A afinação de buffers não faz nada por uma ligação modelada. Mudar de protocolo não faz nada por um servidor sem capacidade. Reinícios repetidos apontam para um lugar completamente diferente.

# 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

Faça a medição enquanto o problema está a acontecer. Uma captura tirada num minuto saudável não prova nada sobre o ciclo que corre no minuto mau.

Uma comparação em que vale a pena confiar

Se outro transporte estiver realmente disponível, compare-o em condições controladas. O mesmo anfitrião, a mesma rede, o mesmo destino e a mesma tarefa. As duas execuções devem caber nos mesmos dez minutos para que as condições do caminho coincidam.

Mudar uma porta não muda um protocolo. Importar um perfil não relacionado para um cliente SSTP não cria um transporte alternativo. A comparação só significa algo quando o servidor oferece a segunda opção.

Mantenha a verificação TLS ativa o tempo todo. O trabalho de desempenho não é razão para aceitar um certificado não verificado. Se as paragens aparecem sobretudo enquanto a ligação ascendente está saturada, olhe para as filas antes de culpar as camadas.