Засичания на 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 все още ще трябва да се оправят. Трафикът извън тунела никога не се задържа зад празнината в последователността на тунела, макар че може да пострада, когато двата пътя споделят една претоварена връзка, и това споделено тясно място заслужава собствено разследване, вместо да бъде пригънато към това.