В 3й части статей я расскажу простым языком про протоколы передачи данных, как они работают и что такое Websocket сервер и какие есть решения для его создания на PHP

Что такое Websocket сервер

В предыдущей части я рассказал с какими проблемами предстоит столкнутся разработчику при проектировании игрового сервера и пути их решения. Мы определились , что для обработки входящих соединений потребуется некое CLI приложение (демон) - Websocket сервер, которое будет обслуживать входящие запросы от пользователей. Хорошей библиотекой для этого является workerman .

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

PS Никто не ограничивает самому написать свой протокол на базе TCP используя библиотеку по ссылке выше

Его плюсы в том что TCP - так называемый протокол гарантированной доставки пакетов (его можно сравнить с системами очередей который при получении пакета должны отправить назад подтверждение о получении) , а наличие постоянного соединения не требует времени на установку каждый раз нового (как HTTP протокол - правда у него есть Connection: Keep-Alive для поддержания соединения, который правда все равно закроется спустя пару секунд бездействия, но для пошаговых игр подойдет и он) с отправкой дополнительных пакетов а так же пакеты доставляются в той последовательности в которой были отправлены пользователю плюс мы можем без действий со стороны пользователя слать ему новые данные с разной периодичностью.

Из минусов можно выделить : на проверку доставки данных (запрос - ответ) требуется дополнительное время, пакеты идут друг за другом, а не параллельно, так же помимо данных шлются некие системные заголовки (накладные расходы)

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

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

Есть ряд статей , которые рассматривают теоретическую часть пропускной способности TCP на одном порту стремящуюся к миллиардам пользователей, но рассмотрим тесты на базе фреймворка (доступна установка через composer ) workerman :

По результатам тестов мы можем видеть что workerman стоит на следующих позициях:

• 1 место (с использованием php 8 и Jit пре компиляции php скриптов в некие "бинарники")

• 2 место - его модификация с заменой Apache и Nginx на HTTP сервер написанный на PHP слушающий порт сервера (те работает и определяется PHP как CLI , без запуска fpm workers). Документация на Китайском , но механика следующая : Singleton'ы (грубо говоря закешированные экземпляры классов) всех контроллеров, вызывающиеся в onMessage() (метод срабатывающий когда на порт сервера приходят данные посланные клиентом из браузера) с параметрами которые пришли в запросе и увеличенный параметр keep-alive (те между браузером и сервером устанавливается постоянное TCP соединение которое дольше остается открытым чем в том же Apache где этот параметр ~10 секунд) - нам не очень актуален этот фреймворк тк мы не будем использовать HTTP

• 3 и 8 место держат вариации с использование PostgreSql и без модификаций

В среднем ~ 350 000 запросов в секунду . Хотя рейтинг и для HTTP протокола, но включенный keep-alive заставляет сервер работать на подобии websocket удерживая соединения).

Остается вопрос: хороший ли это показатель и какое число пользователей можно держать онлайн ?

Ответ на этот и другие вопросы я опишу в следующей части статей про разработку сервера для онлайн игр на php

Буду признателен за лайки - так я могу видеть интересна ли вам данная тематика и стоит ли ее продолжать (тк в русскоязычном пространстве достаточно мало информации про то как создавать сервера для игр, о чем я писал в первой части серии статей).

Подписывайтесь на мой профиль что бы не пропустить новые стать