Велика преузимања наспрам VPN-а: изаберите пут код захтева

„Пошаљи велика преузимања око VPN-а, а мале одговоре задржи на њему“ звучи као политика усмеравања, али није. Рутер одлучује са информацијама доступним у том тренутку: адресе, портови, протокол, ознаке firewall-а, идентификован ток. Коначна величина одговора није у том скупу, јер он још није стигао, а када би рутер могао да измери бајтове, већ их преноси. Ако желите усмеравање по задатку, одлука мора да се пресели у тачку која познаје задатак, а контролна листа испод показује да ли ваш дизајн има такву тачку.

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

У тренутку када пакету треба рута, рутер је видео највише првих неколико пакета тока. Може да каже ко са ким разговара, којим протоколом, са којом ознаком и колико је бајтова досад прошло. Досадашњи бајтови описују прошлост. Величина одговора је својство одговора који још није настао, а код подељених или стриминг одговора можда никада није позната унапред.

Чак су и сопствени метаподаци протокола слабији него што изгледају. HTTP дозвољава одговоре чија се дужина не најављује пре тела, а једна корисничка радња може да произведе много захтева чија заједничка цена не личи ни на једну вредност заглавља. Третирати заглавље као величину задатка је грешка у моделирању пре него грешка у усмеравању.

Провера 1: постоји ли тачка одлуке која може да изабере пут?

Наведите компоненту која ће обавити избор, а затим наведите шта зна у тренутку избора. Програм за ажурирање који преузима са документованог скупа хостова зна своју сврху пре почетка преноса. Услуга преузимања која прегледа метаподатке па отвори захтев зна задатак пре него што веза постоји. Сараднички proxy може да примени политику на нивоу захтева или да кешира одговор без претварања да је рутер.

Ако је одговор „gateway“, контролна листа је већ пала. Gateway може да класификује познате токове према одредишту, ознаци или сегменту клијента и пошаље их дефинисаним путем од првог пакета, што је често довољно за одобрен програм за ажурирање и никада није довољно за непознату величину одговора.

Провера 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

Овакав приступ симптому оставља одлуку о излазу тамо где ју је поставила безбедносна политика, и може се поништити једном командом. Промена излаза за целу класу саобраћаја је промена политике са последицама по аутентификацију, евидентирање и правила приступа, па не би требало да буде први алат при жалби на кашњење.

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

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