TCP внутри SSTP: почему повторная передача происходит дважды

Сарафанное радио приходит раньше протокола. Спросите вокруг, и SSTP окажется тем самым медленным, вариантом, которого избегают, если только что-то не заставит. Эта репутация описывает один режим отказа на одном типе пути.

Механизм реален. Он также условен, о чём репутация никогда не упоминает.

Два надёжных потока на одном пути

SSTP заворачивает свой туннель в сеанс HTTPS. HTTPS работает поверх TCP, и этот внешний поток гарантирует упорядоченную доставку. Поэтому один недостающий сегмент задерживает всё, что стоит в очереди за ним. Последующие байты, принадлежащие другим внутренним разговорам, всё равно ждут.

Внутренние потоки TCP сохраняют собственный порядок и управление перегрузкой. Они не видят внешнего восстановления, поэтому единственное, что наблюдают, — это остановка. Остановка — это сигнал, который говорит им, что путь перегружен.

Теперь оба уровня отступают одновременно. В этом всё взаимодействие, и одного потерянного сегмента достаточно, чтобы его запустить.

Где эффект появляется, а где нет

На чистом пути внешний поток редко что-то восстанавливает. Взаимодействие никогда не запускается, и SSTP прекрасно несёт интерактивный трафик. Общее утверждение терпит крах именно в этой точке.

Эффект появляется, когда потери или переупорядочивание доходят до базового пути. Перегруженное Wi-Fi-соединение или мобильное соединение с переменной задержкой создают условия. Заблокированная внешняя очередь превращается тогда в заметную задержку внутри туннеля.

Эффект растёт и с рабочей нагрузкой. Множество параллельных потоков заполняют очередь и ухудшают блокировку в начале очереди. Один интерактивный сеанс на том же пути может казаться приемлемым.

Чем симптом обычно не является

Не каждый медленный сеанс — эта проблема. Ровно низкая скорость с первого пакета указывает на пропускную способность, шейпинг или ограничение сервера. Паузы, совпадающие с локальной перегрузкой, указывают на очереди на канале доступа.

Средства различаются, поэтому диагноз идёт первым. Настройка буферов ничего не даёт для шейпингованного канала. Смена протоколов ничего не даёт серверу, у которого закончилась пропускная способность. Повторные сбросы указывают совсем в другое место.

# 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

Выполняйте измерение, пока проблема происходит. Запись, сделанная в здоровую минуту, ничего не доказывает о цикле, который работает в плохую.

Сравнение, которому стоит доверять

Если другой транспорт действительно доступен, сравните его в контролируемых условиях. Тот же хост, та же сеть, то же назначение и та же задача. Оба прогона должны уложиться в одни и те же десять минут, чтобы условия пути совпадали.

Смена порта не меняет протокол. Импорт постороннего профиля в клиент SSTP не создаёт альтернативный транспорт. Сравнение имеет смысл только тогда, когда сервер предлагает второй вариант.

Держите проверку TLS включённой всё время. Работа над производительностью не является причиной принимать непроверенный сертификат. Если остановки появляются в основном тогда, когда восходящий канал насыщен, посмотрите на очереди, прежде чем винить уровни.