Dlaczego prędkość WireGuard VPN spada przy dużych opóźnieniach

Wprowadzenie

Wielu użytkowników jest zaskoczonych, gdy z innego kraju łączą się z serwerem WireGuard na swoim routerze GL.iNet i odkrywają, że prędkość Internetu jest znacznie niższa niż symetryczna gigabitowa prędkość w ich domu lub podobnie szybkie łącze w miejscu pobytu za granicą, np. w Airbnb. Zwykle winny może być dostawca Internetu po stronie serwera lub klienta. Często pomija się jednak opóźnienie, choć ma ono realny i znaczący wpływ na przepustowość, czyli prędkość pobierania i wysyłania. Ten wpis ma pomóc w ustaleniu realistycznych oczekiwań i wyjaśnić, dlaczego prędkość spada przy dużych opóźnieniach, widocznych np. w wynikach ping.

Czym jest opóźnienie i dlaczego ma znaczenie?

Opóźnienie to czas potrzebny na przesłanie danych z urządzenia do serwera VPN i z powrotem. Często mierzy się je w milisekundach (ms). Na przykład gdy router GL.iNet w Wietnamie łączy się z serwerem VPN w Teksasie, czas przejścia w obie strony (RTT) może z łatwością wynosić 250-300 ms.

Nawet jeśli Internet jest technicznie „szybki”, duże opóźnienia mogą znacznie ograniczyć rzeczywistą wydajność pobierania i wysyłania, zwłaszcza przy korzystaniu z protokołów opartych na TCP, takich jak HTTPs, przesyłanie plików czy większość aplikacji. Pamiętaj: choć sam WireGuard używa UDP, ruch przesyłany przez tunel VPN, np. ruch internetowy czy strumieniowanie, często opiera się na TCP. WireGuard opakowuje te dane TCP w UDP i wysyła je przez Internet.

Wąskie gardło TCP: przepustowość zależy od opóźnienia

Oto kluczowy wzór opisujący wydajność TCP:

Rozmiar okna TCP = przepustowość x RTT
Najpierw kilka definicji:

• Rozmiar okna TCP to ilość danych, które system pozwala przesłać bez potwierdzenia odbioru, zanim zażąda takiego potwierdzenia.
• Przepustowość to rzeczywista prędkość, czyli ilość danych, które można wysłać lub odebrać w ciągu sekundy.
• RTT (Round-Trip Time, czas przejścia w obie strony) to opóźnienie między wysłaniem a odebraniem pakietów.

Rzeczywisty przykład od użytkownika subreddita GL.iNet

Załóżmy, że przebywasz w Wietnamie i łączysz się z domowym serwerem WireGuard VPN w Teksasie, działającym na routerze GL.iNet Flint 2.

• Lokalizacja serwera: Teksas, USA
  
  • Prędkości lokalne (symetryczne łącze światłowodowe) 700 Mbps pobierania / 940 Mbps wysyłania
• Lokalizacja klienta: Wietnam
  
  • Prędkości lokalne (bez VPN): 455 Mbps pobierania / 634 Mbps wysyłania
    
  • Prędkości lokalne (z włączonym klientem WireGuard VPN): 47.3 Mbps pobierania / 12.1 Mbps wysyłania, ping 288 ms

Najpierw przyjrzyjmy się kilku typowym ograniczeniom każdego połączenia sieciowego:

1. Zmienna wydajność dostawcy Internetu i przeciążenie sieci w okolicy: prędkość może zmieniać się nawet o wielokrotność 100 Mbps
2. Wydajność Wi-Fi: bardzo zmienna, zależna od otoczenia, zakłóceń ze strony innych urządzeń bezprzewodowych, możliwości urządzenia klienckiego oraz działania Wi-Fi w trybie półdupleksowym, w przeciwieństwie do pełnego dupleksu Ethernet
   • Szczegółowe wyjaśnienie rzeczywistej wydajności Wi-Fi znajdziesz tutaj: https://www.wiisfi.com/ Ograniczenie nr 1 jest poza Twoją kontrolą. Ograniczenie nr 2 również w większości pozostaje poza nią, ale można je potencjalnie wyeliminować, korzystając z przewodowych połączeń Ethernet wszędzie tam, gdzie to możliwe.

Iloczyn przepustowości i opóźnienia

