Velika preuzimanja protiv VPN-a: odaberite put kod zahtjeva
Usmjerivač ne može izmjeriti veličinu odgovora prije nego stigne. Usmjeravanje po zadatku traži točku odluke u aplikaciji ili politiku reda koja zadržava postojeći put.
„Pošaljite velika preuzimanja oko VPN-a, a male odgovore zadržite na njemu“ zvuči kao politika usmjeravanja, ali nije. Usmjerivač odlučuje s informacijama dostupnima u tom trenutku: adrese, portovi, protokol, oznake firewalla, identificirani tok. Konačna veličina odgovora nije u tom skupu jer još nije stigla, a kad bi usmjerivač mogao izmjeriti bajtove, već ih prenosi. Ako želite usmjeravanje po zadatku, odluka se mora preseliti u točku koja poznaje zadatak, a kontrolni popis u nastavku pokazuje ima li vaš dizajn takvu točku.
Zašto usmjerivač ne može izmjeriti odgovor
U trenutku kad paketu treba ruta, usmjerivač je vidio najviše prvih nekoliko paketa toka. Može reći tko s kim razgovara, kojim protokolom, s kojom oznakom i koliko je bajtova dosad prošlo. Dosadašnji bajtovi opisuju prošlost. Veličina odgovora svojstvo je odgovora koji još nije nastao, a kod podijeljenih ili streaming odgovora možda nikad nije poznata unaprijed.
Čak su i vlastiti metapodaci protokola slabiji nego što izgledaju. HTTP dopušta odgovore čija se duljina ne najavljuje prije tijela, a jedna korisnička radnja može proizvesti mnogo zahtjeva čiji zajednički trošak ne nalikuje nijednoj vrijednosti zaglavlja. Tretirati zaglavlje kao veličinu zadatka pogreška je modeliranja prije nego pogreška usmjeravanja.
Provjera 1: postoji li točka odluke koja može odabrati put?
Navedite komponentu koja će obaviti odabir, a zatim navedite što zna u trenutku odabira. Program za ažuriranje koji preuzima s dokumentiranog skupa hostova zna svoju svrhu prije početka prijenosa. Usluga preuzimanja koja pregleda metapodatke pa otvori zahtjev zna zadatak prije nego veza postoji. Suradni proxy može primijeniti politiku na razini zahtjeva ili predmemorirati odgovor bez pretvaranja da je usmjerivač.
Ako je odgovor „gateway“, kontrolni popis već je pao. Gateway može klasificirati poznate tokove prema odredištu, oznaci ili segmentu klijenta i poslati ih definiranim putem od prvog paketa, što je često dovoljno za odobren program za ažuriranje, a nikad nije dovoljno za nepoznatu veličinu odgovora.
Provjera 2: što vam metapodaci stvarno govore?
Usmjeravanje svjesno aplikacije samo je toliko dobro koliko su dobra polja koja čita. Pravila duljine odgovora u semantika HTTP-a dopuštaju slučajeve u kojima duljina nije dostupna na početku, a kodiranja sadržaja ionako čine broj prenesenih bajtova različitim od veličine prikaza. Zato će se politika koja mijenja put kad zaglavlje prijeđe prag ponašati nedosljedno, i to uglavnom upravo na velikim prijenosima koje je trebala uhvatiti.
Ono što aplikacijski metapodaci mogu podržati jest odluka o zadatku: ovaj je tijek rada skupna sinkronizacija, ovaj je interaktivan, ovaj je ažuriranje softvera s poznatog izvora. To je politika napisana u terminima namjere i dovoljno je stabilna za testiranje. „Ovaj će odgovor biti veći od četrdeset megabajta“ nije takva politika.
Provjera 3: postoji li tok već?
Usmjeravanje se može promijeniti za tok bez promjene identiteta veze, i tu razliku vrijedi držati jasnom. TCP veza identificirana je adresama i portovima svojih krajeva, a paketi mogu krenuti drugim putem ako se tablica usmjeravanja promijeni ispod njih. Ono što se ne može promijeniti nevidljivo jest stanje prevođenja mrežnih adresa: premještanje prometa na drugi izlaz obično mijenja javnu izvornu torku, a udaljena će strana vidjeti drugog partnera bez odgovarajućeg stanja.
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10
Praktično pravilo jest da je premještanje usred veze s jednog izlaza na drugi novi odnos, a ne migracija. Ako dizajn zahtijeva da se ista veza nastavi, odluka je morala biti donesena prije prvog SYN-a, i nijedno pravilo paketa dodano poslije ne može je čisto rekonstruirati.
Provjera 4: je li stvarni zahtjev latencija, a ne izlaz?
Vrlo mnogo zahtjeva „pošaljite skupni promet negdje drugdje“ zapravo su pritužbe da veliki prijenos čini interaktivni rad sporim. To je problem raspoređivanja i ima odgovor raspoređivanja: pravedan red ili podržana politika propusnosti na postojećem putu sprječava da skupni tok izgladni chat poruku bez premještanja ijednog od njih.
tc qdisc replace dev eth0 root cake bandwidth 100mbit
Rješavanje simptoma na ovaj način ostavlja odluku o izlazu tamo gdje ju je sigurnosna politika postavila, i može se poništiti jednom naredbom. Promjena izlaza za cijelu klasu prometa promjena je politike s posljedicama za autentifikaciju, zapisivanje i pravila pristupa, pa ne bi trebala biti prvi alat pri pritužbi na latenciju.
Ako je zahtjev doista drugi internetski izlaz, recite to tim riječima i provedite ga na podržanoj granici: nova veza iz odobrenog tijeka rada ili aplikacija koja otvara vlastiti zahtjev kroz odabrani izlaz. Zatim zabilježite koje zadatke koriste koji izlaz, da sljedeća osoba to ne mora zaključivati iz tablice usmjeravanja.
Držite kontrolni popis u zapisu promjene: točku odluke, polje ili zadatak koji ju pokreće, postoji li tok već i je li izmjereni simptom bila latencija ili izlaz. Četiri pitanja, a politika koja odgovara na sva četiri je ona kojom možete upravljati, a ne je braniti.