Grutte downloads tsjin de VPN: kies it paad by it fersyk

“Stjoer de grutte downloads om 'e VPN hinne en hâld de lytse antwurden derop” klinkt as in routingbelied, en dat is it net. In router beslút mei ynformaasje dy't op dat stuit beskikber is: adressen, poarten, protokol, firewall-merkjes, in identifisearre stream. De úteinlike grutte fan in antwurd sit net yn dy set, want it is noch net oankommen, en as de router de bytes mjitte koe, draacht er se al. As jo op taak stjoere wolle, moat it beslút nei in punt ferhúzje dat de taak ken, en de kontrolelist hjirûnder lit sjen oft jo ûntwerp sa'n punt hat.

Wêrom in router in antwurd net mjitte kin

Op it stuit dat in pakket in rûte nedich hat, hat de router op syn heechst de earste pear pakketten fan in stream sjoen. Hy kin sizze wa't mei wa praat, fia hokker protokol, mei hokker merk, en hoefolle bytes der oant no ta foarby gien binne. Bytes oant no ta beskriuwe it ferline. De grutte fan it antwurd is in eigenskip fan in antwurd dat noch net makke is, en by opdielde of streamende antwurden is it miskien nea foarôf te witten.

Sels de eigen metadata fan it protokol is swakker as it liket. HTTP lit antwurden ta wêrfan de lingte net foar de lichem oankundige wurdt, en ien brûkeraksje kin in soad oanfragen meitsje wêrfan de gearfoege kosten hielendal net op ien hokker headervaarde lykje. In header behannelje as de grutte fan in taak is in modellearfout foardat it in routingfout is.

Kontrôle 1: is der in beslispunt dat in paad kieze kin?

Neam de komponint dy't de kar meitsje sil, en neam dan wat it wit op it stuit fan de kar. In bywurker dy't fan in dokumintearre set hosts hellet, ken syn doel foardat de oerdracht begjint. In downloadtsjinst dy't metadata rieplachtet en dan de oanfraach iepenet, ken de taak foardat de ferbining bestiet. In gearwurkjende proxy kin belied op oanfraachnivo tapasse of it antwurd cacheje sûnder te dwaan as is er in router.

As it antwurd “de gateway” is, hat de kontrolelist al mislearre. In gateway kin bekende streams yndiele nei bestimming, merk of kliïntsegmint en se fan it earste pakket ôf oer in fêststeld paad stjoere, wat faak genôch is foar in goedkarde bywurker en nea genôch foar in ûnbekende antwurdgrutte.

Kontrôle 2: wat fertelle de metadata jo echt?

Applikaasjebewust stjoeren is mar sa goed as de fjilden dy't it lêst. De regels foar antwurdlingte yn HTTP-semantyk litte gefallen ta wêrby't de lingte by it begjin net beskikber is, en ynhâldkodearings meitsje it tal oerdroegen bytes dochs oars as de grutte fan 'e foarstelling. Dêrom sil in belied dat fan paad feroaret as in header in drompel oerstekt, ynkonsistint hannelje, en meast krekt op 'e grutte oerdrachten dy't it fange moast.

Wat applikaasjemetadata stypje kin, is in beslút oer in taak: dizze wurkstream is in bulk-syngronisaasje, dizze is ynteraktyf, dizze is in software-bywurking fan in bekende oarsprong. Dat is in belied skreaun yn termen fan yntinsje, en it is stabyl genôch om te testen. “Dit antwurd sil grutter wêze as fjirtich megabyte” is net sa'n belied.

Kontrôle 3: bestiet de stream al?

Routing kin foar in stream feroarje sûnder de identiteit fan 'e ferbining te feroarjen, en dat ûnderskied is wurdich om rjocht te hâlden. In TCP-ferbining wurdt identifisearre troch de adressen en poarten fan har einen, en de pakketten kinne in oar paad nimme as de routingtabel dêrûnder feroaret. Wat net ûnsichtber feroarje kin, is de tastân fan netwurkadresfertaalling: ferkear nei in oare útgong ferhúzje feroaret meastentiids de iepenbiere boarntuple, en de fiere kant sil in oare peer sjen sûnder oerienkommende tastân.

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

Dat de praktykse regel is dat in ferhuzing midden yn 'e ferbining fan ien útgong nei in oare in nije relaasje is, gjin migraasje. As it ûntwerp freget dat deselde ferbining trochgiet, moast it beslút foar de earste SYN nommen wêze, en gjin pakketregel dy't letter tafoege wurdt kin it skjin weropbouwe.

Kontrôle 4: is de echte eask fertraging, net útgong?

Hiel in soad oanfragen “stjoer bulkferkear earne oars hinne” binne eins klachten dat in grutte oerdracht ynteraktyf wurk traach fiele lit. Dat is in planningsprobleem, en it hat in planningsantwurd: earlik rigegjen of in stipe bânbreedtebelied op it besteande paad hâldt in bulkstream derfan ôf in chatberjocht hongerje te litten, sûnder ien fan beide te ferhúzjen.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

It symptoom sa oanpakke hâldt it útgongbeslút dêr't it befeiligingsbelied it set hat, en it is mei ien opdracht werom te draaien. De útgong foar in hiele klasse ferkear feroarje is in beliedswiziging mei gefolgen foar autentikaasje, logging en tagongsregels, dus it moat net it earste helpmiddel wêze by in klacht oer fertraging.

As de eask echt in oare ynternetútgong is, sis it yn dy wurden en ymplemintearje it by in stipe grins: in nije ferbining fan in goedkarde wurkstream, of in applikaasje dy't syn eigen oanfraach troch in keazen útgong iepenet. Registrearje dan hokker taken hokker útgong brûke, sadat de folgjende persoan it net út in routingtabel ôfliede hoecht.

Hâld de kontrolelist yn it feroaringsregister: it beslispunt, it fjild of de taak dy't it driuwt, oft de stream al bestiet, en oft it metten symptoom fertraging of útgong wie. Fjouwer fragen, en in belied dat alle fjouwer beantwurdet is ien dat jo betsjinje kinne ynstee fan ferdigenje.