Kāpēc Tor šķiet lēnāks par VPN: klikšķi pret lejupielādēm
Tor un VPN aizture skar dažādas darba slodzes: diagnosticējiet iestrēgušo lapu pirms vainojat joslas platumu, tad mainiet vienu mainīgo katrā testā.
Lapas, kas šķiet iestrēgušas, kamēr lejupielādes notiek normālā ātrumā, apraksta turp un atpakaļ braucienus, nevis joslas platumu. VPN pievieno vienu šifrētu lēcienu, bet Tor ķēde — vairākus, un katrs papildu lēciens maksā rokasspiedienu pirms kāda lietderīga baits pārvietojas. Šīs izmaksas redzamas lapā, kas atver daudz īsu savienojumu, un gandrīz pazūd vienā lielā pārsūtījumā. Kad modelis kļūst redzams, strīds vairs nav par to, kurš rīks ir ātrāks.
Simptoms norāda uz iestatīšanas izmaksām, nevis kapacitāti
Lapas ielāde ir atkarīgu apmaiņu ķēde: nosaukuma meklēšana, transporta rokasspiediens, TLS rokasspiediens, tad pirmais pieprasījums. Katrs ceļa lēciens ievieto savu turp un atpakaļ braucienu šajā ķēdē, pirms kaut kas tiek uzzīmēts. Liela lejupielāde samaksā tās pašas iestatīšanas izmaksas vienreiz un pēc tam plūst, un tieši tāpēc abas darba slodzes nesaskan.
Tīkla panelī lasiet gaidīšanas laiku pirms pirmā baita, nevis kopējo. Ilga gaidīšana ar īsu satura lejupielādi norāda uz turp un atpakaļ braucieniem, savukārt ilga satura lejupielāde ar īsu gaidīšanu norāda uz caurlaidību. Atkārtojiet pret otru galamērķi, jo viens resursdators aiz noslogota releja neko nepierāda. Ja pārsūtīšana ir laba, bet klikšķis lēns, aizdomas par iestatīšanas izmaksām rodas daudz agrāk nekā par joslas platumu.
Aizture un kapacitāte neizdodas dažādos veidos
Veiciet divus mērījumus, un lielākā daļa apjukuma atrisinās pati. Latentums ir fiksētas izmaksas uz apmaiņu, bet kapacitāte ir ātrums laika gaitā, tāpēc viens ceļš var būt labs pirmajā un slikts otrajā. Attāls galapunkts ar dīkstāvē esošu procesoru ātri atbild uz mazu pieprasījumu un tomēr ierobežo pastāvīgu pārsūtīšanu ar to, ko pieļauj tā augšupielādes kanāls. Lietotāji šo sadalījumu izjūt kā ātru klikšķi, kam seko gandrīz nekustīga progresa josla.
Pārbaudiet kapacitāti ar pastāvīgu pārsūtīšanu un vērojiet, vai ātrums paliek stabils vai zāģveidīgs. Pārbaudiet latentumu ar mazu pieprasījumu, kas atkārtots daudzas reizes, un lasiet izkliedi, nevis labāko paraugu, jo plaša izkliede jūtas sliktāk, nekā liecina tās vidējais. Pierakstiet abus skaitļus pirms un pēc katras izmaiņas, citādi vēlāk piedēvēsiet nopelnus nepareizajam mainīgajam.
Abu uzskatīšana par vienu skaitli rada labojumus, kas nekad neizkustina jums svarīgo mērījumu. Tas ir visizplatītākais veids, kā aiztures sūdzība tiek atbildēta ar joslas platuma palielināšanu.
Sīpolu maršrutēšana pievieno lēcienus, kurus neizvēlējāties
Tor ķēde parasti izmanto trīs relejus — sargu, vidējo mezglu un izeju — un klients tos izvēlas no konsensa, nevis no kartes. Tāpēc ceļš var būt daudz garāks par tiešu līniju uz galamērķi. Katrs relejs pārvadā arī citu cilvēku satiksmi, tāpēc jūsu plūsma dala to kapacitāti, kas tam relejam palikusi.
Ķēdes atkārtota izmantošana mīkstina izmaksas, jo jauna plūsma var jāt uz esošas ķēdes, nevis maksāt par vēl vienu būvi. Klients, kas katrai pieprasījumam būvē jaunu ķēdi, maksā iestatīšanu atkal un atkal un jūtas daudz sliktāk nekā tas, kas izmanto atkārtoti. Arī izejas izvēle ir svarīga, jo dažas izejas nes smagāku slodzi un nekas saskarnē nepasaka, uz kuras jūs esat nolaidies. Šī dalīšanās ir dizaina jēga un iemesls, kāpēc aizturi nevar noregulēt uz fiksētu vērtību, tāpēc viena lēna izeja ir vājš iemesls atteikties no šīs kārtības.
Ķēdes kārtības maiņa maina eksperimentu
Vispirms VPN un pēc tam Tor ir cits eksperiments nekā vispirms Tor un pēc tam VPN. Pirmajā kārtībā VPN galapunkts nes visu ķēdi, tāpēc jūsu piekļuves tīkls uzzina tikai VPN adresi. Otrajā pats VPN savienojums tiek nests sīpolu ceļā, un izeja redz VPN satiksmi. Abi ir likumīgi dizaini, un jebkura no tiem salīdzināšana ar pliku VPN mēra ko citu, tāpēc Tor projekta lapa par abu apvienošanu to ietver kā jautājumu par to, ko jūs mēģināt noslēpt, pirms tas kļūst par laika jautājumu.
Turiet ierīci, piekļuves tīklu un galamērķi fiksētus un starp braucieniem mainiet tieši vienu elementu. Serveru, ķēžu un testa resursdatoru pārvietošana kopā rada atšķirību, ko neviens nevar attiecināt. Pierakstiet, ko katra kārtība no kā slēpj, pirms to optimizējat, jo ātra ķēde, kas atklāj to, ko gribējāt noslēpt, nav uzlabojums.
Salīdzinājums, kas pārdzīvo otru braucienu
Izvēlieties divus vai trīs galamērķus, ko patiešām lietojat, un nomēriet to pašu mijiedarbību katrā, tostarp lapu, kas velk daudz mazu resursu, un vienu lielu pārsūtīšanu. Atkārtojiet visu kopumu citā dienas stundā.
Ziņojiet mediānu un sliktāko gadījumu, nevis ātrāko paraugu, jo interaktīvu darbu vērtē pēc tā sliktajiem brīžiem. Atzīmējiet klientu, galapunktu vai izeju un to, vai ķēde vai tunelis tika izmantots atkārtoti šajā braucienā. Ja izmaiņas uzlabo mediānu, bet pasliktina asti, tā ir maiņa, nevis uzvara, un lēmums, vai lietotāji to pamanīs, ir īstais lēmums.