Големи преземања наспроти 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

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

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

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