OpenVPN преку TCP: rto_min не ја решава блокадата на почетокот од редот

Интерактивна школка преку тунелот замрзнува неколку секунди додека работи копирање датотека, потоа продолжува како ништо да не се случило. Проблем има само преземањето, но и школката чека, и двете се опоравуваат во истиот момент. Тој образец е потпис на еден сигурен тек што носи многу разговори и го преживува речиси секое подесување што луѓето прво го пробуваат.

Симптомот вреди внимателно читање бидејќи укажува на механизам, а не на поставка: паузата е заедничка, значи причината е заедничка, а заедничкиот објект е надворешната врска. Сето друго во дневникот изгледа нормално додека тоа се случува.

Симптом: се запира истовремено

Две внатрешни врски што заглавуваат заедно се трагата. Бавното преземање и бавната школка се одделни TCP разговори со одделни редни броеви и одделна состојба на загуштеност, па дефект во едната не би требало да ја допре другата. Кога запираат во ист ритам, нешто над нив ги подредува нивните бајти.

Тоа нешто е транспортниот слој на тунелот. Во TCP режим OpenVPN ги запишува инкапсулираните пакети во една TCP врска кон партнерот, а договорот на TCP е испорака по редослед на еден тек на бајти. Подоцнежните бајти не се предаваат на апликацијата пред оние што недостасуваат, без оглед на кој внатрешен разговор му припаѓаат.

Забележете што симптомот не го кажува. Не кажува дека патеката е расипана, дека серверот е преоптоварен или дека шифрирањето е бавно. Тие даваат други форми: рамномерно низок проток, истекување на време или дефекти што зафаќаат еден правец. Заедничката пауза што завршува кога изгубениот сегмент се преиспраќа е токму ефект на подредување.

Еден надворешен тек на бајти, многу внатрешни разговори

Замислете тунелот истовремено да носи преземање и школка. Еден сегмент од надворешната врска се губи. Следните сегменти можат да стигнат до домаќинот примач и стекот TCP што прима ќе ги потврди, но не може да ги предаде нагоре додека празнината не се пополни. Затоа OpenVPN нема што да чита за школката, иако бајтите на самата школка пристигнаа одамна.

Ова е блокада на почетокот од редот во една врска и не бара двете апликации да делат внатрешна врска. Тие ја делат надворешната, и тоа е доволно.

Ефектот од втор ред го влошува. Внатрешен испраќач што не гледа потврди може повторно да испрати податоци што надворешниот слој веќе се обидува да ги достави. Тоа преиспраќање станува дополнителен тунелски сообраќај на патека што штотуку докажа дека може да губи сегменти, па работата на опоравување се натпреварува со опоравувањето што е важно.

Ништо од ова не гарантира колапс. На чиста патека со кратки повратни патувања и широки редици, овој распоред може години да биде сосема употреблив. Дефектот се појавува кога загубата, доцнењето и длабочината на редот ќе се совпаднат, и затоа извештаите се групираат околу заситени нагорни врски и мобилни врски, а не околу добро опремени канцеларии.

Зошто подолг внатрешен тајмер не може да помогне

Подигнувањето на најмалото време за преиспраќање на патека со 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 на транспортниот сокет има тесна цел: ги спречува малите записи да чекаат повеќе податоци пред испраќање. Тоа му помага на интерактивниот сообраќај да избегне дополнително доцнење на инаку здрава патека.

Таа не го прави транспортот непореден и не го скратува опоравувањето по изгубен сегмент. Школката што запира поради истек на време за преиспраќање ќе запре и со вклучена опција, бидејќи опцијата никогаш не го допрела правилото за редослед.

Лесно е да се збунат двете бидејќи и двете се опишуваат како поправки на доцнење. Едната отстранува вештачко чекање што го воведува баферувањето, другата би барала менување на она што транспортот го гарантира, а тоа не го прави ниту една опција на сокетот.

Како правично да се споредат транспортите

Ако операторот дозволува и двете услуги постојат, споредете услуга UDP и услуга TCP што носат исто работно оптоварување по истата патека за пристап до истиот сервер. Менувањето земја, давател или генерација на серверот помеѓу двата теста внесува променлива што ќе доминира со резултатот.

Гледајте ја заедничката пауза, а не бројот на проток. Неколку внатрешни апликации што заглавуваат заедно за време на надворешна загуба е набљудувањето што ја препознава блокадата на почетокот од редот; еден понизок број на тест за брзина тоа не го прави.

Овластените снимки на интерфејсот на тунелот и на физичкиот интерфејс чисто ги раздвојуваат двата слоја, бидејќи внатрешните и надворешните преиспраќања припаѓаат на различни врски со различни редни простори. Да се видат внатрешни преиспраќања додека надворешниот тек покажува празнина е директен доказ.

Преминот на UDP го отстранува дополнителниот сигурен тек и му го остава на внатрешниот TCP да го направи сопствениот опоравок. Не ветува нулта загуба или ниско доцнење, а заситена нагорна врска, преголеми редици или проблем со MTU се уште ќе треба да се поправат. Сообраќајот надвор од тунелот никогаш не се задржува зад редната празнина на тунелот, иако може да настрада кога двете патеки делат една заситена врска, и тоа заедничко грло заслужува сопствена истрага наместо да се свитка во оваа.