Перейти до контенту
Захист DDoS · Peeryx · 15 Tbps+
Усі посібники

Вимірюйте затримку та втрати пакетів через DDoS-захист

Одного ping недостатньо для оцінки захищеної ігрової мережі. Досвід залежить від маршрутів, втрат, коливань затримки й навантаження сервера. Корисне порівняння використовує ту саму ціль і протокол до зміни та після неї, а також показує метод і межі результатів.

← Усі посібникиCubixServ

Перед початком

Оберіть справжні операторські мережі гравців, правильну ігрову адресу та порт. Запишіть час, протокол, навантаження й конфігурацію. Користуйтеся малими дозволеними тестами та збережіть первинні дані для подальшої перевірки результатів.

RTT вимірює шлях туди й назад

RTT охоплює рух до цілі та повернення. Ділення навпіл не обов’язково дає точну затримку одного напрямку, бо маршрути можуть відрізнятися. Однобічне вимірювання потребує відповідного методу й синхронізованих годинників. Описуйте те, що справді виміряно, а не показуйте точність, яку вибраний тест не здатний надійно обґрунтувати.

Порівняйте кілька зразків замість найкращого результату. Зберігайте мінімальне, центральне значення та високі значення поряд із кількістю вибірки. Варіації та переривання можуть мати більше значення, ніж невелика середня різниця. Відокремте затримку мережі від часу гри для симуляції та відповіді.

Обирайте точки за мережами гравців

Назва країни не показує справжнього маршруту оператора до Франції. Використовуйте кілька потрібних мереж і повторюйте в різний час. Включайте мобільний зв’язок, якщо ним користуються гравці. Швидкий результат у власній мережі не гарантує досвіду всіх операторів або клієнтів країни; зберігайте мережу, час та метод поруч із результатом.

Поєднайте вимірювання зі звичайним службовим підключенням. Зберігайте мережеву статистику гри та контекст, якщо доступний. Проміжне обладнання може обмежувати діагностичні відповіді під час пересилання трафіку; сам по собі тихий стрибок трасування не доводить, що втрата досягла гравця.

Порівнюйте однакові умови

В обох тестах зберігайте адресу, протокол, розмір пакетів і тривалість. Запишіть навантаження сервера та час. Медіана й розкид корисніші за найкращий окремий зразок. Завантажений клієнт, збій Wi-Fi або тимчасовий обхід не є автоматично наслідком захисту; повторіть контрольований тест до наступної зміни мережі й порівняйте всі зразки.

Зберігати необроблені результати та помилки замість вибору сприятливих значень. Включіть кількість спроб і період спостереження. Коротка базова лінія показує поведінку в той час; це не постійна затримка або гарантія доступності.

Покажіть втрати й піки

Низьке середнє може приховувати втрати та значні окремі піки. Покажіть кількість зразків, медіану, високі перцентилі й частку втрат. Досліджуйте відхилення, не видаляючи їх задля кращої статистики. Порівнюйте події з CPU, мережевими чергами й локальним з’єднанням клієнта, щоб розрізнити можливі причини ривків у грі та обрати наступну перевірку.

Для тунелів також перевірте MTU та симптоми, пов’язані з розміром пакета. Для проксі-серверів перевірте тайм-аути та вихідні з’єднання. Не міняйте кілька компонентів одночасно. Підтвердьте законний трафік перед видаленням правила, яке сприяє захисту.

Тестуйте справжній ігровий шлях

ICMP чи TCP 443 не підтверджує UDP гри. Використовуйте правильний клієнт, призначений порт і дозволені тести протоколу. Обережно тлумачте traceroute: проміжний маршрутизатор може обмежувати службові відповіді, коли звичайний трафік іде правильно. Мовчазна проміжна точка сама не доводить втрат ігрових пакетів; перевірте кінцеву ціль та справжнє підключення.

Якщо існує сумісний інструмент, створіть профіль під час сповільнення. Звіти Paper spark можуть визначити дорогу роботу. Зв’яжіть вимірювання та скопіюйте конфігурацію перед внесенням змін. Купуйте більше ресурсів лише тоді, коли це виправдовує наявне обмеження.

Публікуйте з чіткими межами

Якщо вимірювання використовується в пропозиції, зазначте дату, ціль, мережу джерела, протокол і кількість зразків. Відокремте нормальну роботу від документованого тесту під атакою. Повторюйте після зміни маршруту та досліджуйте тривалі відхилення з оператором. Синтетичний тест описує свої умови, а не майбутнє з’єднання кожного гравця чи гарантований ping.

Після виправлення повторіть той самий метод і перевірте звичайний сеанс. Один покращений зразок не встановлює, що всі шляхи фіксовані. Опишіть виміряні ринки та з’єднання, не обіцяючи затримки для всієї країни або плутаючи географічну близькість із якістю маршрутизації.

Що робити у вашій ситуації?

СитуаціяНаступний крок
Медіана зросла після зміниПовторіть той самий тест і перевірте маршрут перед наступним коригуванням.
Гра смикається за доброго середньогоДослідіть втрати, піки та навантаження за той самий час.
Результати однієї країни сильно різнятьсяПоділіть за оператором і перевірте маршрути з відхиленнями.

Офіційні джерела

Джерела описують протоколи й налаштування. Перевірте документацію саме вашої версії.

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