TCP à l’intérieur de SSTP : pourquoi la retransmission survient deux fois

Le bouche-à-oreille arrive avant le protocole. Demandez autour de vous et SSTP est le lent, l’option que l’on évite sauf si quelque chose vous y force. Cette réputation décrit un seul mode de défaillance sur un seul type de chemin.

Le mécanisme est réel. Il est aussi conditionnel, ce que la réputation ne mentionne jamais.

Deux flux fiables sur un seul chemin

SSTP enveloppe son tunnel dans une session HTTPS. HTTPS fonctionne sur TCP, et ce flux externe garantit une livraison ordonnée. Un seul segment manquant retient donc tout ce qui fait la queue derrière lui. Les octets suivants, qui appartiennent à d’autres conversations internes, attendent de toute façon.

Les flux TCP internes conservent leur propre ordre et leur contrôle de congestion. Ils ne voient pas la récupération externe, donc tout ce qu’ils observent est un blocage. Un blocage est le signal qui leur dit que le chemin est congestionné.

Les deux couches reculent maintenant en même temps. C’est toute l’interaction, et un seul segment perdu suffit à la déclencher.

Où l’effet apparaît et où il n’apparaît pas

Sur un chemin propre, le flux externe récupère rarement quoi que ce soit. L’interaction ne se déclenche jamais, et SSTP transporte très bien le trafic interactif. L’affirmation générale échoue précisément sur ce point.

L’effet apparaît lorsque la perte ou la réorganisation atteint le chemin sous-jacent. Une liaison Wi-Fi congestionnée ou une connexion mobile à latence variable crée les conditions. Une file externe bloquée se transforme alors en retard visible à l’intérieur du tunnel.

Il évolue aussi avec la charge de travail. De nombreux flux parallèles remplissent la file et aggravent le blocage en tête de file. Une seule session interactive sur le même chemin peut sembler acceptable.

Ce que le symptôme n’est généralement pas

Toute session lente n’est pas ce problème. Un débit faible et régulier dès le premier paquet indique un manque de capacité, une mise en forme ou une limite de serveur. Les pauses qui coïncident avec une congestion locale indiquent une mise en file sur la liaison d’accès.

Les remèdes diffèrent, c’est pourquoi le diagnostic vient d’abord. Le réglage des tampons ne fait rien pour une liaison mise en forme. Changer de protocole ne fait rien pour un serveur à court de capacité. Des réinitialisations répétées pointent vers un tout autre endroit.

# 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

Effectuez la mesure pendant que le problème se produit. Une capture prise pendant une minute saine ne prouve rien sur la boucle qui tourne pendant la mauvaise.

Une comparaison qui mérite confiance

Si un autre transport est réellement disponible, comparez-le dans des conditions contrôlées. Même hôte, même réseau, même destination et même tâche. Les deux exécutions doivent se situer dans les mêmes dix minutes pour que les conditions du chemin correspondent.

Changer un port ne change pas un protocole. Importer un profil sans rapport dans un client SSTP ne crée pas un transport alternatif. La comparaison n’a de sens que lorsque le serveur propose la seconde option.

Gardez la vérification TLS active en permanence. Le travail sur les performances n’est pas une raison d’accepter un certificat non vérifié. Si les blocages apparaissent surtout lorsque la liaison montante est saturée, examinez la mise en file avant d’accuser les couches.