Miért tűnik lassabbnak a Tor a VPN-nél: kattintások kontra letöltések

A ragadósnak érződő oldalak, miközben a letöltések normál sebességgel futnak, oda-vissza utakat írnak le, nem sávszélességet. A VPN egy titkosított ugrást ad hozzá, a Tor-áramkör pedig többet, és minden extra ugrás egy kézfogásba kerül, mielőtt bármely hasznos bájt elmozdulna. Ez a költség olyan oldalon látszik, amely sok rövid kapcsolatot nyit, és egyetlen nagy átvitelnél nagyrészt eltűnik. Amint a minta láthatóvá válik, a vita már nem arról szól, melyik eszköz gyorsabb.

A tünet a beállítási költségre mutat, nem a kapacitásra

Egy oldal betöltése függő cserék láncolata: névkeresés, szállítási kézfogás, TLS-kézfogás, majd az első kérés. Az útvonal minden ugrása beilleszti a saját oda-vissza útját ebbe a láncba, mielőtt bármi kirajzolódna. Egy nagy letöltés ugyanezt a beállítási költséget egyszer fizeti meg, majd streamel, és éppen ezért nem értenek egyet a két munkaterhelés.

Hálózati panelen az első bájt előtti várakozási időt olvassa, ne az összest. A hosszú várakozás rövid tartalomletöltéssel oda-vissza utakra mutat, míg a hosszú tartalomletöltés rövid várakozással az átbocsátóképességre. Ismételje meg egy második célállomás felé, mert egy foglalt relay mögötti hoszt semmit sem bizonyít. Ha az átvitel rendben van, de a kattintás lassú, jóval a sávszélesség előtt gyanakodjon a beállítási költségre.

A késleltetés és a kapacitás különböző módokon vall kudarcot

Vegyen két mérést, és a zavar nagy része magától megoldódik. A latencia cserénkénti fix költség, a kapacitás pedig időbeli sebesség, így egy útvonal jó lehet az elsőben és rossz a másodikban. Egy távoli végpont tétlen processzorral gyorsan válaszol egy kis kérésre, és mégis a feltöltési linkje által engedettre korlátoz egy tartós átvitelt. A felhasználók ezt a szétválást fürge kattintásként élik meg, amelyet alig mozduló folyamatjelző követ.

Tesztelje a kapacitást tartós átvitellel, és figyelje, hogy a sebesség stabil marad-e vagy fűrészfogas. Tesztelje a latenciát sokszor ismételt kis kéréssel, és a szórást olvassa a legjobb minta helyett, mert a széles szórás rosszabbnak érződik, mint amit az átlaga sugall. Minden változtatás előtt és után jegyezze fel mindkét számot, különben később a rossz változónak tulajdonítja a sikert.

A kettőt egyetlen számként kezelni olyan javításokat szül, amelyek soha nem mozdítják azt a mérést, amely számít Önnek. Ez a leggyakoribb módja annak, hogy a latenciapanaszra sávszélesség-bővítéssel válaszoljanak.

A hagymás útválasztás olyan ugrásokat ad hozzá, amelyeket nem Ön választott

A Tor-áramkör általában három relayt használ — egy őrt, egy középső csomópontot és egy kijáratot —, és a kliens ezeket konszenzusból választja, nem térképből. Az útvonal ezért jóval hosszabb lehet a célállomáshoz vezető egyenes vonalnál. Minden relay mások forgalmát is viszi, így az Ön adatfolyama osztozik azon a kapacitáson, ami a relaynél maradt.

Az áramkör újrafelhasználása tompítja a költséget, mert egy új adatfolyam egy meglévő áramkörre ülhet fel ahelyett, hogy egy másik építésért fizetne. Az a kliens, amely minden kéréshez friss áramkört épít, újra és újra fizeti a beállítást, és sokkal rosszabbnak érződik, mint amelyik újrafelhasznál. A kijárat választása is számít, mert egyes kijáratok nagyobb terhet visznek, és semmi sem mondja meg a felületen, melyikre landolt. Ez a megosztás a tervezés lényege és az oka, hogy a latenciát nem lehet fix értékre hangolni, ezért egy lassú kijárat gyenge ok a felállás elhagyására.

A lánc sorrendjének megváltoztatása megváltoztatja a kísérletet

Először VPN, aztán Tor más kísérlet, mint először Tor, aztán VPN. Az első felállásban a VPN végpont viszi az egész áramkört, így a hozzáférési hálózata csak a VPN-címet ismeri meg. A másodikban maga a VPN-kapcsolat halad a hagymás útvonalon belül, és a kijárat VPN-forgalmat lát. Mindkettő legitim tervezés, és bármelyiket egy csupasz VPN-hez hasonlítani más valamit mér, ezért a Tor Project kettő kombinálásáról szóló oldala úgy keretezi, mint kérdést arról, mit próbál elrejteni, mielőtt időzítési kérdés lenne.

Tartsa fixen az eszközt, a hozzáférési hálózatot és a célt, és futások között pontosan egy elemet változtasson. Szerverek, áramkörök és teszt-hosztok együttes mozgatása olyan különbséget ad, amelyet senki sem tud beszámítani. Írja le, mit rejt el az egyes felállás kitől, mielőtt optimalizálja, mert a gyors lánc, amely felfedi, amit el akart rejteni, nem javítás.

Egy összehasonlítás, amely túlél egy második futást

Válasszon két vagy három olyan célállomást, amelyet valóban használ, és időzítse ugyanazt az interakciót mindegyiken, beleértve egy oldalt, amely sok kis erőforrást húz, és egy nagy átvitelt. Ismételje meg az egész készletet a nap egy másik órájában.

A mediánt és a legrosszabb esetet jelentse a leggyorsabb minta helyett, mert az interaktív munkát a rossz pillanatai alapján ítélik meg. Jegyezze fel a klienst, a végpontot vagy a kijáratot, és hogy az áramkört vagy az alagutat újrahasználták-e abban a futásban. Ha egy változtatás javítja a mediánt, de rontja a farkat, az csere és nem győzelem, és annak eldöntése, hogy a felhasználók észreveszik-e, az igazi döntés.