Zanim zaczniesz
Zapisz adres gry, protokół, czas, metodę oraz użyte łącze. Porównaj niezależne połączenia, jeśli to możliwe. Zmiana ochrony wymaga uzgodnionej topologii i danych operatora; port webowy nie reprezentuje automatycznie rzeczywistego ruchu gry.
Mierz właściwe połączenie
Ping, HTTP, TCP i UDP mogą obejmować różne trasy albo przetwarzanie. Opisz test i nie przedstawiaj wyników jako tego samego pingu gry. TCP na porcie 443 opisuje połączenie ze stroną, nie opóźnienie FiveM czy Bedrock UDP. Używaj przydzielonego endpointu i zapisz elementy pośrednie, żeby porównania dotyczyły tej samej usługi i rzeczywistego układu sieci.
Rozróżnij RTT i jeden kierunek
RTT obejmuje drogę w obie strony, niekoniecznie po tych samych trasach. Dzielenie przez dwa nie daje wiarygodnego pomiaru w jednym kierunku. Potrzebne są odpowiednia metoda i odniesienie czasowe. Dobrze opisana seria RTT jest często praktyczniejsza od pozornie dokładnej liczby. Notuj godzinę, miejsce i sposób pomiaru oraz to, jaki kierunek albo sumę dróg naprawdę badano.
Zapisuj wahania i utratę
Pojedyncza szybka odpowiedź może ukryć dużą zmienność. Zbierz próbki, medianę, odstające wyniki oraz utratę pakietów. Szybkie otrzymane odpowiedzi nie rekompensują automatycznie brakujących. Porównuj spokojne i problematyczne okresy; operatorzy z tego samego kraju mogą się różnić. Jedno łącze nie daje podstaw do gwarancji dla całego kraju. Zachowaj również metodę liczenia brakujących odpowiedzi.
Uwzględnij chronioną trasę
Filtrowanie, dostarczanie i tunele mogą zmienić drogę do źródła. Dodatkowa odległość i punkty wymiany mają znaczenie; więcej wspólnej przepustowości nie oznacza mniejszego opóźnienia. Podawane 15 Tbps CubixServ nie są obietnicą pingu. Zapytaj o faktyczny przebieg oraz zachowanie podczas incydentu, w tym możliwe zmiany routingu, a nie tylko wynik przy normalnym obciążeniu.
Oddziel sieć od pracy serwera
Przeciążony główny wątek, zablokowane zapytania lub nowe chunki mogą spowalniać grę bez podobnego wzrostu pingu. Mierz CPU, konsolę i profile razem. Minecraft wymaga analizy chunków i efektywnego zasięgu, FiveM zasobów i zdarzeń. Więcej RAM nie naprawia automatycznie CPU lub sieci: zmieniaj potwierdzoną przyczynę i porównuj wyniki, nie tylko subiektywne odczucia graczy.
Dokumentuj odtwarzalne porównania
Używaj podobnych łączy, protokołów i okresów przed i po zmianie. Zachowaj medianę, utratę, skrajne wartości i stan serwera, a wątpliwy wynik powtórz w ograniczonym zakresie. Francja może sprzyjać wielu europejskim połączeniom, ale nie gwarantuje stałej liczby dla kraju. Przekaż pomocy odtwarzalny opis i nie przypisuj każdej zwłoki atakowi bez zgodnych danych sieciowych i aplikacyjnych.
Co zrobić w Twojej sytuacji
| Sytuacja | Następny krok |
|---|---|
| Tylko jeden gracz ma opóźnienia | Porównaj jego łącze z niezależnym dostępem i zapisz trasę oraz godzinę. |
| Ping stabilny, gra wolna | Badaj główny wątek, zasoby i bazę danych podczas tej samej sesji. |
| Zmiana wraz z ochroną | Porównaj ten sam endpoint i metodę przed i po uzgodnionej modyfikacji. |
Oficjalne źródła
Te źródła opisują wymienione protokoły i ustawienia. Sprawdź dokumentację właściwą dla używanej wersji.