Přejít na obsah
Ochrana DDoS · Peeryx · 15 Tbps+
Všechny návody

Latence při ochraně DDoS: jak správně měřit trasu a hru

Jediný ping nevysvětluje odezvu herního serveru ani kvalitu ochrany. Vzdálenost, peering, zvolená trasa a práce aplikace ovlivňují různé části výsledku. Měřte opakovatelně stejné cíle, časy a protokoly a síťová data porovnejte se skutečným chováním hry.

← Všechny návodyCubixServ

Než začnete

Připravte veřejný endpoint, přidělený port a protokol a zaznamenejte operátora testujícího připojení. Uchovejte časy, běžnou zátěž a verze. Při porovnání ochrany používejte odsouhlasenou topologii; neodkrývejte původní server ani nevypínejte filtry bez dohodnutého omezeného testu.

Rozlišujte RTT a herní odezvu

RTT měří cestu tam i zpět. Jednosměrná měření potřebují odpovídající hodiny; dělení RTT dvěma není přesnou náhradou. TCP test webu neověří UDP hry. Samotný ping také nemusí používat stejné zpracování jako klient. Jasně označte endpoint, protokol a způsob měření, místo vydávání jedné webové hodnoty za skutečný herní ping všech uživatelů služby.

Místo nejlepšího výsledku porovnejte několik vzorků. Udržujte minimální, střední hodnotu a vysoké hodnoty vedle počtu vzorků. Variace a přerušení mohou mít větší význam než malý průměrný rozdíl. Oddělte zpoždění sítě od času hry na simulaci a reakci.

Měřte ze skutečných přístupů

Výsledky závisejí na síti uživatele a cílové trase, ne pouze na zemi. Dva operátoři v jednom městě mohou mít odlišné spojení. Místní Wi-Fi, sdílené připojení či zatížený přístup ovlivní výsledek. Porovnejte nezávislé přístupy a pokud možno stabilní místní podmínky. Jedna sonda nebo sousední datacentrum nejsou zárukou pro všechny hráče v celé oblasti.

Spárujte měření s normálním servisním připojením. Uchovávejte statistiky a kontext herní sítě, pokud jsou k dispozici. Mezilehlé zařízení může omezit diagnostické odpovědi při přesměrování provozu; tichý traceroute hop sám o sobě nedokazuje, že ztráta dosáhne hráče.

Sledujte rozdělení a ztráty

Uchovejte více vzorků, medián, kolísání a ztráty ve stejném intervalu. Jediný rychlý vzorek zakryje výpadky a jediný pomalý může být výjimka. Ztráty určujte pro skutečný cíl a test, ne jen z neodpovídajícího mezilehlého routeru. Směrovače mohou některé kontrolní zprávy omezovat; potvrďte dopad na celé spojení a dostupnost aplikace dříve, než označíte trasu za vadnou.

Místo výběru příznivých hodnot zachovat nezpracované výsledky a selhání. Zahrňte počet pokusů a dobu pozorování. Krátká základní linie ukazuje chování v té době; nejedná se o trvalou záruku latence nebo dostupnosti.

Oddělte cestu ochrany a aplikaci

Mitigace může změnit trasu, ale velká souhrnná kapacita neříká vlastní latenci služby. Uváděných 15 Tbps není port vašeho serveru ani pingová garance. Porovnejte odsouhlasené cesty se stejnými cíli a zátěží. Webový endpoint, soubory a herní UDP se mohou lišit; dokumentujte tyto rozdíly a přímý zdroj nevystavujte pouze kvůli pohodlnému srovnání ochrany.

U tunelů také prozkoumejte MTU a symptomy zahrnující velikost paketů. U serverů proxy zkontrolujte vypršení časového limitu a následná připojení. Neměňte několik součástí najednou. Před odstraněním pravidla, které přispívá k ochraně, potvrďte legitimní provoz.

Profilujte samotný server

Hra může zpomalit při normální síti kvůli hlavnímu vláknu, databázi či zpracování světa. Srovnejte profil, konzoli a využití ve stejný čas jako stížnost. Průměr CPU může skrývat jedno zatížené vlákno. Více RAM neopraví libovolnou latenci. Než vyměníte infrastrukturu, rozlište cestu paketů, čekání aplikace a klientskou zátěž a uchovejte reprodukovatelnou herní činnost pro další srovnání.

Pokud existuje kompatibilní nástroj, profil během zpomalení. Zprávy spark Paper mohou identifikovat nákladnou práci. Před provedením změn svázejte měření a zkopírujte konfiguraci. Nakupujte více zdrojů pouze tehdy, když to ospravedlňuje pozorované omezení.

Předávejte použitelný výsledek

Zapište čas, operátora, endpoint, protokol, vzorky a konkrétní dopad na hru. Opakujte běžnou relaci a srovnejte předchozí měření za podobných podmínek. Mapu zemí či nejlepší naměřený ping nevydávejte za SLA. Podpoře předejte ověřitelné údaje bez tajných informací, aby mohla odlišit místní přístup, směrování a aplikaci. Změny pak provádějte postupně a ověřte skutečné hráče.

Po opravě opakujte stejnou metodu a zkontrolujte normální relaci. Jeden vylepšený vzorek neprokazuje, že všechny cesty jsou pevné. Popište měřené trhy a připojení, aniž byste slibovali latenci pro celou zemi nebo zaměňovali geografickou blízkost s kvalitou směrování.

Co dělat ve vaší situaci

SituaceDalší krok
Web rychlý, hra pomaláOtestujte skutečný herní protokol a současně profilujte server.
Problém u jednoho operátoraPorovnejte nezávislé přístupy, místní podmínky a celou cílovou trasu.
Kolísání po změně ochranySrovnejte stejné cíle, časy a zatížení a výsledek doložte operátorovi.

Oficiální zdroje

Tyto zdroje vysvětlují uvedené protokoly a nastavení. Ověřte dokumentaci pro používanou verzi.

  1. RFC Editor / IETF/rfc/rfc7679
  2. RFC Editor / IETF/rfc/rfc2680
  3. RFC Editor / IETF/rfc/rfc8899
  4. PaperMC/paper/profiling/