Интернет-оптимизация Killing Floor Dedicated Server

Мощное железо и широкий канал сами по себе не гарантируют плавную игру в Killing Floor. Сервер на Unreal Engine может иметь хороший ping в браузере, но игроки все равно будут видеть рывки, скачущий ping, packet loss, “фантомные” попадания и вылеты при смене карт.

Цель гайда - показать KF1-админам, как читать сетевую статистику, где искать узкое место и какие параметры IpDrv.TcpNetDriver действительно имеют смысл.

Коротко: что настраивать первым

Симптом	Что проверить	Где смотреть
Ping скачет у всех игроков	CPU tick time, tickrate, outgoing bandwidth	`stat net`, `inject userflag 1`, мониторинг CPU
Packet loss только у одного игрока	маршрут до сервера и локальную сеть игрока	`tracert`, PingPlotter, `stat net`
Packet loss у многих игроков	канал сервера, redirect, tickrate	серверный мониторинг, `bytes/sec`, `packets/sec`
Попадания “не засчитываются”	ping, packet loss OUT, server authority	`stat net`, клиентский FPS
Долгие подключения	downloads, redirect, `InitialConnectTimeout`	`IpDrv.TcpNetDriver`, HTTP redirect

Начинайте с диагностики. Слепое повышение NetServerMaxTickRate часто делает ощущения лучше для части игроков и хуже для всех остальных.

1. Ping, latency и bandwidth

Для сетевой игры важны две разные вещи:

latency - задержка доставки пакета, обычно воспринимается как ping
bandwidth - сколько данных канал может передать за секунду

Высокая пропускная способность не означает низкий ping. Можно иметь быстрый канал и плохой маршрут до конкретного игрока. Поэтому жалобу “сервер лагает” нужно проверять не только по скорости интернета, но и по маршруту, packet loss и нагрузке сервера.

2. Tracert и маршрут до сервера

Если проблема есть только у части игроков, пусть они проверят маршрут:

tracert server-ip-or-domain

Что искать:

резкий рост задержки на одном hop
packet loss на раннем hop - часто проблема у игрока или провайдера
packet loss на последнем hop - возможно, проблема у сервера или его хостинга
длинный международный маршрут - нормальный ping в соседней стране не гарантирует нормальный ping через океан

Для длительной проверки удобнее PingPlotter или аналогичный инструмент, потому что tracert показывает только моментальный снимок.

3. `stat net`: главная диагностика в игре

На сервере или клиенте откройте консоль и выполните:

stat net

Важные поля:

Поле	Что значит
`Ping`	игровая задержка, не всегда равна ICMP ping
`Channels`	число релевантных actors, которые сервер ведет для клиента
`Unordered/sec`	пакеты, пришедшие не в том порядке
`Packet loss IN`	потери от сервера к клиенту
`Packet loss OUT`	потери от клиента к серверу
`Packets/sec`	сколько пакетов идет в секунду
`Bunches/sec`	обновления actors в секунду
`Bytes/sec`	реальный поток данных
`Netspeed`	лимит скорости подключения клиента

Packet loss должен быть 0. Разовые скачки бывают, но постоянное ненулевое значение означает, что игрок не получает или не отправляет часть игровой информации.

4. Почему F1 ping и `stat net` отличаются

Ping в таблице игроков и ping из stat net считаются по-разному. Клиентский FPS, tickrate сервера и момент отправки пакета влияют на результат, поэтому F1 может показывать красивую цифру, а игра все равно ощущается плохо.

Для диагностики важнее:

packet loss IN/OUT
bytes/sec относительно netspeed
packets/sec относительно tickrate
стабильность FPS клиента

Если клиентский FPS падает ниже входящих packets/sec, игрок может ощущать “невидимую потерю пакетов”: статистика потерь чистая, но обработка пакетов запаздывает.

5. `inject userflag 1`: tickrate и CPU-time

Для расширенной проверки можно включить userflag:

inject userflag 1

Отключение:

inject userflag 0

Эта команда помогает увидеть максимальный tickrate и время последнего server tick. Используйте ее только для анализа: она создает дополнительный трафик и не нужна во время обычной игры.

Главная формула для оценки CPU:

net + act << 1000 / tickrate

Пример: при tickrate 50 один тик занимает 20 ms. Если сумма net + act регулярно близка к 20 ms, сервер не успевает держать такой tickrate.

