Czy VPN może być szybszy niż połączenie bezpośrednie?

Transfer, który pełznie na łączu biurowym, przez tunel czasem kończy się szybko, a dodatkowa enkapsulacja sprawia, że wygląda to na niemożliwe. Pozorny paradoks bierze się z porównywania niewłaściwych rzeczy. Tunel dodaje pracy, a także zmienia którą ścieżką sieci podąża ruch, jaki adres widzi cel i czasem który serwer w ogóle odpowiada. Decyzja między dwiema trasami wymaga rozdzielenia tych trzech efektów przed jakimkolwiek wnioskiem o szybkości.

Trzy rzeczy, które tunel może zmienić

Pierwsza to tranzyt. Routing internetowy kieruje się polityką operatora i relacjami biznesowymi, a nie zmierzonym opóźnieniem, więc droga przez dostawcę VPN może przechodzić przez inne sieci niż trasa bezpośrednia. Może ominąć zatłoczony punkt wymiany albo trafić na lepiej połączony, i równie łatwo może być gorsza.

Druga to cel. Zmiana adresu wyjściowego często zmienia odpowiedź DNS, a sieć dostarczania treści może dać inny cache lub inny region. Wtedy część poprawy należy do nowego serwera, a nie do tunelu. Ta sama nazwa hosta może trafić na bliższy lub mniej obciążony serwer, choć po stronie klienta nic się nie zmienia.

Trzecia to zachowanie transportu. Enkapsulacja zmienia efektywny rozmiar pakietu, a tunel omijający stratny środkowy odcinek może pozwolić przepływowi TCP powiększać okno zamiast wielokrotnie się wycofywać. Żaden z tych efektów nie jest uniwersalnym mechanizmem przyspieszania; każdy jest warunkiem, który trzeba zaobserwować. To właśnie ich rozdzielenie zamienia ciekawostkę w fakt.

Czego nie może zmienić

Nic w tunelu nie dodaje przepustowości łączu między urządzeniem a siecią. Zasycone łącze Wi-Fi, zatłoczona ostatnia mila albo limitowany plan komórkowy ograniczają obie trasy tak samo, a test szybkości przez tunel nie może przekroczyć tego pułapu. To samo łącze niesie pakiety enkapsulowane, więc enkapsulacja może zużywać przepustowość, ale nigdy jej nie tworzy. Zmienia się to, dokąd pakiety idą po opuszczeniu tego łącza. Dlatego szybki wynik przez tunel zawsze ma wyjaśnienie powyżej pierwszego skoku.

Ograniczenia po stronie serwera są równie obojętne. Jeśli zdalny host obsługuje wolno, lepsza droga tylko dostarcza wolną odpowiedź sprawniej, a użytkownik nadal czeka. Współdzielone źródło pod obciążeniem wygląda wolno na obu trasach w tej samej chwili.

Porównuj trasy poprawnie

Utrzymuj identyczną aplikację, kierunek, czas trwania i współbieżność, a zmieniaj tylko trasę. Uruchamiaj każdy test więcej niż raz, o tej samej porze dnia, i zapisuj adres wyjściowy oraz odpowiedź resolvera obok przepustowości. Pojedyncze uruchomienie to próbka, a nie pomiar, a jedno szybkie pobranie może być trafieniem w cache, które nic nie mówi o trasie. Zapisz warunki przed wynikami, bo liczby trudno potem zinterpretować.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Odpowiedź resolvera to szczegół, który większość porównań pomija, i wyjaśnia „poprawy”, które znikają po wymuszeniu tego samego serwera. Jeśli adres różni się między uruchomieniami, test porównał dwa cele, a nie dwie trasy. Podawaj opóźnienie i straty obok przepustowości, bo trasa szybsza ogólnie, ale dodająca opóźnienie do każdego żądania interaktywnego, nie jest lepsza dla obciążenia, które się skarżyło. Czas rundy liczy się bardziej niż szybkość masowa dla wszystkiego, co pyta i czeka.

Kiedy różnicę warto zachować

Jeśli zatwierdzony tunel niezawodnie poprawia określone obciążenie, jest to uzasadniony wybór operacyjny: udokumentuj obciążenie, pomiar i użyte wyjście. Użyteczny zapis nazywa jeden host, adres wyjściowy utworzony przez tunel, odpowiedź resolvera i te same liczby z trasy bezpośredniej tego samego dnia. To wystarcza kolejnemu inżynierowi, by powtórzyć porównanie, a nie rozstrzygać je od nowa. Wciąż nie jest to dowód, że dostawca cokolwiek ogranicza, i nie przenosi się na inne aplikacje ani inne godziny.

Przechowuj zapis pomiaru razem z konfiguracją. Odpowiada na następne pytanie, czy poprawa nadal istnieje, i to jedyny sposób, by wiedzieć, czy zmieniła się trasa czy obciążenie. Zapis bez daty nie może odpowiedzieć na to pytanie w ogóle.