Чому Tor здається повільнішим за VPN: кліки проти завантажень

Сторінки, які здаються залиплими, поки завантаження йдуть зі звичайною швидкістю, описують кругові обходи, а не пропускну здатність. VPN додає один зашифрований перехід, а ланцюг Tor — кілька, і кожен зайвий перехід коштує рукостискання, перш ніж зрушить хоч один корисний байт. Ця ціна видна на сторінці, яка відкриває багато коротких з'єднань, і майже зникає за однієї великої передачі. Щойно закономірність стає видимою, суперечка перестає бути про те, який інструмент швидший.

Симптом указує на вартість встановлення, а не на ємність

Завантаження сторінки — це ланцюг залежних обмінів: пошук імені, транспортне рукостискання, рукостискання TLS, потім перший запит. Кожен перехід на шляху вставляє свій круговий обхід у цей ланцюг, перш ніж щось намалюється. Велике завантаження платить ту саму вартість встановлення один раз і потім тече, і саме тому два навантаження розходяться.

У панелі мережі читайте час очікування до першого байта, а не загальний. Довге очікування з коротким завантаженням вмісту вказує на кругові обходи, тоді як довге завантаження з коротким очікуванням — на пропускну здатність. Повторіть проти другого призначення, бо один вузол за зайнятим ретранслятором нічого не доводить. Коли передача гаразд, а клік повільний, підозрюйте вартість встановлення значно раніше за пропускну здатність.

Затримка та ємність відмовляють по-різному

Зробіть два виміри, і більшість плутанини розв'язується сама. Затримка — фіксована ціна за обмін, а ємність — швидкість у часі, тож один шлях може бути добрим у першому і поганим у другому. Віддалена кінцева точка з простоюючим процесором швидко відповідає на невеликий запит і все ж обмежує сталу передачу тим, що дозволяє її висхідний канал. Користувачі переживають цей розкол як швидкий клік, за яким іде смуга поступу, що ледве рухається.

Перевіряйте ємність сталою передачею і дивіться, чи швидкість тримається стабільно, чи пиляє. Перевіряйте затримку малим запитом, повтореним багато разів, і читайте розкид, а не найкращий зразок, бо широкий розкид відчувається гірше, ніж підказує середнє. Записуйте обидва числа до і після кожної зміни, інакше пізніше припишете заслугу не тій змінній.

Ставлення до двох як до одного числа породжує виправлення, які ніколи не рухають важливий для вас вимір. Це найчастіший спосіб відповісти на скаргу про затримку оновленням пропускної здатності.

Цибулева маршрутизація додає переходи, які ви не обирали

Ланцюг Tor зазвичай використовує три ретранслятори — вартовий, середній вузол і вихід — і клієнт обирає їх із консенсусу, а не з мапи. Тому шлях може бути значно довшим за пряму лінію до призначення. Кожен ретранслятор несе й чужий трафік, тож ваш потік ділить ту ємність, що в нього лишилася.

Повторне використання ланцюга пом'якшує ціну, бо новий потік може їхати наявним ланцюгом замість платити за ще одну будову. Клієнт, який будує свіжий ланцюг на кожен запит, платить за встановлення знову і знову і відчувається значно гірше за того, хто користується повторно. Вибір виходу теж важливий, бо деякі виходи несуть важче навантаження, і ніщо в інтерфейсі не каже, на який ви потрапили. Цей поділ і є сенсом задуму та причиною, чому затримку не можна налаштувати на фіксоване значення, тож один повільний вихід — слабка причина кидати таку схему.

Зміна порядку ланцюга змінює експеримент

Спершу VPN, потім Tor — це інший експеримент, ніж спершу Tor, потім VPN. У першому варіанті кінцева точка VPN несе весь ланцюг, тож ваша мережа доступу дізнається лише адресу VPN. У другому саме з'єднання VPN несеться всередині цибулевого шляху, і вихід бачить трафік VPN. Обидва варіанти законні, і порівняння будь-якого з них із голим VPN вимірює інше, тому сторінка проєкту Tor про поєднання двох подає це як питання про те, що ви намагаєтеся приховати, раніше, ніж як питання про час.

Тримайте пристрій, мережу доступу й призначення незмінними і міняйте рівно один елемент між прогонами. Переміщення серверів, ланцюгів і тестових вузлів разом створює різницю, яку ніхто не зможе віднести. Запишіть, що кожна схема від кого приховує, перш ніж її оптимізувати, бо швидкий ланцюг, що розкриває те, що ви хотіли приховати, не є покращенням.

Порівняння, яке переживає другий прогін

Виберіть дві або три адреси, якими ви справді користуєтеся, і заміряйте ту саму взаємодію на кожній, включно зі сторінкою, що тягне багато дрібних ресурсів, і однією великою передачею. Повторіть увесь набір в іншу пору доби.

Повідомляйте медіану та найгірший випадок замість найшвидшого зразка, бо інтерактивну роботу судять за її поганими митями. Позначте клієнта, кінцеву точку або вихід і те, чи використовувався ланцюг чи тунель повторно в тому прогоні. Якщо зміна покращує медіану, але погіршує хвіст, це обмін, а не перемога, і вирішити, чи помітять це користувачі, — і є справжнє рішення.