6. Базовый блок `IpDrv.TcpNetDriver`

Основные параметры лежат в KillingFloor.ini:

[IpDrv.TcpNetDriver]
AllowDownloads=True
ConnectionTimeout=15.0
InitialConnectTimeout=150.0
AckTimeout=1.0
KeepAliveTime=0.2
MaxInternetClientRate=10000
MaxClientRate=20000
SimLatency=0
RelevantTimeout=5.0
SpawnPrioritySeconds=1.0
ServerTravelPause=4.0
NetServerMaxTickRate=30
LanServerMaxTickRate=35
DownloadManagers=IpDrv.HTTPDownload
DownloadManagers=Engine.ChannelDownload

7. Что здесь действительно менять

Параметр	Практика
`MaxInternetClientRate`	Обычно `10000-15000`; выше только если клиенты и канал стабильно тянут
`MaxClientRate`	LAN-лимит, можно держать `20000`
`NetServerMaxTickRate`	Главный параметр плавности и нагрузки
`LanServerMaxTickRate`	Для LAN или закрытых низкопинговых игр
`InitialConnectTimeout`	Уменьшайте только при конкретных проблемах с “зависшими” подключениями
`RelevantTimeout`	Обычно оставить `5.0`
`SpawnPrioritySeconds`	Обычно оставить `1.0`
`ServerTravelPause`	Обычно оставить `4.0`

MaxInternetClientRate ограничивает поток от сервера к клиенту. Он не исправляет плохой маршрут от клиента к серверу и не лечит packet loss OUT.

8. Tickrate: стартовые значения

Tickrate - это server FPS. Чем выше tickrate, тем чаще сервер принимает и отправляет обновления. Это может улучшить отзывчивость, но увеличивает CPU и сетевую нагрузку.

Тип сервера	Стартовый tickrate	Комментарий
6 игроков, обычный KF	`30`	Хороший базовый вариант
12 игроков	`40`	Проверяйте `bytes/sec` и packet loss
12 игроков, хорошие клиенты	`45-50`	Только если у игроков нет потерь
20 игроков	`50-55`	Нужны хороший CPU, канал и тесты
Международный сервер	`30-40`	Маршруты важнее теоретической скорости

Для heavily-modded серверов, большого числа zeds или mutators начинайте ниже. Больше actors означает больше Channels и Bunches/sec, а значит больше данных для клиентов.

9. Как понять, что tickrate завышен

Tickrate слишком высок, если:

Packet loss IN появляется у нескольких игроков одновременно
Bytes/sec регулярно упирается в Netspeed
ping растет во время поздних волн
CPU tick time приближается к бюджету тика
игроки с нормальным маршрутом начинают жаловаться на рывки

В таком случае снижайте NetServerMaxTickRate на 5 и повторяйте тест.

10. Windows и Linux серверы

Старые Linux-серверы Unreal/UT могли отправлять пакеты не так стабильно относительно NetServerMaxTickRate, даже когда CPU не был полностью занят.

Практический вывод:

не судите о сервере только по установленному NetServerMaxTickRate
смотрите фактические packets/sec
тестируйте поздние волны, а не пустой сервер
если Linux-инстанс ведет себя странно, сравните с Windows-инстансом на тех же настройках

На современных хостингах поведение может отличаться, но принцип диагностики остается тем же.

11. Downloads и HTTP redirect

AllowDownloads=True нужно для кастомного контента, но не стоит раздавать большие карты с игрового процесса. Когда игрок скачивает карту прямо с сервера, он конкурирует за канал с активными игроками.

Используйте HTTP redirect:

[IpDrv.HTTPDownload]
RedirectToURL=https://example.com/kf-redirect/
UseCompression=True

Если после включения redirect появились ошибки версий, проверьте, что файлы на redirect полностью совпадают с файлами сервера.

12. Клиентские настройки тоже важны

Даже идеальный сервер не исправит плохой клиентский netspeed, слабый FPS или фоновые программы.

Игрокам стоит проверить:

фоновые загрузки, VPN, оверлеи, запись видео
firewall и antivirus inspection
драйвер сетевой карты или Wi-Fi
реальный маршрут до сервера
стабильный FPS выше входящих packets/sec

Для старого DSL/ISDN-класса соединений слишком высокий клиентский netspeed может создавать больше трафика, чем линия стабильно держит. Для современных соединений обычно достаточно серверных лимитов 10000-15000.