Dlaczego Tor wydaje się wolniejszy od VPN: kliknięcia kontra pobierania

Strony, które wydają się zawieszone, gdy pobierania idą w normalnym tempie, opisują podróże w obie strony, a nie pasmo. VPN dodaje jeden zaszyfrowany skok, a obwód Tora kilka, i każdy dodatkowy skok kosztuje uścisk dłoni, zanim przesunie się choć jeden użyteczny bajt. Ten koszt widać na stronie, która otwiera wiele krótkich połączeń, i prawie znika przy jednym dużym transferze. Gdy wzorzec staje się widoczny, spór przestaje dotyczyć tego, które narzędzie jest szybsze.

Objaw wskazuje na koszt konfiguracji, a nie na przepustowość

Ładowanie strony to łańcuch zależnych wymian: wyszukanie nazwy, uścisk dłoni transportu, uścisk dłoni TLS, potem pierwsze żądanie. Każdy skok na ścieżce wstawia swoją własną podróż w obie strony do tego łańcucha, zanim cokolwiek się narysuje. Duże pobieranie płaci ten sam koszt konfiguracji raz, a potem płynie, i właśnie dlatego oba obciążenia się nie zgadzają.

W panelu sieci czytaj czas oczekiwania przed pierwszym bajtem, a nie sumę. Długie oczekiwanie przy krótkim pobieraniu treści wskazuje na podróże w obie strony, natomiast długie pobieranie przy krótkim oczekiwaniu na przepustowość. Powtórz wobec drugiego celu, bo jeden host za zajętym przekaźnikiem niczego nie dowodzi. Kiedy transfer jest dobry, a kliknięcie wolne, podejrzewaj koszt konfiguracji znacznie wcześniej niż pasmo.

Opóźnienie i przepustowość zawodzą na różne sposoby

Zrób dwa pomiary i większość zamieszania rozwiązuje się sama. Opóźnienie to stały koszt na wymianę, a przepustowość to tempo w czasie, więc jedna ścieżka może być dobra w pierwszym i zła w drugim. Odległy punkt końcowy z bezczynnym procesorem szybko odpowiada na małe żądanie i nadal ogranicza stały transfer do tego, na co pozwala jego łącze wysyłające. Użytkownicy odczuwają ten podział jako żwawy klik, po którym następuje pasek postępu ledwo się poruszający.

Testuj przepustowość stałym transferem i patrz, czy tempo pozostaje stabilne, czy piłuje. Testuj opóźnienie małym żądaniem powtarzanym wiele razy i czytaj rozrzut, a nie najlepszą próbkę, bo szeroki rozrzut odczuwa się gorzej, niż sugeruje jego średnia. Zapisuj obie liczby przed i po każdej zmianie, inaczej później przypiszesz zasługę niewłaściwej zmiennej.

Traktowanie obu jako jednej liczby tworzy poprawki, które nigdy nie ruszają pomiaru, na którym ci zależy. To najczęstszy sposób, w jaki skarga na opóźnienie dostaje odpowiedź w postaci modernizacji pasma.

Rutowanie cebulowe dodaje skoki, których nie wybrałeś

Obwód Tora zwykle używa trzech przekaźników — strażnika, węzła środkowego i wyjścia — a klient wybiera je z konsensusu, nie z mapy. Dlatego ścieżka może być znacznie dłuższa niż prosta linia do celu. Każdy przekaźnik niesie też ruch innych, więc twój strumień dzieli tę przepustowość, która mu została.

Ponowne użycie obwodu łagodzi koszt, bo nowy strumień może jechać po istniejącym obwodzie zamiast płacić za kolejną budowę. Klient, który buduje świeży obwód dla każdego żądania, płaci konfigurację raz za razem i wypada znacznie gorzej niż ten, który używa ponownie. Wybór wyjścia też ma znaczenie, bo niektóre wyjścia niosą cięższe obciążenie i nic w interfejsie nie mówi, na które trafiłeś. To współdzielenie jest sensem projektu i powodem, dla którego opóźnienia nie da się nastroić na stałą wartość, więc jedno wolne wyjście to słaby powód, by porzucać ten układ.

Zmiana kolejności łańcucha zmienia eksperyment

VPN najpierw, a Tor potem to inny eksperyment niż Tor najpierw, a VPN potem. W pierwszym układzie punkt końcowy VPN niesie cały obwód, więc twoja sieć dostępowa poznaje tylko adres VPN. W drugim samo połączenie VPN jest niesione wewnątrz cebulowej ścieżki, a wyjście widzi ruch VPN. Oba są legalnymi projektami, a porównywanie któregokolwiek z gołym VPN mierzy coś innego, dlatego strona projektu Tor o łączeniu obu ujmuje to jako pytanie o to, co próbujesz ukryć, zanim stanie się pytaniem o czas.

Trzymaj urządzenie, sieć dostępową i cel nieruchomo, a między przebiegami zmieniaj dokładnie jeden element. Przesuwanie serwerów, obwodów i hostów testowych razem tworzy różnicę, której nikt nie przypisze. Zapisz, co każdy układ przed kim ukrywa, zanim go zoptymalizujesz, bo szybki łańcuch, który ujawnia to, co chciałeś ukryć, nie jest ulepszeniem.

Porównanie, które przetrwa drugi przebieg

Wybierz dwa lub trzy cele, których naprawdę używasz, i zmierz tę samą interakcję na każdym, w tym stronę, która ciągnie wiele małych zasobów, i jeden duży transfer. Powtórz cały zestaw o innej porze dnia.

Raportuj medianę i najgorszy przypadek zamiast najszybszej próbki, bo pracę interakcyjną ocenia się po jej złych momentach. Zanotuj klienta, punkt końcowy lub wyjście i to, czy obwód lub tunel został ponownie użyty w tym przebiegu. Jeśli zmiana poprawia medianę, ale pogarsza ogon, to wymiana, a nie zwycięstwo, i decyzja, czy użytkownicy to zauważą, jest tą prawdziwą.