Dlaczego pobieranie przez VPN może pobić twoje bezpośrednie połączenie

Transfer, który przyspiesza w tunelu, zwykle wskazuje na limit na jednym porcie. Trzy kontrolowane porównania oddzielają kształtownik od rzeczywistego przyspieszenia.

Połącz tunelem, uruchom duże pobieranie, a pójdzie ono mniej więcej dwa razy szybciej niż ten sam plik bez niego. Brzmi to jak reklama, ale może być prawdziwym pomiarem na domowym łączu. Zwykła przyczyna to limit szybkości przypisany do jednego portu: tunel przenosi transfer tam, gdzie kształtownik nie patrzy, i rzeczywista przepustowość łącza pokazuje się po raz pierwszy.

Co oznacza, że ciekawą liczbą nie jest to, jak szybki był VPN. Lecz to, ile swojego łącza nigdy nie dostawałeś, i dlaczego.

Limit, który idzie za portem, nie za trasą

Dostawca dostępu może ograniczać przepustowość na abonenta według protokołu lub portu docelowego, a port 80 jest ulubionym celem, bo tak dużo zwykłego przeglądania go używa. Limit często nie działa od pierwszego pakietu: transfer startuje blisko szybkości łącza, wypala zapas burst, a potem osiada na ograniczonej wartości. Pierwsze sekundy wyglądają zdrowo, reszta transferu nie.

Wyślij te same bajty innym portem, a kształtownik na 80 nigdy ich nie zobaczy. Tunel wygląda, jakby bił połączenie bezpośrednie, choć dodał przeskok, szyfrowanie i własny narzut. Poprawiło się nie to, co na trasie, ale brak pewnej reguły.

Dlatego efekt jest tak powtarzalny przy różnych plikach i celach. Jeśli limit jest na porcie, wszystko przenoszone tym portem zachowuje się tak samo, niezależnie od rozmiaru pliku i tego, kim jest gospodarz. Cel, który przyciąga inną regułę, pokazuje inną krzywą, a ta różnica sama w sobie jest diagnostyczna.

Mierz plateau, nie szczyt

Szczyt to najmniej informacyjna część transferu, bo każde połączenie wygląda dobrze, gdy zapełniają się jego bufory. Zanotuj, gdzie szybkość się ustala i jak długo tam zostaje.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Uruchom parę bezpośrednio po sobie na tej samej maszynie, o tej samej godzinie, wobec gospodarzy w porównywalnych sieciach. Jedna próbka niczego nie dowodzi; kształt krzywej z dwóch przebiegów każdego z nich to, co odróżnia zapas burst od stałego ograniczenia. Zapisz, gdzie szybkość się wypłaszcza, a nie to, co pokazała pierwsza sekunda, bo burst jest właśnie tym, co kształtownik daje ci, zanim zacznie ograniczać. Spokojne plateau, które utrzymuje się do końca transferu, to liczba do porównania.

Trzymaj plik już skompresowany, żeby kompresja transportowa nie mogła zostać podana jako wyjaśnienie. PDF albo archiwum usuwa tę zmienną i nie pozwala nikomu twierdzić, że tunel ścisnął ładunek. Jeśli oba transfery używają tego samego pliku, jedyną pozostałą różnicą jest trasa i port. Zapisuj narzędzie i port obok każdej liczby, inaczej drugi przebieg nie jest porównywalny z pierwszym.

Trzy porównania, które izolują przyczynę

Przejdź je po kolei i zatrzymaj się, gdy wzorzec będzie jasny, bo każde z nich wyklucza inną historię.

  1. Powtórz to samo pobieranie zwykłą drogą webową i narzędziem transferu na innym porcie, z gospodarza o porównywalnej pojemności.
  2. Powtórz oba z plikiem nieskompresowalnym, żeby kompresja przestała być kandydatem.
  3. Jeśli sam prowadzisz serwer tunelu, przypisz go ponownie do portu 80, dostosuj profil klienta, żeby oba końce się zgadzały, i prześlij ponownie. Jeśli tunel siedzi teraz na ograniczonej szybkości webowej, ograniczenie idzie za portem, a nie za VPN.

Trzeci krok jest rozstrzygający i jest też tym, który ludzie pomijają, bo wymaga zmiany konfiguracji. Bez niego pokazałeś, że dwie rzeczy się różnią, a nie że przyczyną jest port.

Czego ten pomiar nie może potwierdzić

Nie pokazuje, że tunel jest ogólnie szybszy, że cokolwiek kompresuje ani że inne porty na łączu są nieograniczone. Opisuje ten transfer, na tym łączu, o tej godzinie. Limity mogą obowiązywać na sesję, na abonenta lub zależnie od pory dnia, i mogą się zmienić bez zapowiedzi.

Nie dowodzi też, że bezpośrednia trasa jest zepsuta. Ograniczona trasa nadal działa; jest ograniczona celowo, a świadoma polityka nie jest awarią czekającą na naprawę.

I na pewno nie uzasadnia kierowania wszystkiego przez tunel. Każda aplikacja na porcie 80 pozostaje ograniczona, a wszystko, co przekierujesz, zależy teraz od dodatkowego przeskoku i dodatkowego trybu awarii.

Zamień ustalenie w coś wykonalnego

Zapisz obserwację jako pomiar, a nie wyrok: duże transfery na porcie 80 osiadają w okolicy połowy szybkości, jaką ten sam plik osiąga na innym porcie, o tych godzinach, na tym łączu, z tymi próbkami w załączeniu. To prośba o wsparcie, którą ktoś może zbadać.

„VPN jest szybszy” nie jest. Zaprasza to odpowiedź o narzucie szyfrowania, a ta odpowiedź jest technicznie poprawna, nie mówiąc nikomu nic użytecznego. Dołącz liczbę próbek, godzinę i port, żeby czytelnik mógł odtworzyć wzorzec.

Jeśli zdecydujesz się nadal używać innego portu do dużych transferów, zanotuj zastrzeżenie we własnych zapisach: przeniesienie nasłuchu na port 80 koliduje z każdym serwerem webowym, który jest tam już przypisany, a wynikająca z tego awaria wygląda jak zepsuty tunel, a nie jak konflikt portów.

Powiązane artykuły