Store nedlastingar mot VPN-en: vel vegen ved førespurnaden

«Send dei store nedlastingane utanom VPN-en og hald dei små svara på han» høyrest ut som ein ruterpolitikk, og det er det ikkje. Ein ruter avgjer ut frå informasjonen som er tilgjengeleg i augneblinken: adresser, portar, protokoll, brannmurmerke, ein identifisert straum. Den endelege storleiken på eit svar er ikkje i det settet, fordi det ikkje har kome enno, og når ruteren kunne måle byta, fraktar han dei allereie. Viss du vil styre etter oppgåve, må avgjerda flyttast til eit punkt som kjenner oppgåva, og sjekklista nedanfor viser om designet ditt har eit slikt punkt.

Kvifor ein ruter ikkje kan måle eit svar

I augneblinken då ei pakke treng ei rute, har ruteren sett høgst dei første få pakkene i ein straum. Han kan seie kven som snakkar med kven, over kva protokoll, med kva merke, og kor mange byte som har passert så langt. Byte så langt skildrar fortida. Storleiken på svaret er ein eigenskap ved eit svar som ikkje er generert enno, og for oppdelte eller straumande svar er han kanskje aldri kjend på førehand.

Sjølv metadadata til protokollen er svakare enn dei ser ut. HTTP tillèt svar der lengda ikkje blir kunngjort før kroppen, og éi einaste brukarhandling kan lage mange førespurnader der den samla kostnaden ikkje liknar nokon ein verdi i ein header. Å handsame ein header som storleiken på ei oppgåve er ein modelleringsfeil før det er ein ruterfeil.

Sjekk 1: finst det eit punkt for avgjerd som kan velje ein veg?

Nemn komponenten som skal gjere valet, og nemn deretter kva han veit i augneblinken han vel. Ein oppdatering som hentar frå eit dokumentert sett vertar, kjenner føremålet sitt før overføringa startar. Ein nedlastingsteneste som sjekkar metadata og deretter opnar førespurnaden, kjenner oppgåva før sambandet finst. Ein samarbeidande proxy kan bruke politikk på førespurnadsnivå eller cache svaret utan å late som han er ein ruter.

Viss svaret er «gatewayen», har sjekklista allereie feila. Ein gateway kan klassifisere kjende straumar etter mål, merke eller klientsegment og sende dei nedover ein definert veg frå første pakke, noko som ofte er nok for ein godkjend oppdatering og aldri nok for ein ukjend svarsstorleik.

Sjekk 2: kva fortel metadadataa deg eigentleg?

Applikasjonsmedviten styring er berre så god som felta ho les. Reglane for svarlengd i HTTP-semantikk tillèt tilfelle der lengda ikkje er tilgjengeleg ved start, og innhaldskodingar gjer uansett talet på overførte byte annleis enn storleiken på framstellinga. Difor vil ein politikk som byter veg når ein header kryssar ein terskel, oppføre seg inkonsistent, og mest nettopp på dei store overføringane han skulle fange.

Det applikasjonsmetadata kan støtte, er ei avgjerd om ei oppgåve: denne arbeidsflyten er ein massiv synkronisering, denne er interaktiv, denne er ein programvareoppdatering frå ein kjend opphavsstad. Det er ein politikk skriven i intensjonsomgrep, og han er stabil nok til å bli testa. «Dette svaret blir større enn førti megabyte» er ikkje den slags politikk.

Sjekk 3: finst straumen allereie?

Ruting kan endre seg for ein straum utan å endre identiteten til sambandet, og den skilnaden er verdt å halde greie på. Eit TCP-samband blir identifisert av endepunktsadressene og portane sine, og pakkene kan ta ein annan veg viss rutetabellen endrar seg under dei. Det som ikkje kan endre seg usynleg, er tilstanden til nettverksadresseomsetjinga: å flytte trafikk til ein annan utgang endrar vanlegvis den offentlege kildetuppelen, og den fjerne enden vil sjå ein annan part utan samsvarande tilstand.

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

Så den praktiske regelen er at ei flytting midt i eit samband frå ein utgang til ein annan er eit nytt tilhøve, ikkje ein migrasjon. Viss designet krev at det same sambandet held fram, måtte avgjerda takast før den første SYN, og ingen pakkeregel som blir lagd til seinare kan rekonstruere han reint.

Sjekk 4: er det eigentlege kravet latenstid, ikkje utgang?

Svært mange førespurnader om å «sende bulk-trafikk ein annan stad» er eigentleg klager over at ei stor overføring får interaktivt arbeid til å kjennast tregt. Det er eit planleggingsproblem, og det har eit planleggingssvar: rettferdig køing eller ein støtta bandbreiddepolitikk på den eksisterande vegen hindrar ein bulkstraum i å svelte ei chatmelding utan å flytte nokon av dei.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Å handsame symptomet slik held utgangsavgjerda der tryggleikspolitikken plasserte henne, og ho kan rullast tilbake med éin kommando. Å endre utgangen for ein heil klasse trafikk er ei politikkendring med konsekvensar for autentisering, logging og tilgangsreglar, så det bør ikkje vere det første verktøyet ved ei klage på latenstid.

Viss kravet verkeleg er ein annan internettutgang, seie det med dei orda og implementer det ved ei støtta grense: eit nytt samband frå ein godkjend arbeidsflyt, eller ein applikasjon som opnar si eiga førespurnad gjennom ein vald utgang. Registrer deretter kva oppgåver som brukar kva utgang, slik at neste person ikkje må utleie det frå ein rutetabell.

Hald sjekklista i endringsoppføringa: avgjerdspunktet, feltet eller oppgåva som driv det, om straumen allereie finst, og om det målte symptomet var latenstid eller utgang. Fire spørsmål, og ein politikk som svarar på alle fire, er ein du kan drive i staden for å forsvare.