Nagy letöltések kontra VPN: a kérésnél válasszunk útvonalat

„A nagy letöltéseket küldd a VPN mellett, a kis válaszokat tartsd rajta” útválasztási irányelvnek hangzik, de nem az. A router az abban a pillanatban rendelkezésre álló információval dönt: címek, portok, protokoll, firewall-jelölések, azonosított folyam. A válasz végleges mérete nincs ebben a halmazban, mert még nem érkezett meg, és mire a router megmérhetné a bájtokat, már szállítja őket. Ha feladat szerint akar irányítani, a döntésnek olyan pontra kell kerülnie, amely ismeri a feladatot, és az alábbi ellenőrzőlista megmutatja, van-e ilyen pont a tervezésében.

Miért nem tud egy router választ mérni

Abban a pillanatban, amikor egy csomagnak útvonalra van szüksége, a router legfeljebb egy folyam első néhány csomagját látta. Meg tudja mondani, ki kivel beszél, milyen protokollon, milyen jelöléssel, és hány bájt haladt át eddig. Az eddigi bájtok a múltat írják le. A válasz mérete egy még meg nem született válasz tulajdonsága, és a darabolt vagy streamelt válaszok esetében talán soha nem tudható előre.

Még a protokoll saját metaadatai is gyengébbek, mint amilyennek látszanak. A HTTP engedélyez olyan válaszokat, amelyek hosszát nem hirdetik meg a törzs előtt, és egyetlen felhasználói művelet sok kérést hozhat létre, amelyek együttes költsége semmilyen fejlécértékhez nem hasonlít. Egy fejlécet a feladat méreteként kezelni modellezési hiba, mielőtt útválasztási hiba lenne.

1. ellenőrzés: van-e olyan döntési pont, amely útvonalat választhat?

Nevezze meg a komponenst, amely a választást hozza, majd nevezze meg, mit tud a választás pillanatában. Egy frissítő, amely dokumentált hosztkészletről tölt le, az átvitel kezdete előtt ismeri a célját. Egy letöltési szolgáltatás, amely metaadatokat néz meg, majd megnyitja a kérést, a kapcsolat létrejötte előtt ismeri a feladatot. Egy együttműködő proxy kérés szintű szabályt alkalmazhat, vagy gyorsítótárazhatja a választ anélkül, hogy routernek adná ki magát.

Ha a válasz „az átjáró”, az ellenőrzőlista már megbukott. Az átjáró ismert folyamokat sorolhat be cél, jelölés vagy kliensszegmens szerint, és az első csomagtól meghatározott útvonalra küldheti őket, ami gyakran elég egy jóváhagyott frissítőnek, és soha nem elég egy ismeretlen válaszméretnek.

2. ellenőrzés: mit mondanak valójában a metaadatok?

Az alkalmazástudatos irányítás csak annyira jó, mint a mezők, amelyeket olvas. A a HTTP szemantikája válaszhossz-szabályai engedélyeznek olyan eseteket, amikor a hossz a kezdetben nem elérhető, és a tartalomkódolás amúgy is különbözővé teszi az átvitt bájtok számát a reprezentáció méretétől. Ezért a fejléc küszöbátlépésekor útvonalat váltó irányelv következetlenül fog viselkedni, és főleg éppen azoknál a nagy átviteleknél, amelyeket el kellett volna kapnia.

Amit az alkalmazásmetaadatok támogatni tudnak, az egy feladatra vonatkozó döntés: ez a munkafolyamat tömeges szinkronizálás, ez interaktív, ez egy ismert forrásból származó szoftverfrissítés. Ez szándéknyelven írt irányelv, és elég stabil a teszteléshez. „Ez a válasz nagyobb lesz negyven megabájtnál” nem ilyen irányelv.

3. ellenőrzés: létezik-e már a folyam?

Az útválasztás változhat egy folyam számára a kapcsolat identitásának megváltoztatása nélkül, és ezt a különbséget érdemes tisztán tartani. A TCP-kapcsolatot végpontjainak címei és portjai azonosítják, és a csomagok más útvonalra kerülhetnek, ha az útválasztási tábla alattuk megváltozik. Ami nem változhat láthatatlanul, az a hálózaticím-fordítás állapota: a forgalom más kimenetre helyezése általában megváltoztatja a nyilvános forrástuple-t, és a távoli fél más partnert fog látni megfelelő állapot nélkül.

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

A gyakorlati szabály tehát az, hogy a kapcsolat közbeni áthelyezés egyik kimenetről a másikra új kapcsolat, nem migráció. Ha a tervezés megköveteli, hogy ugyanaz a kapcsolat folytatódjon, a döntést az első SYN előtt kellett meghozni, és semmilyen később hozzáadott csomagszabály nem tudja tisztán újraépíteni.

4. ellenőrzés: a valódi követelmény a késleltetés, nem a kimenet?

Nagyon sok „küldd a tömeges forgalmat máshová” kérés valójában panasz arra, hogy egy nagy átvitel lassúnak érzeteti az interaktív munkát. Ez ütemezési probléma, és van ütemezési válasza: egy méltányos sor vagy a meglévő útvonalon támogatott sávszélesség-szabály megakadályozza, hogy egy tömeges folyam éheztessen egy csevegőüzenetet anélkül, hogy bármelyiket áthelyezné.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

A tünet ilyen kezelése ott hagyja a kimeneti döntést, ahol a biztonsági irányelv elhelyezte, és egyetlen paranccsal visszafordítható. A kimenet megváltoztatása egy egész forgalmi osztály számára olyan irányelvváltozás, amelynek hitelesítési, naplózási és hozzáférési szabálykövetkezményei vannak, ezért nem szabadna az első eszköznek lennie egy késleltetési panasz esetén.

Ha a követelmény valóban más internetes kimenet, mondja ki ezekkel a szavakkal, és támogatott határon valósítsa meg: új kapcsolat jóváhagyott munkafolyamatból, vagy olyan alkalmazás, amely a saját kérését egy kiválasztott kimeneten nyitja meg. Ezután rögzítse, mely feladatok melyik kimenetet használják, hogy a következő embernek ne kelljen az útválasztási táblából kikövetkeztetnie.

Tartsa az ellenőrzőlistát a változás feljegyzésében: a döntési pontot, az őt vezérlő mezőt vagy feladatot, hogy a folyam már létezik-e, és hogy a mért tünet késleltetés vagy kimenet volt-e. Négy kérdés, és az az irányelv, amely mind a négyre válaszol, olyan, amelyet üzemeltetni lehet, nem pedig védeni.