TCP вътре в SSTP: защо повторното предаване се случва два пъти

SSTP пренася тунела в TCP поток през TLS. Когато пътят изпуска пакети, външното и вътрешното възстановяване отстъпват едновременно.

Слуховете пристигат преди протокола. Попитайте наоколо и 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 проверката включена през цялото време. Работата върху производителността не е причина да приемете непроверен сертификат. Ако спиранията се появяват главно, докато изходящата връзка е наситена, погледнете опашките, преди да обвините слоевете.

Подобни статии