OpenVPN TCP аркылуу: rto_min кезектин башындагы бөгөттү жойбойт

Туннелдин үстүндөгү интерактивдүү shell файл көчүрмөсү жүрүп жатканда бир нече секунд катып калат, анан эч нерсе болбогондой уланат. Көйгөй жүктөөдө гана, бирок shell да күтөт, экөө тең бир эле учурда калыбына келет. Бул үлгү көптөгөн сүйлөшүүлөрдү ташыган бир ишенимдүү агымдын кол тамгасы жана адамдар биринчи сынаган дээрлик ар бир жөндөөгө туруштук берет.

Симптомду кылдат окуу керек, анткени ал параметрге эмес, механизмге көрсөтөт: тыныгуу жалпы, демек себеби да жалпы, ал эми жалпы объект тышкы байланыш. Ушул убакта журналдагы калган нерселердин баары кадимкидей көрүнөт.

Симптом: баары бир убакта токтойт

Эки ички байланыштын чогуу илинип калышы белги. Жай жүктөө жана жай shell өзүнчө иреттик номурлары жана өзүнчө тыгын абалы бар өзүнчө TCP сүйлөшүүлөрү, ошондуктан бириндеги бузулуу экинчисине тийбеши керек. Алар бир ритмде токтогондо, алардын үстүндөгү бир нерсе байттарын иреттеп жатат.

Ошол нерсе туннелдин ташуу катмары. TCP режиминде OpenVPN капсулаганын пакеттерди өнөктөшкө бараткан бир TCP байланышка жазат, ал эми TCP келишими бир байт агымын ирети менен жеткирүү. Кийинки байттар кайсы ички сүйлөшүүгө таандык болбосун, жетишпегендерден мурун колдонмого берилбейт.

Симптом эмнени айтпай турганына көңүл буруңуз. Ал жолдун бузулганын, сервердин ашык жүктөлгөнүн же шифрлоонун жай экенин айтпайды. Алар башка формаларды берет: бирдей төмөн өткөрүү жөндөмү, убакыт бүтүүлөрү же бир багытка гана тийген бузулуулар. Жоголгон сегмент кайра жиберилгенде бүткөн жалпы тыныгуу так иреттүүлүк таасири.

Бир тышкы байт агымы, көптөгөн ички сүйлөшүү

Туннел бир убакта жүктөөнү да, shell-ди да ташып жатканын элестетиңиз. Тышкы байланыштын бир сегменти жоголот. Кийинки сегменттер кабыл алуучу хостко жетиши мүмкүн жана кабыл алуучу TCP стек аларды тастыктайт, бирок боштук толукталмайынча аларды жогору бере албайт. Ошондуктан OpenVPN-дин shell үчүн окуй турган эч нерсеси жок, shell-дин өз байттары көптөн мурун келген болсо да.

Бул бир байланыштын ичиндеги кезек башындагы бөгөт жана ал эки колдонмонун ички байланышты бөлүшүүсүн талап кылбайт. Алар тышкы байланышты бөлүшөт, бул жетиштүү.

Экинчи даражадагы таасир аны начарлатат. Тастыктоолорду көрбөгөн ички жиберүүчү тышкы катмар жеткирүүгө аракет кылып жаткан маалыматты кайра жибериши мүмкүн. Бул кайра жиберүү сегменттерди жоготуп аларын жаңы эле далилдеген жолдо кошумча туннелдик трафикке айланат, ошондуктан калыбына келтирүү иши маанилүү калыбына келтирүү менен атаандашат.

Булардын эч бири кулап түшүүгө кепилдик бербейт. Кыска барып-келүү убакыттары жана кенен кезектери бар таза жолдо бул түзүлүш жылдар бою толук жарактуу болушу мүмкүн. Бузулуу жоготуу, кечигүү жана кезек тереңдиги чогуу келгенде пайда болот, ошондуктан отчёттор жакшы жабдылган кеңселерге эмес, тыгындаган жогорку каналдарга жана уюлдук байланыштарга топтолот.

Эмне үчүн узунураак ички таймер жардам бере албайт

Жолдо rto_min аркылуу эң аз кайра жиберүү мөөнөтүн көтөрүү ушул жолду колдонгон жергиликтүү өндүрүлгөн TCP трафиги үчүн таймерге негизделген кайра жиберүүнү кечиктирет. Бул чыныгы таасири бар чыныгы баскыч жана ал биринчи эмес, экинчи даражадагы маселени чечет.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

