Dideli atsisiuntimai prieš VPN: kelią rinkitės užklausoje

„Didelius atsisiuntimus siųsk aplink VPN, o mažus atsakymus laikyk ant jo“ skamba kaip maršrutizavimo politika, bet ja nėra. Maršrutizatorius sprendžia pagal tuo metu turimą informaciją: adresus, prievadus, protokolą, firewall žymes, identifikuotą srautą. Galutinis atsakymo dydis į šį rinkinį nepatenka, nes jis dar neatėjo, o kai maršrutizatorius galėtų išmatuoti baitus, jis jau juos perduoda. Jei norite valdyti pagal užduotį, sprendimas turi persikelti į tašką, kuris žino užduotį, o žemiau esantis kontrolinis sąrašas parodo, ar jūsų projekte yra toks taškas.

Kodėl maršrutizatorius negali išmatuoti atsakymo

Tuo metu, kai paketui reikia maršruto, maršrutizatorius yra matęs daugiausiai pirmuosius kelis srauto paketus. Jis gali pasakyti, kas su kuo kalba, kokiu protokolu, su kokia žyme ir kiek baitų jau praėjo. Iki šiol praėję baitai apibūdina praeitį. Atsakymo dydis yra dar nesukurto atsakymo savybė, o suskaidytuose ar srautiniuose atsakymuose jis gali būti niekada iš anksto nežinomas.

Net paties protokolo metaduomenys yra silpnesni, nei atrodo. HTTP leidžia atsakymus, kurių ilgis neskelbiamas prieš turinį, o vienas naudotojo veiksmas gali sukurti daug užklausų, kurių bendra kaina nepanaši į jokią vieną antraštės reikšmę. Laikyti antraštę užduoties dydžiu yra modeliavimo klaida anksčiau, nei tai būtų maršrutizavimo klaida.

Patikra 1: ar yra sprendimo taškas, galintis pasirinkti kelią?

Įvardykite komponentą, kuris atliks pasirinkimą, o tada įvardykite, ką ji žino pasirinkimo momentu. Atnaujinėjas, kuris atsisiunčia iš dokumentuoto hostų rinkinio, savo tikslą žino prieš prasidedant perdavimui. Atsisiuntimo paslauga, kuri pasižiūri metaduomenų ir tada atveria užklausą, žino užduotį prieš atsirandant ryšiui. Bendraujantis proxy gali taikyti užklausos lygio politiką arba talpinti atsakymą podėlyje, nevaizduodamas maršrutizatoriaus.

Jei atsakymas „šliuzas“, kontrolinis sąrašas jau žlugo. Šliuzas gali klasifikuoti žinomus srautus pagal paskirties vietą, žymę ar kliento segmentą ir siųsti juos nustatytu keliu nuo pirmo paketo, ko dažnai pakanka patvirtintam atnaujinėjui ir niekada nepakanka nežinomam atsakymo dydžiui.

Patikra 2: ką metaduomenys iš tikrųjų jums sako?

Programą suprantantis valdymas yra toks geras, kokie geri laukai, kuriuos jis skaito. HTTP semantika atsakymo ilgio taisyklės leidžia atvejus, kai ilgis pradžioje neprieinamas, o turinio kodavimai vis tiek padaro perduotų baitų skaičių skirtingą nuo pateikties dydžio. Todėl politika, kuri keičia kelią antraštei perkopus slenkstį, elgsis nenuosekliai, ir daugiausia būtent tuose dideliuose perdavimuose, kuriuos ji turėjo sugauti.

Tai, ką programos metaduomenys gali pagrįsti, yra sprendimas apie užduotį: šis darbo srautas yra masinis sinchronizavimas, šis interaktyvus, šis programinės įrangos atnaujinimas iš žinomo šaltinio. Tai politika, parašyta ketinimo terminais, ir ji pakankamai stabili, kad ją būtų galima testuoti. „Šis atsakymas bus didesnis nei keturiasdešimt megabaitų“ nėra tokia politika.

Patikra 3: ar srautas jau egzistuoja?

Maršrutizavimas gali pasikeisti srautui nekeičiant ryšio tapatybės, ir šį skirtumą verta išlaikyti tikslų. TCP ryšys identifikuojamas pagal jo galinių taškų adresus ir prievadus, o paketai gali eiti kitu keliu, jei maršrutizavimo lentelė pasikeičia po jais. Tai, kas negali pasikeisti nepastebimai, yra tinklo adresų vertimo būsena: perkėlus srautą į kitą išėjimą, paprastai pasikeičia viešasis šaltinio kortižas, o tolimoji pusė pamatys kitą partnerį be atitinkančios būsenos.

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

Taigi praktinė taisyklė: perkėlimas ryšio viduryje iš vieno išėjimo į kitą yra naujas santykis, o ne migracija. Jei projektas reikalauja, kad tas pats ryšys tęstųsi, sprendimas turėjo būti priimtas prieš pirmąjį SYN, ir jokia vėliau pridėta paketų taisyklė negali jo švariai atkurti.

Patikra 4: ar tikrasis reikalavimas yra vėlavimas, o ne išėjimas?

Labai daug prašymų „siųsk masinį srautą kitur“ iš tikrųjų yra skundai, kad didelis perdavimas interaktyvų darbą daro lėtą. Tai planavimo problema, ir ji turi planavimo atsakymą: teisinga eilė arba palaikoma pralaidumo politika esamame kelyje neleidžia masiniam srautui badauti pokalbio žinutės, neperkeliant nė vieno iš jų.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Taip sprendžiant simptomą, išėjimo sprendimas lieka ten, kur jį padėjo saugumo politika, ir jį galima atšaukti viena komanda. Išėjimo keitimas visai srauto klasei yra politikos pakeitimas, turintis pasekmių autentifikavimui, žurnalevimui ir prieigos taisyklėms, todėl tai neturėtų būti pirmas įrankis dėl vėlavimo skundžiantis.

Jei reikalavimas tikrai yra kitas interneto išėjimas, pasakykite tai tais pačiais žodžiais ir įgyvendinkite palaikomoje riboje: naujas ryšys iš patvirtinto darbo srauto arba programa, kuri atveria savo užklausą per pasirinktą išėjimą. Tada užrašykite, kurios užduotys naudoja kurį išėjimą, kad kitam žmogui nereikėtų to spręsti iš maršrutizavimo lentelės.

Laikykite kontrolinį sąrašą pakeitimo įraše: sprendimo tašką, jį varantį lauką ar užduotį, ar srautas jau egzistuoja ir ar išmatuotas simptomas buvo vėlavimas, ar išėjimas. Keturi klausimai, o politika, atsakanti į visus keturis, yra tokia, kurią galite valdyti, o ne ginti.