Jakie są oznaki ostrzegawcze, że przekaźnik tunelowy ogranicza przepustowość?

Przekaźnik prawdopodobnie ogranicza przepustowość, gdy połączenie pozostaje przekazywane, a wydajność znacznie poprawia się przy bezpośredniej lub bliższej ścieżce, podczas gdy oba końce pozostają niewykorzystane.

VPN-y nakładkowe i tunele wychodzące często przełączają się na współdzielony lub samodzielnie hostowany przekaźnik, gdy NAT traversal nie może utworzyć ścieżki peer-to-peer. Przekaźnik może zachować łączność, ale dodaje kolejny odcinek sieci, kolejkę, warstwę TCP lub TLS, geograficzne obejście, limit sprawiedliwości i punkt przetwarzania. Rzetelna diagnoza porównuje status przekaźnika, opóźnienie, jitter, kierunek, CPU punktów końcowych oraz kontrolę ścieżki bezpośredniej, zamiast obwiniać szyfrowanie lub NAS na podstawie jednego wolnego kopiowania plików.

Potwierdź, że ścieżka danych jest faktycznie przekazywana

Sprawdź status peer klienta tunelu podczas aktywnego ruchu. Zanotuj, czy ścieżka jest bezpośrednia, przekazywana, pośredniczona czy przełączająca się między trybami, oraz wybraną region lub host przekaźnika.

Problem Tailscale dokumentuje klientów komórkowych pozostających na DERP z opóźnieniem od 200 do 900 milisekund. Status połączenia zatem potwierdza dostępność, a nie efektywną ścieżkę danych.

Jeśli klient zgłasza bezpośrednią łączność przez cały czas wolnego testu, nie oznaczaj przekaźnika jako przyczyny. Kontynuuj testy CPU punktów końcowych, odciążenia tunelu, MTU, uploadu ISP, Wi-Fi i pamięci masowej.

Porównaj ścieżki przekazywane i bezpośrednie z tymi samymi punktami końcowymi

Przeprowadź test przepustowości sieciowej między tym samym klientem a serwerem domowym podczas przekazywania, a następnie powtórz po ustanowieniu bezpośredniej ścieżki peer lub tymczasowej sieci testowej z dostępnym portem. Zachowaj ten sam protokół, kierunek i sprzęt punktów końcowych.

Opublikowany przypadek peer-relay zmierzył zarówno duże zmniejszenie opóźnienia, jak i 12,5-krotny wzrost przepustowości po zmianie tylko topologii przekaźnika.

Duża i powtarzalna poprawa po usunięciu lub przeniesieniu przekaźnika to silny dowód. Mała zmiana oznacza, że przekaźnik może nie być dominującym wąskim gardłem, zwłaszcza gdy upload domowy lub zdalne Wi-Fi już ustalają niższy limit.

Obserwuj wysokie opóźnienie, jitter i geograficzne obejścia

Zmierz minimalne, medianę i wysokie percentyle opóźnienia do peer i do regionu przekaźnika. Zanotuj jitter i utratę pakietów podczas okresów bezczynności i podczas ciągłego transferu.

Niezależny raport diagnostyczny zarejestrował ścieżkę przekazywaną z średnim opóźnieniem powyżej 400 ms, znacznym jitterem i mierzalną utratą pakietów, co może powodować załamanie transferów plików TCP i interaktywnego dostępu, nawet gdy tunel pozostaje ustanowiony.

Jeśli przekaźnik jest geograficznie daleko od obu punktów końcowych lub opóźnienie znacznie się waha pod obciążeniem, przetestuj bliższy region, samodzielnie hostowany przekaźnik lub przekaźnik peer. Stabilne niskie opóźnienie przekaźnika przy słabej przepustowości wskazuje raczej na ograniczenia pojemności, sprawiedliwości, CPU lub zachowania transportu.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź, czy przekaźnik ma stały limit przepustowości

Przeprowadź kilka dużych transferów o różnych porach i w obu kierunkach. Limit przekaźnika często objawia się jako stabilny plateau, który nie rośnie, gdy poprawia się prędkość internetu punktów końcowych, pamięć NAS lub Wi-Fi klienta.

Prace benchmarkingowe nad implementacjami przekaźników pokazują, że pojemność przekazywania, efektywność CPU i obciążenie współbieżne mają istotny wpływ na przepustowość tunelu. Aktualny projekt kompatybilny z DERP publikuje benchmarki przekaźników przy wielu obciążeniach dla różnych rozmiarów CPU i poziomów ruchu.

Jeśli jeden strumień osiąga plateau, dodaj drugi kontrolowany strumień i obserwuj całkowitą przepustowość. Stały wspólny limit sugeruje pojemność przekaźnika lub ścieżki; niezmiennie niska przepustowość przy bezczynnym CPU przekaźnika wskazuje na RTT, utratę, kontrolę przeciążenia lub ograniczenia punktów końcowych.

Oddziel limity przekaźnika od CPU punktów końcowych i uploadu ISP

Monitoruj CPU, przerwania programowe, użycie procesów szyfrowania, wykorzystanie karty sieciowej i aktywność dysku na obu punktach końcowych oraz na samodzielnie hostowanym przekaźniku. Porównaj wolny kierunek z zmierzoną przepustowością uploadu i downloadu połączenia domowego.

Przekaźnik może przekazywać dane tylko tak szybko, jak jego najsłabszy odcinek przychodzący lub wychodzący. Uruchamianie przekaźnika na VPS niskiej klasy, w odległym regionie, ograniczonym kontenerze lub współdzielonym łączu domowym może powodować ten sam objaw co limit zarządzanego przekaźnika.

Jeśli CPU punktu końcowego lub przekaźnika osiąga nasycenie, dostosuj lub zaktualizuj ten węzeł przed zmianą lokalizacji przekaźnika. Jeśli CPU jest niskie, ale jeden kierunek ISP jest pełny, przekaźnik ujawnia limit łącza dostępowego, a nie go tworzy.

Zmień projekt przekaźnika na granicy zatrzymania

Zamień ścieżkę przekaźnika, gdy pozostaje wybrana dla normalnego ruchu, powoduje nieakceptowalne opóźnienie lub jitter, ogranicza utrzymaną przepustowość poniżej wymagań obciążenia, a bezpośrednia lub bliższa kontrola przekaźnika dowodzi, że reszta ścieżki może działać lepiej.

Przewodnik ZimaSpace po alternatywach dostępu zdalnego CGNAT wyjaśnia, dlaczego przekaźnik może być konieczny, nawet jeśli nie jest najszybszą ścieżką.

Wybierz bliższy przekaźnik peer, lepiej położony VPS, ulepszone NAT traversal lub przepływ pracy o niższej przepustowości zamiast wyłączania jedynej dostępnej ścieżki bez zamiennika. Zweryfikuj nowy projekt za pomocą oryginalnego zdalnego pliku, mediów lub obciążenia synchronizacji, a nie tylko krótkiego pinga.