Velká stahování versus VPN: cestu vyberte už u požadavku

„Velké stahování pošli mimo VPN a malé odpovědi na ní nech“ zní jako směrovací politika, ale není. Router rozhoduje podle informací dostupných v daném okamžiku: adresy, porty, protokol, značky firewallu, identifikovaný tok. Konečná velikost odpovědi v této množině není, protože ještě nedorazila, a než by router mohl bajty změřit, už je přenáší. Pokud chcete směrovat podle úlohy, rozhodnutí se musí přesunout do bodu, který úlohu zná, a kontrolní seznam níže ukazuje, zda váš návrh takový bod má.

Proč router nemůže změřit odpověď

V okamžiku, kdy paket potřebuje trasu, viděl router nanejvýš první několik paketů toku. Může říct, kdo s kým mluví, jakým protokolem, se kterou značkou a kolik bajtů už proteklo. Bajty dosud popisují minulost. Velikost odpovědi je vlastnost odpovědi, která ještě nevznikla, a u částečných nebo streamovaných odpovědí ji možná nikdy nelze předem znát.

I vlastní metadata protokolu jsou slabší, než se zdá. HTTP povoluje odpovědi, jejichž délka se před tělem neoznamuje, a jediná akce uživatele může vytvořit mnoho požadavků, jejichž souhrnná cena se nepodobá žádné hodnotě hlavičky. Považovat hlavičku za velikost úlohy je chyba modelu dřív než chyba směrování.

Kontrola 1: existuje rozhodovací bod, který umí vybrat cestu?

Pojmenujte komponentu, která volbu provede, a potom pojmenujte, co ví v okamžiku volby. Aktualizátor, který stahuje z dokumentované sady hostitelů, zná svůj účel dřív, než přenos začne. Služba stahování, která nahlédne do metadat a pak otevře požadavek, zná úlohu dřív, než spojení existuje. Spolupracující proxy může uplatnit politiku na úrovni požadavku nebo odpověď cachovat, aniž by předstíral, že je router.

Pokud zní odpověď „brána“, kontrolní seznam už selhal. Brána umí klasifikovat známé toky podle cíle, značky nebo klientského segmentu a poslat je definovanou cestou od prvního paketu, což často stačí pro schválený aktualizátor a nikdy nestačí pro neznámou velikost odpovědi.

Kontrola 2: co vám metadata skutečně říkají?

Směrování s ohledem na aplikaci je tak dobré, jak dobrá jsou pole, která čte. Pravidla délky odpovědi v sémantika HTTP připouštějí případy, kdy délka není na začátku k dispozici, a kódování obsahu stejně dělá počet přenesených bajtů odlišný od velikosti reprezentace. Politika, která přepne cestu, když hlavička překročí práh, se proto bude chovat nekonzistentně, a to hlavně právě u velkých přenosů, které měla zachytit.

Co metadata aplikace podpořit mohou, je rozhodnutí o úloze: tento postup je hromadná synchronizace, tento je interaktivní, tento je aktualizace softwaru ze známého zdroje. To je politika psaná v řeči záměru a je dost stabilní na to, aby se dala testovat. „Tato odpověď bude větší než čtyřicet megabajtů“ takovou politikou není.

Kontrola 3: existuje tok už teď?

Směrování se může pro tok změnit, aniž by se změnila identita spojení, a to je rozdíl, který stojí za to držet rovně. Spojení TCP je určeno adresami a porty koncových bodů a pakety mohou jít jinou cestou, pokud se pod nimi změní směrovací tabulka. Co se nemůže změnit neviditelně, je stav překladu síťových adres: přesun provozu na jiný výstup obvykle změní veřejnou zdrojovou n-tici a vzdálený konec uvidí jiného protějška bez odpovídajícího 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 tedy je, že přesun uprostřed spojení z jednoho výstupu na jiný je nový vztah, nikoli migrace. Pokud návrh vyžaduje, aby stejné spojení pokračovalo, muselo se rozhodnout před prvním SYN a žádné později přidané pravidlo paketů to čistě nezrekonstruuje.

Kontrola 4: je skutečným požadavkem latence, ne výstup?

Velmi mnoho požadavků „pošlete hromadný provoz jinam“ jsou ve skutečnosti stížnosti, že velký přenos zdržuje interaktivní práci. To je problém plánování a má plánovací odpověď: spravedlivé řazení do front nebo podporovaná politika šířky pásma na stávající cestě zabrání tomu, aby hromadný tok vyhladověl zprávu v chatu, aniž by se jeden z nich přesunul.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Řešit symptom tímto způsobem nechává rozhodnutí o výstupu tam, kam ho postavila bezpečnostní politika, a je vratné jedním příkazem. Změna výstupu pro celou třídu provozu je změna politiky s důsledky pro autentizaci, protokolování a přístupová pravidla, takže by neměla být prvním nástrojem při stížnosti na latenci.

Pokud je požadavek skutečně jiný internetový výstup, řekněte to těmito slovy a realizujte to na podporované hranici: nové spojení ze schváleného postupu, nebo aplikace, která otevře vlastní požadavek přes zvolený výstup. Pak zaznamenejte, které úlohy používají který výstup, aby to další člověk nemusel odvozovat ze směrovací tabulky.

Uchovejte kontrolní seznam v záznamu o změně: rozhodovací bod, pole nebo úlohu, která ho řídí, zda tok už existuje a zda měřený symptom byla latence, nebo výstup. Čtyři otázky a politika, která odpovídá na všechny čtyři, je ta, kterou můžete provozovat, místo abyste ji obhajovali.