Анын жасай албаганы: тышкы байттарды иреттен тыш чыгаруу, жоголгон сегментти тезирээк калыбына келтирүү же алыскы колдонмо серверин ошол эле таймерди кабыл алууга мажбурлоо. Кабыл алуучу стек дагы эле ирети менен жеткирет, ал эми алыскы учтагы жиберүүчү дагы эле өзүнүн барып-келүү өлчөөлөрүн колдонот.

Ал ошондой эле башка бардык жоготууну калыбына келтирүү механизмдерин өчүрбөйт. Чыныгы жоготуу таймерге негизделген калыбына келтирүүнү талап кылган жерде чоңураак минимум колдонмону аракет кылуудан мурун узагыраак күтүүгө мажбурлайт, бул кечигүүгө сезимтал сессияга керектүү нерсенин тескериси.

Он эки секунддук туруктуу төмөнкү чек бул темадагы кеңештерде TCP туннелинин болушу аны талап кылгандай көрүнөт. RFC 6298-де сүрөттөлгөн кайра жиберүү таймери өлчөнгөн барып-келүү убактысынан экспоненциалдуу чегинүү менен алынат, ошондуктан туруктуу чек белгилүү бир жол үчүн саясат тандоо, протокол талабы эмес. Кеңири колдонулганда ал симптомду жашырып, ошол жол камтыган ар бир агымдын калыбына келишин өзгөртөт.

tcp-nodelay эмне кылат жана эмне кылбайт

Ташуу сокетинде Nagle стилиндеги буферлөөнү өчүргөн туннелдик опциянын максаты тар: кичине жазуулардын жиберүү алдында кошумча маалымат күтүүсүн токтотот. Бул интерактивдүү трафикке башка жагынан соо жолдо кошумча кечигүүдөн качууга жардам берет.

Ал ташууну иретсиз кылбайт жана жоголгон сегменттен кийинки калыбына келтирүүнү кыскартпайт. Кайра жиберүү мөөнөтү үчүн токтогон shell ошол опция күйүк болсо да токтойт, анткени опция иреттүүлүк эрежесине эч качан тийген эмес.

Экөөнү алмаштыруу оңой, анткени экөө тең кечигүүнү түзөтүү катары сүрөттөлөт. Бири буферлөө алып келген жасалма күтүүнү алып салат, экинчиси ташуу кепилдик берген нерсени өзгөртүүнү талап кылат, ал эми муну эч бир сокет опциясы жасабайт.

Ташуу катмарларын кадимкидей салыштыруу жолу

Эгер оператор уруксат берсе жана эки кызмат тең болсо, бирдей жумуш жүгүн ташыган UDP кызматы менен TCP кызматын ошол эле серверге бараткан ошол эле кирүү жолунда салыштырыңыз. Эки сынактын ортосунда өлкөнү, провайдерди же сервер муунун алмаштыруу жыйынтыкка үстөмдүк кыла турган өзгөрмө киргизет.

Өткөрүү жөндөмүнүн санына эмес, жалпы тыныгууга көңүл буруңуз. Тышкы жоготуу убагында бир нече ички колдонмонун чогуу илиниши кезек башындагы бөгөттү аныктаган байкоо; ылдамдык сынагынын бир төмөн саны муну жасабайт.

Туннел интерфейсиндеги жана физикалык интерфейстеги уруксат берилген кармоолор эки катмарды таза ажыратат, анткени ички жана тышкы кайра жиберүүлөр ар башка иреттик мейкиндиктери бар ар башка байланыштарга таандык. Тышкы агым боштук көрсөтүп турганда ички кайра жиберүүлөрдү көрүү түз далил.

UDP-ге өтүү кошумча ишенимдүү агымды алып салат жана ички TCP өз калыбына келтирүүсүн өзү жасашына жол берет. Ал нөлдүк жоготууга же төмөн кечигүүгө убада бербейт, ал эми каныккан жогорку канал, өтө чоң кезектер же MTU маселеси дагы эле оңдоону талап кылат. Туннелден тышкаркы трафик туннелдин иреттик боштугунун артында эч качан кармалбайт, бирок эки жол бир тыгындаган байланышты бөлүшкөндө ал дагы эле жабыркашы мүмкүн, жана бул жалпы кууш жер бул жерге бүктөлбөстөн өз изилдөөсүнө татыктуу.