Големите изтегляния срещу VPN: изберете пътя при заявката

„Изпращайте големите изтегляния около VPN и задръжте малките отговори върху него“ звучи като политика за маршрутизиране, но не е. Маршрутизаторът решава с информация, налична в този момент: адреси, портове, протокол, маркировки на firewall, идентифициран поток. Крайният размер на отговора не е в този набор, защото той още не е пристигнал и докато маршрутизаторът успее да измери байтовете, той вече ги пренася. Ако искате насочване по задача, решението трябва да се премести в точка, която познава задачата, а списъкът по-долу показва дали дизайнът ви има такава точка.

Защо маршрутизаторът не може да определи размера на отговора

В момента, в който пакетът се нуждае от маршрут, маршрутизаторът е видял най-много първите няколко пакета от потока. Той може да каже кой с кого говори, по кой протокол, с каква маркировка и колко байта са преминали досега. Байтовете досега описват миналото. Размерът на отговора е свойство на отговор, който още не е генериран, а при раздробени или поточни отговори може никога да не бъде знаен предварително.

Дори собствената метаинформация на протокола е по-слаба, отколкото изглежда. HTTP допуска отговори, чиято дължина не се обявява преди тялото, а едно потребителско действие може да създаде много заявки, чиято обща цена не прилича на нито една стойност на заглавка. Да се третира заглавка като размер на задача е грешка в моделирането преди да е грешка в маршрутизирането.

Проверка 1: има ли точка за решение, която може да избере път?

Назовете компонента, който ще направи избора, после назовете какво знае в момента на избора. Обновяващ агент, който тегли от документиран набор хостове, знае целта си преди трансферът да започне. Услуга за изтегляне, която преглежда метаданни и после отваря заявката, знае задачата преди връзката да съществува. Съдействащ proxy може да прилага политика на ниво заявка или да кешира отговора, без да се представя за маршрутизатор.

Ако отговорът е „шлюзът“, списъкът вече се е провалил. Шлюзът може да класифицира известни потоци по дестинация, маркировка или клиентски сегмент и да ги изпрати по определен път от първия пакет, което често е достатъчно за одобрен обновяващ агент и никога не е достатъчно за неизвестен размер на отговор.

Проверка 2: какво всъщност ви казват метаданните?

Насочването с оглед на приложението е толкова добро, колкото са полетата, които чете. Правилата за дължина на отговора в семантиката на HTTP допускат случаи, в които дължината не е налична в началото, а кодирането на съдържанието така или иначе прави броя прехвърлени байтове различен от размера на представянето. Затова политика, която сменя пътя при преминаване на заглавка през праг, ще се държи непоследователно и най-вече точно при големите трансфери, които е трябвало да хване.

Това, което метаданните на приложението могат да подкрепят, е решение за задача: този работен процес е групова синхронизация, този е интерактивен, този е софтуерна актуализация от известен източник. Това е политика, написана на езика на намерението, и е достатъчно стабилна за тестване. „Този отговор ще бъде по-голям от четиридесет мегабайта“ не е такава политика.

Проверка 3: потокът вече съществува ли?

Маршрутизирането може да се промени за поток, без да се промени идентичността на връзката, и това е разлика, която си струва да се пази. TCP връзката се идентифицира с адресите и портовете на крайните точки, а пакетите могат да поемат различен път, ако таблицата за маршрутизиране се промени под тях. Това, което не може да се промени незабележимо, е състоянието за транслация на мрежови адреси: преместването на трафика към друг изход обикновено променя публичния кортеж на източника и отсрещната страна ще види различен партньор без съответстващо състояние.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Затова практичното правило е, че преместване по средата на връзката от един изход към друг е нова връзка, а не миграция. Ако дизайнът изисква същата връзка да продължи, решението е трябвало да бъде взето преди първия SYN и никое добавено по-късно правило за пакети не може да го възстанови чисто.

Проверка 4: истинското изискване закъснение ли е, а не изход?

Много голяма част от заявките „изпратете груповия трафик другаде“ всъщност са оплаквания, че голям трансфер прави интерактивната работа бавна. Това е проблем на планирането и има отговор от планирането: справедливо опашковане или поддържана политика за честотната лента по съществуващия път не позволява на групов поток да изгладни съобщение в чата, без да мести нито един от двата.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Такава работа със симптома оставя решението за изхода там, където сигурностната политика го е поставила, и е обратима с една команда. Смяната на изхода за цял клас трафик е промяна на политиката с последствия за удостоверяването, журналирането и правилата за достъп, затова не бива да е първият инструмент при оплакване от закъснение.

Ако изискването наистина е различен интернет изход, кажете го с тези думи и го реализирайте на поддържана граница: нова връзка от одобрен работен процес или приложение, което отваря собствената си заявка през избран изход. После запишете кои задачи кой изход ползват, за да не се налага следващият човек да го извежда от таблица за маршрутизиране.

Пазете списъка в записа за промяната: точката на решение, полето или задачата, която я задвижва, дали потокът вече съществува и дали измереният симптом е закъснение или изход. Четири въпроса и политика, която отговаря на четирите, е такава, която може да се експлоатира, а не да се защитава.