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ěř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.

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.

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.

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í.

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.

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/