Veľké sťahovania verzus VPN: cestu vyberte už pri požiadavke

„Veľké sťahovania pošli mimo VPN a malé odpovede na nej nechaj“ znie ako smerovacia politika, ale nie je. Router rozhoduje podľa informácií dostupných v danom okamihu: adresy, porty, protokol, značky firewallu, identifikovaný tok. Konečná veľkosť odpovede v tejto množine nie je, lebo ešte nedorazila, a kým by router mohol bajty zmerať, už ich prenáša. Ak chcete smerovať podľa úlohy, rozhodnutie sa musí presunúť do bodu, ktorý úlohu pozná, a kontrolný zoznam nižšie ukazuje, či váš návrh taký bod má.

Prečo router nemôže zmerať odpoveď

V okamihu, keď paket potrebuje trasu, videl router nanajvýš prvé niekoľko paketov toku. Môže povedať, kto s kým hovorí, akým protokolom, s ktorou značkou a koľko bajtov doteraz prešlo. Doterajšie bajty opisujú minulosť. Veľkosť odpovede je vlastnosť odpovede, ktorá ešte nevznikla, a pri členených alebo streamovaných odpovediach ju možno nikdy nemožno poznať vopred.

Aj vlastné metadáta protokolu sú slabšie, než sa zdá. HTTP povoľuje odpovede, ktorých dĺžka sa pred telom neoznamuje, a jediná akcia používateľa môže vytvoriť veľa požiadaviek, ktorých spoločná cena sa nepodobá žiadnej hodnote hlavičky. Považovať hlavičku za veľkosť úlohy je chyba modelu skôr, než je chybou smerovania.

Kontrola 1: existuje rozhodovací bod, ktorý vie vybrať cestu?

Pomenujte komponent, ktorý voľbu vykoná, a potom pomenujte, čo vie v okamihu voľby. Aktualizátor, ktorý sťahuje z dokumentovanej množiny hostiteľov, pozná svoj účel pred začiatkom prenosu. Služba sťahovania, ktorá nahliadne do metadát a potom otvorí požiadavku, pozná úlohu pred vznikom spojenia. Spolupracujúca proxy môže uplatniť politiku na úrovni požiadavky alebo odpoveď ukladať do vyrovnávacej pamäte bez toho, aby predstierala, že je router.

Ak znie odpoveď „brána“, kontrolný zoznam už zlyhal. Brána vie klasifikovať známe toky podľa cieľa, značky alebo klientskeho segmentu a poslať ich definovanou cestou od prvého paketu, čo často stačí schválenému aktualizátoru a nikdy nepostačuje neznámej veľkosti odpovede.

Kontrola 2: čo vám metadáta skutočne hovoria?

Smerovanie s ohľadom na aplikáciu je také dobré, aké dobré sú polia, ktoré číta. Pravidlá dĺžky odpovede v sémantika HTTP pripúšťajú prípady, keď dĺžka nie je na začiatku dostupná, a kódovanie obsahu robí počet prenesených bajtov odlišný od veľkosti reprezentácie tak či tak. Preto sa politika, ktorá prepne cestu, keď hlavička prekročí prah, bude správať nekonzistentne, a to hlavne práve pri veľkých prenosoch, ktoré mala zachytiť.

Čo môžu metadáta aplikácie podporiť, je rozhodnutie o úlohe: tento postup je hromadná synchronizácia, tento je interaktívny, tento je aktualizácia softvéru zo známeho zdroja. To je politika písaná v reči zámeru a je dosť stabilná na to, aby sa dala testovať. „Táto odpoveď bude väčšia ako štyridsať megabajtov“ takou politikou nie je.

Kontrola 3: existuje tok už teraz?

Smerovanie sa môže pre tok zmeniť bez zmeny identity spojenia, a ten rozdiel sa oplatí držať presne. Spojenie TCP je určené adresami a portmi svojich koncov a pakety môžu ísť inou cestou, ak sa pod nimi zmení smerovacia tabuľka. Čo sa nemôže zmeniť neviditeľne, je stav prekladu sieťových adries: presun prevádzky na iný výstup zvyčajne zmení verejnú zdrojovú n-ticu a vzdialená strana uvidí iného partnera bez zodpovedajúceho stavu.

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

Praktické pravidlo teda je, že presun v strede spojenia z jedného výstupu na druhý je nový vzťah, nie migrácia. Ak návrh vyžaduje, aby to isté spojenie pokračovalo, rozhodnutie sa malo prijať pred prvým SYN a žiadne neskôr pridané pravidlo paketov to čisto nezrekonštruuje.

Kontrola 4: je skutočnou požiadavkou latencia, nie výstup?

Veľmi veľa požiadaviek „pošlite hromadnú prevádzku inam“ sú v skutočnosti sťažnosti, že veľký prenos spôsobuje, že interaktívna práca sa zdá pomalá. To je problém plánovania a má plánovaciu odpoveď: spravodlivé radienie do frontov alebo podporovaná politika šírky pásma na existujúcej ceste zabráni hromadnému toku vyhladovať správu v chate bez presunu kohokoľvek z nich.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Takéto riešenie symptómu necháva rozhodnutie o výstupe tam, kde ho postavila bezpečnostná politika, a je vratné jediným príkazom. Zmena výstupu pre celú triedu prevádzky je zmena politiky s dôsledkami pre autentizáciu, protokolovanie a pravidlá prístupu, takže by nemala byť prvým nástrojom pri sťažnosti na latenciu.

Ak je požiadavka skutočne iný internetový výstup, povedzte to tými slovami a zrealizujte to na podporovanej hranici: nové spojenie zo schváleného postupu alebo aplikácia, ktorá otvorí vlastnú požiadavku cez zvolený výstup. Potom zaznamenajte, ktoré úlohy používajú ktorý výstup, aby to ďalší človek nemusel odvodzovať zo smerovacej tabuľky.

Uchovajte kontrolný zoznam v zázname o zmene: rozhodovací bod, pole alebo úlohu, ktorá ho riadi, či tok už existuje a či meraný symptom bola latencia alebo výstup. Štyri otázky a politika, ktorá odpovedá na všetky štyri, je tá, ktorú môžete prevádzkovať, nie obhajovať.