Dlaczego pobieranie przez VPN ogranicza wysyłanie serwera

Klient pokazuje szybkie łącze pobierania, serwer siedzi na łączu światłowodowym, a transfer i tak się wlecze. Liczba, którą ludzie porównują, to zwykle ta wydrukowana w planie klienta, podczas gdy pakiet najpierw przechodzi przez wychodzące łącze dostępowe serwera. To łącze jest budżetem, w który transfer musi się zmieścić. W małym łączu domowym to najmniejsza liczba na ścieżce.

Liczba, którą przeczytałeś, była w złym kierunku

Pobieranie do zdalnego klienta zużywa przepustowość wysyłania na serwerowym końcu tunelu. Ogłaszane szybkości pobierania serwera opisują przeciwny kierunek i nie mówią nic o tym. Ta sama asymetria odwraca się, gdy klient wysyła, dlatego jeden kierunek może wydawać się dobry, a drugi bezużyteczny.

Narzut enkapsulacji i każdy konkurencyjny ruch zużywają część tego samego budżetu. Żaden z nich nie jest widoczny w teście prędkości, który mierzy tylko klienta.

Zapisz ścieżkę jako budżet

Wypisz każdą granicę, którą pakiet musi przekroczyć, i daj każdej liczbę w tej samej jednostce. Dostarczenie ze źródła, przetwarzanie na serwerze, łącze wysyłania serwera, ścieżka pośrednia, łącze pobierania klienta i przetwarzanie po stronie klienta — wszystkie obowiązują. Użyteczna prędkość to najmniejsza z nich minus narzut, a żadne strojenie powyżej tego pułapu nie zmienia wyniku. Zapisz listę przed pomiarem, bo mówi, której liczbie nie wierzyć.

Przy łączu wysyłania serwera 20 Mbit/s i łączu pobierania klienta 100 Mbit/s serwer ogranicza transfer dużo wcześniej, niż klient to zauważy. Narzut i każdy jednoczesny transfer zabierają kolejną część, a nasycone łącze wysyłania opóźnia też potwierdzenia, co spowalnia transfer TCP poniżej surowego pułapu. Żaden z tych dwóch efektów nie pojawia się w porównaniu planów.

Trzymaj megabity i megabajty osobno i mów, czy każda liczba mierzy ruch zaszyfrowanego łącza, czy ładunek aplikacji. Mieszanie tych dwóch to najczęstsza przyczyna tego, że budżet wydaje się nie sumować. Oznacz każdą liczbę jej jednostką i punktem pomiaru.

Gdzie płyta naprawdę cię kosztuje

Gdy łącze dostępowe jest wystarczająco duże, sprzęt punktu końcowego staje się widoczny i dopiero wtedy procesor ma znaczenie. Zidentyfikuj model, układ interfejsów i użytą implementację. Obserwacja o współdzielonej magistrali wczesnej płyty nie opisuje każdej późniejszej rewizji.

Porównuj pojedyncze ścieżki przetwarzania, a nie jedną średnią CPU. Umiarkowane obciążenie całkowite może ukryć jedno nasycone jądro wykonujące całą pracę na pakiet, a częstotliwość taktowania nie przenosi się między projektami procesorów jako ocena wydajności. Szybkość pakietów jest równie ważna jak przepustowość, bo małe pakiety kosztują więcej na bajt niż duże. Mierz rozmiarami pakietów, których twoje obciążenie faktycznie używa.

Granice termiczne i mocowe również decydują o zachowaniu trwałym. Krótki wybuch może wyglądać świetnie, podczas gdy transfer trwający dziesięć minut jest dławiony, dlatego benchmark z kilku sekund jest złym przewodnikiem dla nocnej kopii zapasowej.

Wytyczne wydajności producenta rozdzielają przepustowość dostępu, CPU, przetwarzanie pakietów, transport i rozmiar pakietu na odrębne ograniczenia. Warto je przeczytać przed zmianą szyfru, bo zmiana szyfru rzadko przesuwa granicę, która nigdy nie była ograniczeniem.

Zmierz, zanim zmienisz szyfr

Uruchom test kierunkowy, który podaje prędkość faktycznie osiągniętą przez tunel, a następnie uruchom ten sam test na surowym interfejsie dla porównania. Różnica między tymi dwiema liczbami to koszt tunelu, a mniejszy z dwóch pułapów mówi, którą granicę atakować.

Zachowaj politykę bezpieczeństwa nietkniętą podczas porównywania. Stary wynik uzyskany ze słabym szyfrem lub podkręconą płytą nie jest planem dla bieżącego wdrożenia.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Przechowuj wyniki kierunkowe obok obserwacji punktu końcowego z tego samego przebiegu. Następna zmiana powinna celować w zmierzony pułap, a nie w komponent, który wygląda najmniejszy w karcie katalogowej.