Wêrom fielt Tor stadiger as in VPN: klikken tsjin downloafs

Siden dy’t kleverich fiele wylst downloafs op normale faasje rinne, beskriuwe hinne-en-wer-reizen, net bânbreedte. In VPN foeget ien fersifere sprong ta en in Tor-sirkwy foeget ferskate ta, en elke ekstra sprong kostet in handdruk foardat ien nuttige byte beweecht. Dy kosten binne te sjen op in side dy’t in soad koarte ferbiningen iepenet en ferdwine hast by ien grutte oerdracht. Sadree’t it patroan sichtber is, giet de diskusje net mear oer hokker helpmiddel flugger is.

It symptoom wiist op opsetkosten, net op kapasiteit

It laden fan in side is in keatling fan ôfhinklike útwikselings: in nammesyklje, in ferfiershanddruk, in TLS-handdruk, dan it earste fersyk. Elke sprong yn it paad foeget syn eigen hinne-en-wer-reis oan dy keatling ta foardat der wat tekene wurdt. In grutte downloaf betellet deselde opsetkosten ien kear en streamt dan, en dêrom binne de twa wurklasten it net iens.

Lês yn it netwurkpaniel de tiid dy’t wachte wurdt foar de earste byte, net it totaal. Lang wachtsjen mei in koarte ynhâld-downloaf wiist op hinne-en-wer-reizen, wylst in lange ynhâld-downloaf mei in koart wachtsjen op trochfier wiist. Werhelje tsjin in twadde bestimming, want ien host efter in drok relais bewiist neat. As de oerdracht goed is en de klik stadich, fertinkje dan opsetkosten folle earder as bânbreedte.

Fertraging en kapasiteit mislearje op ferskate manieren

Nim twa lêzingen en it measte fan ‘e betizing lost himsels op. Latensje is in fêste kosten per útwikseling en kapasiteit is in faasje oer de tiid, dus ien paad kin goed wêze yn ‘e earste en min yn ‘e twadde. In fier einpunt mei in ledige prosessor antwurdet fluch op in lyts fersyk en beheint dochs in oanhâldende oerdracht ta wat syn opgeande keppeling tastiet. Brûkers belibje dy splitsing as in flugge klik folge troch in foarútgongsbalke dy’t amper beweecht.

Test kapasiteit mei in oanhâldende oerdracht en sjoch oft it tempo stabyl bliuwt of seageft. Test latensje mei in lyts fersyk dat in protte kearen werhelle wurdt en lês de sprieding yn stee fan it bêste mônster, want in brede sprieding fielt slimmer as syn gemiddelde suggerearret. Skriuw beide sifers op foar en nei elke feroaring, oars jouwe jo letter it ferkearde fariabele de eare.

De twa as ien sifer behannelje liedt ta reparearrings dy’t nea de mjitting bewege dy’t jo wichtich fine. Dat is de meast foarkommende manier wêrop in klacht oer latensje beantwurdet wurdt mei in bânbreedteferbettering.

Sipelrouting foeget sprongen ta dy’t jo net keazen hawwe

In Tor-sirkwy brûkt normaal trije relays — in bewekker, in middenknooppunt en in útgean — en de klant kiest se út in konsensus, net fan in kaart. It paad kin dêrom folle langer wêze as de direkte line nei de bestimming. Elk relay draacht ek it ferkear fan oaren, dus jo stream dielt de kapasiteit dy’t dat relay oer hat.

Herbrûken fan it sirkwy sêft de kosten, want in nije stream kin op in besteand sirkwy ride yn stee fan foar in oare bou te beteljen. In klant dy’t foar elk fersyk in nij sirkwy bout, betellet de opset hieltiten wer en fielt folle slimmer as ien dy’t herbrûkt. De kar fan útgean makket ek út, want guon útgongen drage swierdere lading en neat yn ‘e ynterface fertelt jo op hokker oft jo lâne binne. Dat dielen is it doel fan it ûntwerp en de reden dat latensje net op in fêste wearde ôfsteld wurde kin, dus ien stadige útgong is in minne reden om de regeling op te jaan.

It feroarjen fan ‘e folchoarder fan ‘e keatling feroaret it eksperimint

VPN earst en Tor dêrnei is in oar eksperimint as Tor earst en VPN dêrnei. Yn ‘e earste regeling draacht it VPN-einpunt it hiele sirkwy, dus jo tagongsnetwurk leart allinnich it VPN-adres. Yn ‘e twadde wurdt de VPN-ferbining sels yn it sipelpaad dragen, en it útgean sjocht VPN-ferkear. Beide binne legitime ûntwerpen, en ien fan beide fergelykje mei in bleat VPN mjit wat oars, dêrom de side fan it Tor-projekt oer it kombinearjen fan ‘e twa it as in fraach oer wat jo ferbergje wolle stelt foardat it in fraach oer tiid is.

Hâld it apparaat, it tagongsnetwurk en de bestimming fêst, en feroarje tusken de rinnen krekt ien elemint. It ferpleatsen fan servers, sirkwys en testhosts tagelyk jout in ferskil dat nimmen taskriuwe kin. Skriuw op wat elke regeling foar wa ferberget foardat jo it optimalisearje, want in flugge keatling dy’t sjen lit wat jo ferbergje woenen, is gjin ferbettering.

In fergeliking dy’t in twadde rin oerlibbet

Kies twa of trije bestimmingen dy’t jo echt brûke en mjit deselde ynteraksje op elk, ynklusyf in side dy’t in soad lytse boarnen lûkt en ien grutte oerdracht. Werhelje de hiele set op in oar oere fan ‘e dei.

Rapportearje de mediaan en it slimste gefal yn stee fan it fluchste mônster, want ynteraktyf wurk wurdt beoardiele op syn minne mominten. Notearje de klant, it einpunt of útgean, en oft it sirkwy of de tunnel foar dy rin herbrûkt waard. As in feroaring de mediaan ferbetteret mar de sturt ferslechteret, is dat in ruil en net in winst, en beslute oft brûkers it merke sille is de echte beslissing.