Suuret lataukset vastaan VPN: valitse polku pyynnössä

“Lähetä suuret lataukset VPN:n ohi ja pidä pienet vastaukset sen päällä” kuulostaa reitityskäytännöltä, mutta ei ole sitä. Reititin päättää sillä hetkellä käytettävissä olevalla tiedolla: osoitteet, portit, protokolla, firewall-merkinnät, tunnistettu virtaus. Vastauksen lopullinen koko ei kuulu tähän joukkoon, koska se ei ole vielä saapunut, ja kun reititin voisi mitata tavut, se kuljettaa niitä jo. Jos haluat ohjata tehtävän mukaan, päätöksen on siirryttävä pisteeseen, joka tuntee tehtävän, ja alla oleva tarkistuslista näyttää, onko suunnitelmassasi sellainen piste.

Miksi reititin ei voi mitata vastausta

Hetkellä, jolloin paketti tarvitsee reitin, reititin on nähnyt enintään virtauksen ensimmäiset paketit. Se voi kertoa, kuka puhuu kenen kanssa, millä protokollalla, millä merkinnällä ja kuinka monta tavua on tähän mennessä kulkenut. Tähänastiset tavut kuvaavat menneisyyttä. Vastauksen koko on ominaisuus vastaukselle, jota ei ole vielä luotu, ja pätkittyjen tai suoratoistovastausten kohdalla se ei ehkä ole koskaan etukäteen tiedossa.

Jopa protokollan omat metatiedot ovat heikompia kuin miltä ne näyttävät. HTTP sallii vastaukset, joiden pituutta ei ilmoiteta ennen runkoa, ja yhdestä käyttäjän toimesta voi syntyä monta pyyntöä, joiden yhteiskustannus ei muistuta mitään yksittäistä otsakearvoa. Otsakkeen pitäminen tehtävän kokona on mallinnusvirhe ennen kuin se on reititysvirhe.

Tarkistus 1: onko olemassa päätöspiste, joka voi valita polun?

Nimeä komponentti, joka tekee valinnan, ja nimeä sitten, mitä se tietää valinnan hetkellä. Dokumentoidusta isäntäjoukosta hakeva päivittäjä tuntee tarkoituksensa ennen siirron alkua. Metatietoja tutkiva ja sitten pyynnön avaava latauspalvelu tuntee tehtävän ennen yhteyden syntymistä. Yhteistyökykyinen proxy voi soveltaa pyyntötason käytäntöä tai välimuistittaa vastauksen esittämättä olevansa reititin.

Jos vastaus on “yhdyskäytävä”, tarkistuslista on jo epäonnistunut. Yhdyskäytävä voi luokitella tunnetut virtaukset kohteen, merkinnän tai asiakassegmentin mukaan ja lähettää ne määritettyä polkua ensimmäisestä paketista, mikä usein riittää hyväksytylle päivittäjälle eikä koskaan riitä tuntemattomalle vastauksen koolle.

Tarkistus 2: mitä metatiedot todella kertovat?

Sovellustietoinen ohjaus on vain niin hyvä kuin kentät, joita se lukee. HTTP:n semantiikka vastauspituussäännöt sallivat tapaukset, joissa pituus ei ole saatavilla alussa, ja sisältökoodaukset tekevät siirrettyjen tavujen määrästä joka tapauksessa erilaisen kuin esityksen koko. Siksi käytäntö, joka vaihtaa polkua otsakkeen ylittäessä kynnyksen, käyttäytyy epäjohdonmukaisesti, ja enimmäkseen juuri niissä suurissa siirroissa, jotka sen oli tarkoitus napata.

Se, mitä sovelluksen metatiedot voivat tukea, on päätös tehtävästä: tämä työnkulku on massasynkronointi, tämä on interaktiivinen, tämä on ohjelmistopäivitys tunnetusta lähteestä. Se on aikomuksen kielellä kirjoitettu käytäntö, ja se on riittävän vakaa testattavaksi. “Tämä vastaus on suurempi kuin neljäkymmentä megatavua” ei ole sellainen käytäntö.

Tarkistus 3: onko virtaus jo olemassa?

Reititys voi muuttua virtaukselle muuttamatta yhteyden identiteettiä, ja tämä ero kannattaa pitää selvänä. TCP-yhteys tunnistetaan päätepisteidensä osoitteista ja porteista, ja paketit voivat kulkea toista polkua, jos reititystaulu muuttuu niiden alla. Se, mikä ei voi muuttua näkymättömästi, on verkko-osoitteiden käännöksen tila: liikenteen siirtäminen toiseen ulostuloon muuttaa yleensä julkisen lähdetupleen, ja kaukopää näkee toisen vastapuolen ilman vastaavaa tilaa.

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

Käytännön sääntö on siis, että siirto kesken yhteyden ulostulosta toiseen on uusi suhde, ei migraatio. Jos suunnitelma vaatii saman yhteyden jatkuvan, päätös oli tehtävä ennen ensimmäistä SYN:iä, eikä myöhemmin lisätty pakettisääntö voi rakentaa sitä puhtaasti uudelleen.

Tarkistus 4: onko todellinen vaatimus latenssi, ei ulostulo?

Hyvin monet pyynnöt “lähetä massaliikenne muualle” ovat itse asiassa valituksia siitä, että suuri siirto saa interaktiivisen työn tuntumaan hitaalta. Se on ajoitusongelma, ja siihen on ajoitusvastaus: reilu jonotus tai tuettu kaistanleveyskäytäntö nykyisellä polulla estää massavirtauksen näännyttämästä chat-viestiä siirtämättä kumpaakaan.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Oireen käsitteleminen näin pitää ulostulopäätöksen siellä, mihin tietoturvakäytäntö sen asetti, ja se on peruttavissa yhdellä komennolla. Ulostulon vaihtaminen kokonaiselle liikenneluokalle on käytännön muutos, jolla on seurauksia todennukselle, lokitukselle ja pääsysäännöille, joten sen ei pitäisi olla ensimmäinen työkalu latenssivalituksessa.

Jos vaatimus on todella toinen internet-ulostulo, sano se niillä sanoilla ja toteuta se tuetulla rajalla: uusi yhteys hyväksytystä työnkulusta tai sovellus, joka avaa oman pyyntönsä valitun ulostulon kautta. Kirjaa sitten, mitkä tehtävät käyttävät mitäkin ulostuloa, jotta seuraavan henkilön ei tarvitse päätellä sitä reititystaulusta.

Pidä tarkistuslista muutoksen tiedoissa: päätöspiste, sitä ohjaava kenttä tai tehtävä, onko virtaus jo olemassa ja oliko mitattu oire latenssi vai ulostulo. Neljä kysymystä, ja käytäntö, joka vastaa kaikkiin neljään, on sellainen, jota voit operoida sen sijaan että puolustaisit sitä.