Wysyłanie przez VPN wolniejsze niż pobieranie? Ustal, na jaki limit trafiasz

Większość linii dostępowych jest asymetryczna, więc tunel zwykle wysyła wolniej, niż pobiera, i to jest oczekiwana odpowiedź, a nie usterka. Ciekawe pytanie brzmi, czy twoje wysyłanie ogranicza linia, coś innego, co już jej używa, czy przepływ, który zatrzymuje się zamiast płynąć równo. Te trzy dają tę samą skargę i wymagają innej pracy.

Trzy limity, które z paska postępu wyglądają identycznie

Przepustowość to pierwszy, i jest cechą produktu dostępowego, a nie tunelu. Łącze wysyłowe o kilku megabitach jest normalne w światłowodzie dla konsumentów i w wielu planach komórkowych, a koszt szyfrowania jest mały wobec tej różnicy. Enkapsulacja dodaje też bajty do każdego pakietu, co obcina użyteczną przepustowość w obu kierunkach, a nie tylko w jednym, więc sama nie wyjaśni dużej asymetrii.

Współzawodnictwo to drugi. Synchronizacja w chmurze, biblioteki zdjęć i agenci aktualizacji wysyłają, gdy maszyna wygląda na bezczynną, a drugie urządzenie na tej samej linii robi to samo. Kolejkowanie to trzeci: nasycone łącze wysyłowe spycha ruch interaktywny za danymi masowymi, więc rozmowy się rwą, podczas gdy sam transfer raportuje zdrowy postęp.

Mierz jeden kierunek naraz

Użyj tego samego urządzenia, tego samego profilu i tego samego celu, i nigdy nie uruchamiaj obu kierunków jednocześnie, chyba że właśnie współzawodnictwo chcesz obserwować. Wstrzymaj własne opcjonalne transfery przed pierwszym przebiegiem. Dwa przebiegi z jedną flagą pomiędzy rozstrzygają większość.

iperf3 domyślnie wysyła z klienta, więc zwykły przebieg mierzy twoją ścieżkę wysyłania; -R odwraca kierunek i mierzy pobieranie. Uruchom je w odstępie kilku minut i zapisz obie liczby zamiast je uśredniać:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Jeśli liczba wysyłania to mały ułamek liczby pobierania i pozostaje stabilna między przebiegami, kształt odpowiada asymetrycznej linii dostępowej i tunel nie jest tu historią. Jeśli wysyłanie waha się między przebiegami albo załamuje się po dziesięciu sekundach, czytaj dalej.

Rozstrzygnij po tym, gdzie zmienia się wysyłanie

Zmieniaj jedną zmienną naraz i patrz, który kierunek się rusza. Drugi punkt końcowy VPN, który wysyła lepiej, wskazuje na ten punkt lub trasę do niego. To samo wolne wysyłanie z drugiego urządzenia na tej samej linii wskazuje na linię. Inne urządzenie na innej linii, które też jest wolne, wskazuje na politykę wejściową celu, której lokalnie nie naprawisz.

Zapisuj bajty na sekundę i upływający czas dla tego samego obciążenia, a nie jeden wynik prędkości. Klient kopii zapasowych i test prędkości używają różnych celów i różnej współbieżności, więc porównywanie ich liczb nic nie odpowiada. Jeśli małe żądania są w porządku i tylko duże transfery się wloką, limit prawdopodobnie wcale nie jest przepustowością.

W codziennym użyciu ograniczenie wysyłania w tle albo zaplanowanie go poza godzinami spotkań często pomaga bardziej niż jakiekolwiek ustawienie tunelu. Oceń tę zmianę po łącznym obciążeniu: kopia zapasowa, która kończy się później, ale nie psuje już rozmów, jest zwykle lepszą wymianą.

Gdy zatrzymanie wygrywa z powolnością

Transfer, który zastyga w powtarzalnym punkcie, a potem rusza dalej, zachowuje się jak problem MTU ścieżki, a nie limit szybkości. Tunel zmniejsza użyteczny ładunek na pakiet, a urządzenie, które odrzuca wynikający komunikat ICMP, zostawia nadawcę z domysłami. Ten wzorzec zasługuje na własny test, bo naprawa różni się od strojenia szybkości. Stała niska liczba wskazuje na przepustowość, a wybuch, po którym następuje cisza, wskazuje na ładunek, którego ścieżka nie uniesie.

Przetestuj ścieżkę ładunkiem, którego nie wolno fragmentować, a potem porównaj MTU interfejsu tunelu z wartością, która przechodzi:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Jeśli duża sonda znika, a mniejsza przechodzi, ściśnij TCP MSS na tunelu zamiast obniżać MTU interfejsu dla każdego protokołu. Uporczywe zatrzymania po tym punkcie należą do pamięci masowej lub tempa aplikacji odbierającej, a nie do ścieżki sieciowej.

Co zmienić, a co zostawić

Zmieniaj to, co kontrolujesz: harmonogramy transferów w tle, wybór punktu końcowego i MSS dla zatrzymującej się ścieżki. Utrzymuj każdą zmianę odwracalną i ograniczoną do jednego obciążenia. Zostaw w spokoju to, co pomiar uznaje za dobre, w tym prędkość pobierania, która już pasuje do linii.

Zapisz liczby przed i po wraz z profilem, punktem końcowym i porą dnia, bo problem wysyłania, który przesuwa się z punktem końcowym, jest kwestią routingu, a ten, który przesuwa się z urządzeniem, jest lokalny. Właśnie ten zapis zmienia mgliste skargi w decyzję, a kosztuje dwa przebiegi tego samego polecenia.