Dlaczego pobieranie jest szybsze przez VPN niż bezpośrednio

Zaczynasz duże pobieranie, pierwsze sekundy wyglądają normalnie, a potem prędkość ustala się na około połowie tego, co linia powinna dostarczać. Łączysz się z tunelem, powtarzasz to samo pobieranie i utrzymuje on wyższą prędkość przez cały plik. To jednocześnie realny pomiar i mylący wniosek, ponieważ tunel nie przyspieszył ścieżki. Po prostu przeniósł twój ruch z portu, który coś po drodze ograniczało.

Zdradza to kształt krzywej

Obserwuj transmisję, a nie końcową liczbę. Ograniczona ścieżka zwykle zaczyna się blisko prędkości łącza, zużywa swój limit burst i osiada na limicie, więc średnia zależy od tego, jak długo patrzyłeś. Tunel, który naprawdę poprawiłby ścieżkę, pokazywałby lepszą prędkość od pierwszej sekundy i utrzymywał ją. Plateau jest odciskiem palca i łatwo je przeoczyć, jeśli notujesz tylko szczyt.

Dwa przebiegi tego samego pliku, jeden bezpośredni i jeden przez tunel, wystarczą, by sprawdzić, czy plateau istnieje.

Zauważ, kiedy zaczyna się plateau, jak długo trwa i jaką prędkość utrzymuje. Te trzy wartości odróżniają ustawiacz od zatłoczonej ścieżki, bo przeciążenie pozwala prędkości wędrować, a ustawiacz przybija ją do jednej liczby. Jeśli przebieg bezpośredni stopniowo się pogarsza, a przebieg przez tunel pozostaje stabilny, patrzysz na politykę, a nie na fizykę.

Trzy porównania, po jednej zmiennej

Zmieniaj jedną rzecz na przebieg, inaczej niczego się nie dowiesz. Pobierz ten sam plik zwykłą ścieżką webową, potem narzędziem do transferu, które używa innego portu, z hosta o porównywalnej wydajności i o tej samej godzinie. Trzymaj maszynę klienta bez zmian, bo laptop przemieszczający się między sieciami dodaje zmienną, której nie kontrolujesz.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Użyj pliku już skompresowanego, na przykład obrazu dysku, żeby kompresja transportowa nie mogła wyjaśnić różnicy. Następnie, jeśli kontrolujesz serwer, przenieś jego nasłuch na port, który podejrzewasz o ograniczenie, zaktualizuj profil klienta i powtórz. Gdyby tunel spadł teraz do ograniczonej prędkości, limit podąża za portem, a nie za tunelem, i sprawa jest rozstrzygnięta. Każde porównanie wykonaj dwa razy i zachowaj liczby plateau, a nie szczyty.

Zanotuj też godzinę, bo ustawiacz może działać według czasu, a test wieczorny może nie zgodzić się z porannym. Dwa przebiegi o tej samej godzinie są warte więcej niż dziesięć rozrzuconych po całym dniu.

Czego ten pomiar nie może uzasadnić

Nie pokazuje, że tunel jest ogólnie szybszy, że cokolwiek kompresuje ani że inne porty nie są ograniczone. Opisuje jeden transfer na jednej linii w ciągu jednej godziny. Limity mogą być na sesję, na abonenta albo czasowe, a operator może je zmienić bez zapowiedzi.

Nie pokazuje też, że bezpośrednia ścieżka jest wadliwa. Ograniczona ścieżka działa dokładnie tak, jak zamierzono, jest po prostu ograniczona polityką.

To rozróżnienie ma znaczenie, gdy to opisujesz. Awaria prosi o zgłoszenie naprawcze, a polityka prosi o pytanie o umowę albo decyzję, by ją obejść. Nazwanie limitu awarią tworzy rozmowę z pomocą techniczną, która zaczyna się od błędnego założenia. Nazwanie go polityką pozwala zadać konkretne pytanie, które ma konkretną odpowiedź.

Zamień ustalenie w prośbę o wsparcie

Użyj liczb i pomiń wniosek. Prośba, która stwierdza, że duże transfery przez port 80 utrzymują się w tych godzinach na około połowie oczekiwanej prędkości, z załączonymi liczbami plateau, jest wykonalna. Prośba mówiąca, że VPN jest szybszy, taka nie jest, bo czyta się jak twierdzenie o tunelu, a nie obserwację o linii. Załącz oba przebiegi i ich znaczniki czasu, a potem pozwól operatorowi opisać politykę.

Nie wpychaj każdej aplikacji do tunelu tylko po to, by gonić tę liczbę.

Tunel nadal kosztuje cię dodatkowy przeskok, szyfrowanie i nowy zestaw trybów awarii, podczas gdy ograniczony port pozostaje ograniczony dla wszystkiego innego, co go używa. Gdy duże transfery muszą kończyć się niezawodnie, prowadź własną notatkę o tym, który port niesie limit. Przeniesienie nasłuchu na port 80 koliduje też z każdym serwerem webowym już do niego przypisanym, a to daje nową awarię zamiast poprawki.