Оптимізація мережевих налаштувань та рейтів (Network Tweaking) у Rust
Однією з найбільш дратівливих проблем для гравців на серверах Rust є rubberbanding (ефект «гумової стрічки» або гумові повернення). Це мережевий лаг, при якому гравця після спроби пробігти вперед різко відкидає назад на колишню позицію. Особливо гостро ця проблема проявляється на серверах із високим онлайном (100+ гравців) під час масових рейдів або в моменти, коли серверний процесор завантажений обробкою фізики.
Багато адміністраторів помилково вважають, що в цьому винні виключно потужності хостингу або DDoS-атаки. Насправді у 80% випадків «гумові повернення» відбуваються через те, що мережеві буфери сервера переповнюються, і он починає відкидати вхідні пакети від клієнтів. У цій статті ми розберемо, як правильно налаштувати параметри рейтів, мережевої черги та змінні server.tickrate і server.netrespond для досягнення ідеальної плавності гри.
1. Розбір головного параметра: server.tickrate
Змінна server.tickrate визначає, скільки разів на секунду сервер обробляє мережеві пакети, оновлює позиції гравців, прораховує траєкторії куль та синхронізує стан світу з клієнтами. За замовчуванням у Rust це значення дорівнює 30.
- Міф про високий Tickrate: Деякі адміністратори, прийшовши з CS2 або інших шутерів, намагаються виставити
server.tickrate 60або даже128, думаючи, що це покращить реєстрацію влучань. В умовах Rust це фатальна помилка. Підвищення тикрейту подвоює або потроює навантаження на процесор хостингу. Якщо CPU не справляється, сервер починає пропускати цілі тіки, що призводить до жорстокого rubberbanding. - Оптимальний вибір: Для серверів з онлайном понад 100 осіб стандартом індустрії є
server.tickrate 30. На серверах-гігантах (200-300+ слотів) для стабілізації продуктивності тикрейт безболісно знижують до20або25. Це знижує мережевий тиск на CPU і повністю прибирає повернення, викликані просадками самого сервера.
2. Тонке налаштування мережевої чуйності (server.netrespond)
У мережевому коді Rust є вбудовані механізми, які регулюють частоту та пріоритет відправки мережевих оновлень. Їх правильна конфігурація у файлі server.cfg дозволяє серверу "дихати" вільніше при пікових навантаженнях.
# Обмежує кількість мережевих оновлень, що обробляються за один серверний тік.
# Значення за замовчуванням — 4. Збільшення до 8-10 дозволяє швидше очищати чергу пакетів при високому онлайні.
server.netrespond 8
# Вмикає агресивне склеювання мережевих пакетів перед відправкою, що знижує навантаження на мережеву карту.
fps.limit 60 # Обмеження FPS самого сервера (не плутати з FPS гравців!).
# Вище 60-100 виставлять серверний FPS немає сенсу, це лише створить порожнє навантаження на CPU.3. Боротьба з переповненням мережевих черг (Network Queues)
Коли гравець біжить по карті, його клієнт безперервно шле серверу пакети зі своїми координатами (UserCmd). Якщо сервер зайнятий обробкою складної події (наприклад, падінням вертольота або вибухом стіни), пакети гравця встають у чергу. Якщо черга переповнюється, сервер скидає старі пакети. Коли сервер нарешті "прокидається", він бачить пакет гравця, який прийшов набагато пізніше, вважає його переміщення нелегальним (Antihack) і примусово повертає назад.
Щоб розширити ці буфери та дати гравцям із поганим інтернет-з'єднанням грати без лагів, додайте до свого server.cfg такі параметри налаштування черг:
| Змінна | Стандарт | Рекомендоване значення | Опис ефекту |
|---|---|---|---|
server.maxpacketspersecond |
1500 |
2500 або 3000 |
Максимальна кількість пакетів на секунду, яку сервер прийме від одного клієнта до того, як вважатиме це спамом/атакою і кікне його. Збільшення запобігає хибним кікам під час інтенсивного ПВП. |
server.packetsetback |
true |
false (для тестів) |
Якщо увімкнено, сервер жорстко відкидає гравця назад при будь-яких мережевих затримках. Якщо гумові повернення душать онлайн, вимкнення цього параметра згладить переміщення, но може злегка підвищити навантаження на античит. |
server.ipconnectionspersecond |
20 |
50 |
Збільшує ліміт одночасних мережевих запитів на підключення. Допомагає уникнути лагів «черги на вхід», коли після рестарту на сервер ломляться відразу 100 осіб. |
4. Оптимізація систем авторизації та передачі чанків
Коли новий гравець підключається к серверу, йому необхідно передати величезний масив даних: інформацію про всі будівлі в радіусі його видимості. Цей процес називається Network Encryption та Level Streaming. Неправильні налаштування можуть викликати фризи у всіх інших гравців у момент заходу новачка.
Додайте такі команди для плавної передачі даних:
server.netwritebuffer— збільште розмір буфера відправки пакетів. За замовчуванням він дорівнює 16МБ. На високонавантажених серверах рекомендується підняти його до 32 або 64МБ через параметри запуску, щоб сервер міг плавно і без затримки «виштовхувати» дані карти гравцям.net.visdist 100— радіус мережевої видимості сутностей (в метрах). Зниження цього параметра зі стандартних 150 до 100-120 метрів змусить сервер слати гравцеві інформацію тільки про ті об'єкти, які дійсно знаходяться поруч із ним. Це кардинально знижує мережевий трафік і прибирає лаги навколо величезних кланових баз.
Порада для перевірки мережевого здоров'я: Введіть у консоль сервера команду netstat. Зверніть увагу на показники втрат пакетів (Packet Loss) та розмір черги (Queue Size). Якщо розмір черги стабільно вище 0, це означає, що мережеві параметри вашого сервера затиснуті, і вам необхідно застосувати налаштування з таблиці вище.
Чек-лист для застосування налаштувань
- Зупиніть сервер через панель хостингу.
- Перейдіть у файловый менеджер, відкрийте файл
server/my_server_identity/cfg/server.cfg. - Вставте оптимізовані параметри рейтів.
- Збережіть файл і запустіть сервер. Налаштування наберуть чинності автоматично.