Na pierwszy rzut oka wyniki testu prędkości VPN po stronie klienta mogą rozczarowywać, ale w rzeczywistości są całkiem dobre przy takim opóźnieniu. Oto wyjaśnienie z wykorzystaniem wcześniejszego wzoru:
Rozmiar okna TCP = 47.3 Mbps x 0.288 sekundy
　 　 　 　    = 13.6 Mb, czyli ~1.7 MB

Okno TCP o rozmiarze 1.7 MB jest w rzeczywistości dość duże, a osiągnięcie tego rozmiaru przy opóźnieniu 288 ms oznacza, że TCP działa całkiem dobrze. Jak to jednak możliwe, skoro pierwotne pole rozmiaru okna TCP jest ograniczone do zaledwie 65,535 bajtów (około 64 KB)?

Skalowanie okna TCP dla lepszej wydajności

Odpowiedź kryje się w funkcji skalowania okna TCP, wprowadzonej z myślą o nowoczesnych sieciach o dużej przepustowości i dużych opóźnieniach. Jak opisuje Microsoft w tym artykule, pole rozmiaru okna TCP ma tylko 16 bitów, co ogranicza nieskalowane okno do 65,535 bajtów. Aby to obejść, w RFC 7323 wprowadzono opcję skalowania okna TCP, która pozwala przesunąć rozmiar okna w lewo nawet o 14 bitów, zwiększając jego maksymalny rozmiar do 1 GB. Współczynnik skalowania jest negocjowany podczas trójetapowego uzgadniania połączenia TCP. Po włączeniu tej funkcji punkty końcowe mogą mnożyć pierwotny rozmiar okna. Algorytmy kontroli przeciążenia w systemach operacyjnych urządzeń klienckich nieustannie ustalają właściwe skalowanie rozmiaru okna. W niektórych przypadkach, np. w systemie Microsoft Windows, automatyczne dostrajanie rozmiaru okna wyjątkowo źle radzi sobie z maksymalizacją przepustowości pobierania.

Przykład rozmiaru okna TCP negocjowanego przez system operacyjny i wpływu opóźnienia na przepustowość Źródło: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Dlaczego nie można po prostu stale zwiększać rozmiaru okna TCP

Ostatecznie rozmiar okna TCP zależy od dostępnej przepustowości i czasu przejścia w obie strony. Nie wystarczy jednak zwiększać rozmiaru okna, aby uzyskać wyższą przepustowość. Po przekroczeniu pewnego progu większe okna wymagają więcej pamięci i mocy obliczeniowej zarówno po stronie nadawcy, jak i odbiorcy. Może to przeciążyć urządzenia i sieci, zwiększyć utratę pakietów i obniżyć wydajność.

Dlatego w poprzednim przykładzie okno TCP o rozmiarze około 1.7 MB jest całkiem normalne i świadczy o dobrej wydajności połączenia przy dużym opóźnieniu. Ogólna górna granica wynosząca około 2 MB może stanowić praktyczny limit dla wielu nowoczesnych systemów, równoważąc przepustowość i zużycie zasobów. Przy oknie 2 MB i opóźnieniu 288 ms maksymalna teoretyczna przepustowość wynosi około 55.5 Mbps. Wyjaśnia to, dlaczego trudno osiągnąć wyższe prędkości mimo znacznie szybszych samych łączy internetowych po obu stronach: serwera i klienta. Jeśli przekształcimy wcześniejszy wzór, aby obliczyć przepustowość, zobaczymy, że przy opóźnieniu 80 ms i oknie 2 MB można teoretycznie osiągnąć około 200 Mbps. Niestety prawa fizyki nie pozwalają nam uzyskać takiego opóźnienia ze względu na fizyczną odległość (Teksas <-> Wietnam).

Podsumowanie

Mamy nadzieję, że ten artykuł wyjaśnił sytuację i pomoże Ci mieć bardziej realistyczne oczekiwania co do prędkości pobierania i wysyłania przy kolejnym korzystaniu z WireGuard VPN za granicą. Pamiętaj też, że routery obsługują wiele jednoczesnych sesji TCP. Choć ceniony GL.iNet Flint 2 ma aż 1 GB pamięci RAM DDR4, router kliencki połączony z tym Flint 2 może mieć znacznie mniej pamięci RAM i tym samym ograniczać skalowanie rozmiaru okna TCP.

Więcej informacji i wskazówek dotyczących rozwiązywania problemów oraz konfiguracji WireGuard VPN znajdziesz w następującym wpisie na forum GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Poznaj routery domowe GL.iNet