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 увесь час уключанай. Праца над прадукцыйнасцю не з'яўляецца прычынай прымаць непацверджаны сертыфікат. Калі прыпынкі з'яўляюцца галоўным чынам тады, калі ўзыходзячы канал насычаны, паглядзіце на чаргаванне, перш чым вінаваціць узроўні.

Падобныя артыкулы