Suured allalaadimised versus VPN: vali tee päringu juures

„Saada suured allalaadimised VPN-ist mööda ja hoia väikesed vastused selle peal“ kõlab marsruutimispoliitikana, kuid ei ole seda. Ruuter otsustab sellel hetkel kättesaadava teabe põhjal: aadressid, pordid, protokoll, firewall-märgised, tuvastatud voog. Vastuse lõplik suurus ei kuulu sellesse hulka, sest see pole veel saabunud, ja selleks ajaks, kui ruuter saaks baite mõõta, kannab ta neid juba. Kui soovid ülesande järgi suunata, peab otsus liikuma punkti, mis ülesannet teab, ja allolev kontrollnimekiri näitab, kas sinu kujunduses on selline punkt.

Miks ruuter ei saa vastust mõõta

Hetkel, mil pakett vajab marsruuti, on ruuter näinud kõige rohkem voo paari esimest paketti. Ta oskab öelda, kes kellega räägib, mis protokollil, mis märgisega ja kui palju baite on seni liikunud. Senised baidid kirjeldavad minevikku. Vastuse suurus on veel loomata vastuse omadus ja tükeldatud või voogedastusvastuste puhul ei pruugi see kunagi ette teada olla.

Isegi protokolli enda metaandmed on nõrgemad, kui paistavad. HTTP lubab vastuseid, mille pikkust ei teatata enne keha, ja üks kasutajatoiming võib tekitada palju päringuid, mille koondkulu ei sarnane ühegi päise väärtusega. Päist ülesande suuruseks pidada on modelleerimisviga enne, kui see on marsruutimisviga.

Kontroll 1: kas on otsustuspunkt, mis suudab tee valida?

Nimetage komponent, mis valiku teeb, ja seejärel nimetage, mida see valiku hetkel teab. Uuendaja, mis toob dokumenteeritud hostide hulgast, teab oma eesmärki enne ülekande algust. Allalaadimisteenus, mis uurib metaandmeid ja avab seejärel päringu, teab ülesannet enne ühenduse tekkimist. Koostöövõimeline proxy saab rakendada päringutasandi poliitikat või vastust vahemällu salvestada, teeseldes seejuures mitte ruuterit.

Kui vastus on „lüüs“, on kontrollnimekiri juba läbi kukkunud. Lüüs saab liigitada tuntud voogusid sihtkoha, märgise või kliendisegmendi järgi ja saata need esimesest paketist kindlaksmääratud teele, mis on heakskiidetud uuendaja jaoks sageli piisav ja tundmatu vastuse suuruse jaoks kunagi mitte.

Kontroll 2: mida metaandmed sulle tegelikult ütlevad?

Rakenduseteadlik suunamine on nii hea kui väljad, mida see loeb. HTTP semantika vastuse pikkuse reeglid lubavad juhtumeid, kus pikkus pole alguses saadaval, ja sisukodeeringud teevad üle kantud baitide arvu ikkagi esituse suurusest erinevaks. Seetõttu käitub poliitika, mis vahetab teed, kui päis ületab lävendi, ebajärjekindlalt, ja peamiselt just nendel suurtel ülekannetel, mida see pidi tabama.

Mida rakenduse metaandmed toetada saavad, on otsus ülesande kohta: see töövoog on hulgisünkroonimine, see on interaktiivne, see on tarkvarauuendus tuntud allikast. See on kavatsuse keeles kirjutatud poliitika ja piisavalt stabiilne, et seda testida. „See vastus on suurem kui nelikümmend megabaiti“ ei ole selline poliitika.

Kontroll 3: kas voog on juba olemas?

Marsruutimine võib voo jaoks muutuda ilma ühenduse identiteeti muutmata, ja see erinevus tasub selgelt hoida. TCP-ühendus on tuvastatav oma otspunktide aadresside ja portidega ning paketid võivad minna teist teed, kui marsruutimistabel nende all muutub. Mis ei saa märkamatult muutuda, on võrgu aadressitõlke olek: liikluse viimine teise väljundisse muudab tavaliselt avalikku lähtekorteeži ja kaugem pool näeb teist partnerit, kellel pole vastavat olekut.

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

Nii et praktiline reegel on: ühenduse keskel ühest väljundist teise liikumine on uus suhe, mitte migratsioon. Kui kujundus nõuab, et sama ühendus jätkuks, oleks otsus tulnud teha enne esimest SYN-i, ja hiljem lisatud paketireegel ei suuda seda puhtalt taastada.

Kontroll 4: kas tegelik nõue on latentsus, mitte väljund?

Väga paljud palved „saada hulgiliiklus mujale“ on tegelikult kaebused, et suur ülekanne muudab interaktiivse töö aeglaseks. See on ajastamise probleem ja sellel on ajastamise vastus: õiglane järjekord või toetatud ribalaiusepoliitika olemasoleval teel hoiab hulgivoo vestlussõnumi näljutamast, kumbagi liigutamata.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Sümptomi selline käsitlemine jätab väljundi otsuse sinna, kuhu turbepoliitika selle pani, ja see on ühe käsuga tagasipööratav. Väljundi muutmine tervele liiklusklassile on poliitikamuudatus, millel on tagajärjed autentimisele, logimisele ja juurdepääsureeglitele, seega ei tohiks see olla esimene tööriist latentsuse kaebuse puhul.

Kui nõue on tõesti teine internetiväljund, öelge seda nende sõnadega ja rakendage seda toetatud piiril: uus ühendus heakskiidetud töövoost või rakendus, mis avab oma päringu valitud väljundi kaudu. Seejärel kirjutage üles, millised ülesanded millist väljundit kasutavad, et järgmine inimene ei peaks seda marsruutimistabelist tuletama.

Hoidke kontrollnimekiri muudatuse kirjes: otsustuspunkt, seda juhtiv väli või ülesanne, kas voog on juba olemas ja kas mõõdetud sümptom oli latentsus või väljund. Neli küsimust, ja poliitika, mis vastab kõigile neljale, on selline, mida saab käitada, mitte kaitsta.