Dlaczego dwa testy prędkości VPN w tym samym tunelu się nie zgadzają

Dwa przebiegi, jeden tunel, a liczby różnią się trzykrotnie. Tunel nie zmienił się między nimi. Zmienił się pomiar: strona testowa, która wybiera serwer na podstawie twojej widocznej lokalizacji, liczba strumieni decydująca, czy rurę wypełnia jeden wolny start, czy sześć, oraz czas trwania tak krótki, że kończy się, zanim ścieżka zacznie być porządnie używana. Testy prędkości nie są błędne, ale odpowiadają na węższe pytanie niż to, które ludzie im zadają.

Nowy adres wyjściowy zmienia cel testu

Większość stron testowych wybiera serwer pomiarowy automatycznie i robi to częściowo, patrząc, skąd wygląda na to, że pochodzi twoje połączenie. Włącz tunel i twoje widoczne państwo się zmienia, więc wybrany serwer się zmienia, a porównanie obejmuje teraz dwie różne trasy do dwóch różnych hostów.

Wynik wcale nie jest pomiarem VPN. To pomiar twojej trasy do serwera, którego nie wybrałeś, a różnicą między oboma przebiegami może rządzić peering tego serwera, a nie cokolwiek, co zrobił tunel.

Ustal cel, zanim zmienisz cokolwiek innego. Każde wiarygodne narzędzie pozwala wybrać serwer jawnie, a gdy tego nie robi, strona wyników zwykle podaje użyty, co wystarcza, by zauważyć, że oba przebiegi nie są porównywalne. Potwierdź, co widziała strona, zanim zaufasz jej wyborowi:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Jeśli państwo zmieniło się między przebiegami, zmieniło się też wszystko, co test wybrał potem. Zapisz zaobserwowane wyjście obok każdego wyniku, a zamieszanie w większości znika.

Wolny start kończy się po zakończeniu większości krótkich testów

Połączenie TCP nie zaczyna na prędkości łącza. Zaczyna od małego okna przeciążenia, mniej więcej podwaja je w każdej rundzie, a pojemność ścieżki osiąga dopiero po kilku rundach. Test dziesięciosekundowy na ścieżce o dużym opóźnieniu może spędzić znaczną część życia w tym rozpędzie.

Dlatego tunel z większym opóźnieniem wypada w krótkim teście gorzej, niż na to zasługuje, i dlatego dłuższy przebieg często zgłasza wyższą liczbę bez żadnej zmiany konfiguracji. ramy przepustowości RFC 6349 traktują to wprost, dlatego poważne pomiary trwają dość długo, by osiągnąć stan ustalony. Pięciosekundowy przebieg na ścieżce satelitarnej mierzy przyspieszacz, nie drogę.

Patrz na fazy połączenia zamiast ufać jednej liczbie. Curl raportuje każdy etap osobno, więc widać, czy czas idzie na uścisk dłoni, na rozpęd czy na transfer:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Uruchom go dwa razy z rzędu do tego samego celu. Jeśli drugi przebieg jest znacznie szybszy, mierzyłeś rozpęd, nie ścieżkę, a każde porównanie oparte tylko na pierwszym jest podejrzane.

Jeden strumień i sześć strumieni mierzą różne rzeczy

Pojedynczy strumień TCP ogranicza okno, które może utrzymać w locie, czyli w przybliżeniu czas rundy pomnożony przez szybkość. Na długiej ścieżce ten iloczyn przewyższa to, co wykorzysta jeden strumień, więc jedno pobieranie zaniża istniejącą przepustowość. Sześć równoległych strumieni wypełnia tę lukę i daje większą liczbę.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Obie liczby są prawdziwe. Liczba jednego strumienia mówi, co zrobi jedno pobieranie, co zwykle dostaje karta przeglądarki. Liczba równoległa mówi, co ścieżka może nieść łącznie, co może wykorzystać torrent albo pobieranie wieloczęściowe. Cytowanie jednej tak, jakby była drugą, to sposób, w jaki zdrowy tunel bywa wymieniany bez powodu.

Porównywanie wyniku równoległego z wynikiem jednego strumienia to najczęstszy sposób, w jaki ludzie dochodzą do wniosku, że VPN zmniejszył im prędkość o połowę. Wyrównaj metodę, potem porównuj. Ślad w trzecim poleceniu dodaje brakujący kontekst: ścieżka z dużym jitterem da niespójne wyniki w obu trybach, a żadna liczba strumieni tego nie naprawi.

Szyfrowanie kosztuje czas procesora, enkapsulacja kosztuje bajty

Dwa mechanizmy działają na każdym pakiecie niezależnie od tego, jak szybkie jest łącze. Szyfrowanie zużywa procesor na bajt, a enkapsulacja dodaje bajty nagłówka, które łącze i tak musi nieść. Oba objawiają się jako sufit i mają różne symptomy.

Sufit procesora objawia się jako płaskowyż: przepustowość przestaje rosnąć, ile strumieni byś dodał, a procesor maszyny jest zajęty, gdy łącze nie jest. Na małym routerze lub telefonie to często prawdziwa granica, dlatego szybka linia może nadal dawać skromny tunel.

Koszt w bajtach jest mniejszy, ale stały. Dodatkowe nagłówki oznaczają mniej ładunku na pakiet, a na ścieżce z ustaloną maksymalną jednostką transmisji mogą też wywołać fragmentację lub czarną dziurę, która ujawnia się jako zacięcie przy dużych transferach, a nie jako wolna średnia.

Te trzy bywają mylone, bo użytkownicy opisują wszystkie jako to, że VPN jest wolny. Tylko pierwszy reaguje na większą maszynę, tylko drugi na mniejsze MTU, a tylko trzeci na zarządzanie kolejkami.

Zapisz metodę w protokole

Wynik wart zachowania wymienia urządzenie, sieć dostępową, wyjście, serwer pomiarowy, kierunek, liczbę strumieni i czas trwania. Bez tego dwóch liczb nie da się porównać, a zgłoszenie zawierające jedną liczbę to właściwie nastrój.

Zachowuj też złe przebiegi. Seria, w której jedno wyjście za każdym razem daje zacięcie, jest znacznie bardziej informacyjna niż średnia, a zacięcia to dokładnie to, co średnie ukrywają.

Potem testuj to, na czym naprawdę ci zależy. Jeśli celem jest duże pobieranie, pobierz plik. Jeśli celem jest rozmowa, mierz opóźnienie pod obciążeniem, a nie przepustowość w spoczynku, bo tunel może dobrze wypaść w teście prędkości i nadal uczynić każde spotkanie niesłyszalnym.