TCP dentro SSTP: perché la ritrasmissione avviene due volte

Il passaparola arriva prima del protocollo. Chiedete in giro e SSTP è quello lento, l'opzione che si evita a meno che qualcosa non vi costringa. Quella reputazione descrive un solo modo di guasto su un solo tipo di percorso.

Il meccanismo è reale. È anche condizionale, cosa che la reputazione non menziona mai.

Due flussi affidabili su un solo percorso

SSTP avvolge il suo tunnel in una sessione HTTPS. HTTPS gira su TCP, e quel flusso esterno garantisce la consegna ordinata. Un solo segmento mancante trattiene quindi tutto ciò che è in coda dietro di esso. I byte successivi, appartenenti ad altre conversazioni interne, attendono comunque.

I flussi TCP interni mantengono il proprio ordine e il proprio controllo della congestione. Non riescono a vedere il recupero esterno, quindi l'unica cosa che osservano è uno stallo. Uno stallo è il segnale che dice loro che il percorso è congestionato.

Ora entrambi gli strati arretrano nello stesso momento. È tutta l'interazione, e un solo segmento perso basta ad avviarla.

Dove l'effetto compare e dove no

Su un percorso pulito il flusso esterno raramente recupera qualcosa. L'interazione non si attiva mai, e SSTP trasporta il traffico interattivo benissimo. L'affermazione generale fallisce proprio su questo punto.

L'effetto compare quando la perdita o la riordinazione raggiungono il percorso sottostante. Un collegamento Wi-Fi congestionato o una connessione mobile con latenza variabile creano le condizioni. Una coda esterna bloccata si trasforma allora in un ritardo visibile dentro il tunnel.

L'effetto cresce anche con il carico di lavoro. Molti flussi paralleli riempiono la coda e peggiorano il blocco di testa. Una sola sessione interattiva sullo stesso percorso può sembrare accettabile.

Ciò che di solito il sintomo non è

Non ogni sessione lenta è questo problema. Una velocità bassa e costante fin dal primo pacchetto indica capacità, sagomatura o un limite del server. Le pause che coincidono con congestione locale indicano code sul collegamento di accesso.

I rimedi differiscono, ed è per questo che la diagnosi viene prima. La regolazione dei buffer non fa nulla per un collegamento sagomato. Cambiare protocollo non fa nulla per un server a corto di capacità. Le reimpostazioni ripetute indicano un punto del tutto diverso.

# 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

Eseguite la misurazione mentre il problema è in corso. Una cattura presa durante un minuto sano non dimostra nulla sul ciclo che gira durante il minuto cattivo.

Un confronto di cui fidarsi

Se un altro trasporto è davvero disponibile, confrontatelo in condizioni controllate. Stesso host, stessa rete, stessa destinazione e stesso compito. Entrambe le esecuzioni devono cadere negli stessi dieci minuti perché le condizioni del percorso coincidano.

Cambiare una porta non cambia un protocollo. Importare un profilo non correlato in un client SSTP non crea un trasporto alternativo. Il confronto ha senso solo quando il server offre la seconda opzione.

Mantenete attiva la verifica TLS per tutto il tempo. Il lavoro sulle prestazioni non è una ragione per accettare un certificato non verificato. Se gli stalli compaiono soprattutto mentre l'uplink è saturo, guardate le code prima di dare la colpa agli strati.