В этой части серии статей про разработку сервера для реалтайм игр я расскажу вам о показателе сетевого устройства которое значительно влияет на количество запросов, которое способен обработать ваш игровой сервер.

В статье я расскажу как разработчиков вводят в заблуждение рассказывая что необходимо учесть в первую очередь при разработке серверов (и не только для игр), но умалчивая о реальных "узких местах" (проблемах).

В конце статьи будет приложена видео версия.

Пропускная способность

Когда речь идет про сетевые карты, роутеры и другие устройства для приема и передачи пакетов главным их показателем считается пропускная способность которая часто составляет 100 Мегабит в секунду на домашних устройствах.

Многие ошибочно полагают что зная этот параметр, а так же скорость вашего интернета которая так же выражается в Мегабитах в секунду (Мбит/с) и размер передаваемых пакетов вашему серверу смогут посчитать количество команд (пакетов) игроков в секунду.

Уменьшение размера пакета в первую очередь ?!

Например, многие полагают что при фактической скорости 10 Мб/с интернета и размере пакетов от клиентов 64 байта смогут обработать 1 250 000 таких пакетов в секунду (1 Мбит = 125 000 байт) и в первую очередь стремятся уменьшить размер пакета следующим образом:

• Выбирают UDP протокол с не гарантированной доставкой не по порядку приходящих пакетов за счет меньшего размера заголовков (не думая об обязательных паузах между командами в играх за время которых можно тысячи раз переслать пакеты повторно в случае их потери и мучаясь с нумерацией не по порядку приходящих пакетов)

• Используют на этапе проектирования нечитабельные (кроме самого их автора) байт - флаги в которых кроется какая-то команда (взамен использования текстовых понятных человеку команд, например в том же json)

• Использование сжатие (которое тратит время перед отправкой пакетов и тормозит процесс)

Почему CPU важен при работе с сетью

Уменьшение размера пакетов - необходимая часть разработки, но ни как не на этапе проектирования. Однако очень часто разработчика сервера начинается с этого, а любые лишние действия требуют времени, усложняю проект, увеличивают шанс ошибок и приближают эмоциональное выгорание оттягивая релиз вашего проекта для показа другим людям (если мозг долго не получает положительную обратную связь то начинает полагать что занимается ерундой).

Математический вывод выше о количестве обработанных пакетов не является верным - один процесс (поток) не способен считывать с сетевого стека пакеты с той же скоростью с которых сетевое устройство их принимает.

И вот тут и кроется самое основное, что должен предусмотреть разработчик - возможность работы сервера в нескольких параллельных процессах (потоках), а как я рассказал в другой статье за это отвечает количество ядер процессора CPU и их thread (нитей).

Если сервер работающих в один поток не способен прочитать и 10% принятых пакетов (бывает что и 1%), то уменьшение размера пакетов (которые в играх обычно небольшие) даст лишь небольшой прирост в скорости и это выглядит не первоочередной задачей, а скорее той, которую нужно решать в самую последнюю очередь для оптимизации и уменьшения количества ядер CPU .

Задержка сетевого устройства

Для определения скорости с которой сетевое устройство может передать пакет дальше производители этих устройств публикуют в тестах выполняемых стандартом под названием RFC 2544 в разделе Latency (Frame Latency). Иногда можно встретить упоминание RFC 1242 на котором основаны методы замера.

Ниже представлена выдержка из инструкции тест-анализатора сетевого оборудования, что означает показатель Latency (задержки)

Однако с сетевыми устройствами можно работать в параллельных потоках и т.к. "под капотом" оно работает параллельно (на своих встроенных ядрах и нитях thread) и, как я полагаю, асинхронно - при увеличении нагрузки на него эта скорость может падать.

Приведу примеры таких тестов, где us - микросекунды:

А вот пример теста где уже подсчитано количество пакетов (Frames) в секунду:

Согласно публичным тестам задержка (Latency) для пакетов 64 байта в среднем находится от 7 до 50 микросекунд, т.е. от 135 000 до 20 000 уже полученных устройством пакетов в секунду можно с него считать в рамках одного потока.

Это позволяет сделать вывод, что задержка достаточно серьёзная (если само устройство при скорости 10 Мбит/c способно принять 1 250 000 аналогичных пакетов).

Выводы

Одним из самых первых и важных решений при разработке сервера - это обеспечение его работы в многопоточном режиме, т.е. что бы ваш сервис представлял собой несколько потоков (они могут делить между собой память как в языке C#, использовать каналы Channel как я языке Go или PHP или даже быть разными процессами обмен данных между которых можно наладить например установив TCP соединение между, использовать сокет (фаил) для обмена информации и т.д.).

Этот подход можно заметить и в WEB серверах (apache, nginx) и менеджерах процессов PHP - FPM где нужно вручную указать количество этих параллельных потоков (процессов) - они называются в них workers. Имейте в виду, что помимо обработки пакетов сервером для работы ОС нужно оставлять свободными (в зависимости от того что на ней еще работает, например база данных).

Помимо того что бы сервер работал в многопоточном режиме на физической "машине" (железе) должно быть достаточное количество нитей (thread) у ядер CPU что бы ваши потоки (процессы) находились на разных нитях и действительно работали параллельно (в ОС есть встроенный балансировщик на который как я полагаю можно положиться как минимум на первых порах разработки).

В заключение

Надеюсь статья была для вас полезна. Я не стал углубляться во все аспекты взаимодействия с сетевым оборудованиям и сетевыми ускорителями, однако эта информация поможет людям решившим создать свою онлайн игру с высоким количеством онлайн игроков где нужен свой сервер (в том числе и авторитарный - самостоятельно рассчитывающий игровые механики и физику).

Подписывайтесь на мой профиль если вам интересно данное направление - я веду разработку собственного авторитарного сервера и демонстрационной онлайн игры. Все статьи пишутся мной лично на основе собственного опыта и исследований. Так же я веду видео блог на Youtube

В следующей статье я расскажу как ускорить ваш TCP сервер в 2 раза отключив лишь один стандартный параметр.

Видео версия данной статьи: