Miks Tor tundub VPN-ist aeglasem: klikid versus allalaadimised
Tori ja VPN-i viivitus tabab erinevaid töökoormusi: diagnoosi kleepuv lehekülg enne ribalaiuse süüdistamist ja muuda siis iga katse kohta ühte muutujat.
Leheküljed, mis tunduvad kleepuvatena, kui allalaadimised käivad tavalise kiirusega, kirjeldavad edasi-tagasi reise, mitte ribalaiust. VPN lisab ühe krüpteeritud hüppe ja Tori ring lisab mitu, ning iga lisahüpe maksab kätlemise enne, kui liigub ükski kasulik bait. See kulu paistab lehel, mis avab palju lühikesi ühendusi, ja kaob suures osas ühe suure ülekande juures. Kui muster on nähtav, ei ole vaidlus enam sellest, milline tööriist on kiirem.
Sümptom osutab seadistuskulule, mitte mahutavusele
Lehe laadimine on sõltuvate vahetuste ahel: nimeotsing, transpordikätlus, TLS-kätlus ja siis esimene päring. Iga hüpe teel lisab sellesse ahelasse oma edasi-tagasi reisi enne, kui midagi joonistub. Suur allalaadimine maksab sama seadistuskulu üks kord ja voogab siis, ja täpselt sellepärast need kaks töökoormust lahknevad.
Lugege võrgupaneelil esimese baidi eelse ootamise aega, mitte koguaega. Pikk ootamine lühikese sisu allalaadimisega osutab edasi-tagasi reisidele, samas kui pikk sisu allalaadimine lühikese ootamisega osutab läbilaskevõimele. Korrake teise sihtkoha vastu, sest üks host hõivatud relee taga ei tõesta midagi. Kui ülekanne on korras ja klõps on aeglane, kahtlustage seadistuskulu palju varem kui ribalaiust.
Viivitus ja mahutavus ebaõnnestuvad erineval moel
Tehke kaks mõõtmist ja enamik segadust laheneb iseenesest. Latentsus on vahetuse kohta fikseeritud kulu ja mahutavus on kiirus ajas, seega võib üks tee olla esimeses hea ja teises halb. Kaugem otspunkt jõudeoleva protsessoriga vastab väikesele päringule kiiresti ja piirab ikkagi püsivat ülekannet sellega, mida tema üleslink lubab. Kasutajad kogevad seda lõhet kiire klõpsuna, millele järgneb edenemisriba, mis vaevu liigub.
Testige mahutavust püsiva ülekandega ja jälgige, kas kiirus püsib ühtlane või saagihambaline. Testige latentsust väikese päringuga, mida korratakse palju kordi, ja lugege hajuvust, mitte parimat valimit, sest lai hajuvus tundub hullem, kui selle keskmine vihjab. Kirjutage mõlemad numbrid üles enne ja pärast iga muudatust, muidu omistate hiljem au valele muutujale.
Kahe kohtlemine ühe numbrina tekitab parandusi, mis ei liiguta kunagi mõõtmist, millest hoolite. See on kõige tavalisem viis, kuidas latentsuse kaebusele vastatakse ribalaiuse uuendusega.
Sibulmarsruutimine lisab hüppeid, mida te ei valinud
Tori ring kasutab tavaliselt kolme releed — valvurit, keskse sõlme ja väljapääsu — ja klient valib need konsensusest, mitte kaardilt. Seetõttu võib tee olla palju pikem kui otseliin sihtkohta. Iga relee kannab ka teiste liiklust, seega jagab teie voog seda mahutavust, mis releel alles on.
Ringi korduskasutus pehmendab kulu, sest uus voog saab sõita olemasoleval ringil, selle asemel et maksta veel ühe ehituse eest. Klient, kes ehitab iga päringu jaoks värske ringi, maksab seadistust korduvalt ja tundub palju hullem kui see, kes kasutab korduskasutust. Ka väljapääsu valik loeb, sest mõned väljapääsud kannavad raskemat koormat ja miski liideses ei ütle, millisele te maandusite. See jagamine on disaini mõte ja põhjus, miks latentsust ei saa fikseeritud väärtusele häälestada, seega on üks aeglane väljapääs nõrk põhjus korraldusest loobuda.
Ahela järjekorra muutmine muudab katset
Kõigepealt VPN ja seejärel Tor on teine katse kui kõigepealt Tor ja seejärel VPN. Esimeses korralduses kannab VPN-i otspunkt kogu ringi, seega õpib teie juurdepääsuvõrk tundma ainult VPN-i aadressi. Teises kantakse VPN-ühendust ennast sibulatee sees ja väljapääs näeb VPN-i liiklust. Mõlemad on legitiimsed disainid, ja kummagi võrdlemine palja VPN-iga mõõdab midagi muud, mistõttu Tori projekti leht kahe kombineerimise kohta raamistab selle küsimusena sellest, mida te püüate peita, enne kui see on küsimus ajastusest.
Hoidke seade, juurdepääsuvõrk ja sihtkoht fikseerituna ning muutke jooksude vahel täpselt ühte elementi. Serverite, ringide ja testhostide korraga liigutamine tekitab erinevuse, mida keegi ei saa omistada. Kirjutage üles, mida iga korraldus kelle eest peidab, enne kui seda optimeerite, sest kiire ahel, mis paljastab selle, mida tahtsite peita, ei ole parendus.
Võrdlus, mis elab üle teise jooksu
Valige kaks või kolm sihtkohta, mida tegelikult kasutate, ja mõõtke sama suhtlust igas, sealhulgas lehekülg, mis tõmbab palju väikeseid ressursse, ja üks suur ülekanne. Korrake kogu komplekti teisel kellaajal.
Esitage mediaan ja halvim juhtum, mitte kiireim valim, sest interaktiivset tööd hinnatakse selle halbade hetkede järgi. Märkige klient, otspunkt või väljapääs ja kas ringi või tunnelit selle jooksu jaoks korduskasutati. Kui muudatus parandab mediaani, aga halvendab saba, on see vahetus, mitte võit, ja otsustamine, kas kasutajad seda märkavad, on tegelik otsus.