rPman

Это не вебсокет вносит задержки, а телеграм. Задержки в рассылке сообщений клиентам у него доходят до нескольких минут, это не исправить, клиенты должны сами подключаться к тому же серверу что и бот, управлять этим невозможно.

Использовать базу данных как источник событий - плохая идея, т.е. это возможно, разные базы данных предлагают для этого разные инструменты, типа sqlite notifications, postgres notify, у mysql точно видел как мониторили изменения читая binary logs напрямую, в любом случае это извращения.

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

Совершенно не понимаю, зачем эти порты пробрасывать, возможно это специфика битрикс.

Websocket - это расширение http протокола, т.е. буквально это постоянно висящее http соединение от браузера до клиента, в котором можно слать данные в обе стороны.

С точки зрения nginx прокси, это обычный http запрос, настройки там минимальны

Но у тебя внутри твоей сети должен быть поднять этот websocket сервер. Т.е. какое то приложение, которое и является этим сервером, умеющим обрабатывать не http rest а именно непрерывное подключение.
-----------------------------------------------
Либо модуль веб сервера!

Я не совсем уверен, в документации есть только пара строчек об этом

Включает использование Веб-сокетов. Активна только при использовании nginx-push-stream-module в версии 0.4.0

Используется этот модуль https://github.com/wandenberg/nginx-push-stream-module
Читай инструкции как его настраивать

т.е. веб сервер становится посредником, где уже бакэнд сможет слать к нему запросы в http rest стиле и управлять открытыми websocket каналами (и читать к примеру старые сообщения, этот момент меня огорчил, так как не нашел как бакэнд будет получать сообщения о новых данных в канале ws)

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

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

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

не существует адекватной гарантирующей защиты, позволяющей скрыть от пользователя эту информацию.

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

Еще способы решения, выполнять критичную логику на сервере, а клиент пусть будет просто отображением, вырожденный случай - на сервере запускается приложение а на клиент транслируется ее изображение, само собой на практике на столько сильно переносить код на сервер не обязательно.

Если сервер написан с использованием swoole, то почему бы и клиента на нем не писать?
https://www.swoole.co.uk/docs/modules/swoole-async...

поставить между сервером и вами прослойку, которая будет фильтровать поток данных, либо смотреть. умеет ли сервер как это лимитировать

Не закладывай такую бомбу на старте, потом переделывать сложнее чем правильно сделать сейчас.

Server site event или вебсокеты, по мне так это одно и то же но вебсокеты более универсальны (т.е. свой вебсокет сервер удобно использовать и бакэнду для inter-process communication)

Данные сообщения сериализуй в строку чем то вроде json, просто, универсально, удобно, с помощью JSON.stringify а декодировать JSON.parse.

Если сообщение сложное и содержит много данных разного типа, на стлько что json вырастает в несколько раз, то можно воспользоваться бинарными сериализаторами, популярный и красиво реализованный - google protobuf (тут обсуждали как раз) или просто сжать канал

Ответь пожалуйста, зачем тебе такие крутые фреймворки для чата?

Обычный websocket, чистый, не замутненный кодомусором, на php сервер бери Ratchet но само собой можешь выбрать любой другой, на github вариантов тьма.

попробуйте подменить метод на свой, что то типа такого:
https://stackoverflow.com/questions/40341197/how-t...

WebSocket.prototype.oldSend = WebSocket.prototype.send;

WebSocket.prototype.send = function(data) {
     console.log("ws: sending data");
     WebSocket.prototype.oldSend.apply(this, [data]);
};

Если вам нужна скорость, то уходите от постоянного переподключения к сервисам.

Конечно, современные веб-сервера и браузер умеют переиспользовать подключение для http rest, но это стоит перепроверить в вашем случае. Если идут постоянные переподключения то высокие пинги могут превратить работу вашего сервиса в лагучую дрянь (один https добавит пару туда-сюда отправлений).

websocket изначально по определению однократно открывает подключение а затем использование открытого канала возможно в обе стороны (с http rest только в одну и с оговорками в сторону клиента, читай не эффективно).

А еще вопрос, как у вас организован код обработки http rest. Если это старый классический подход, когда на каждый запрос запускается php скрипт это это еще и высоченная нагрузка на сервер, переделывайте (а точнее убирайте эту фигню и оставьте websocket), так как разница подходов дает ускорение на пару тройку порядков (это не шутка и не преувеличение).

у http rest только одно достоинство - почти бесплатная горизонтальная масштабируемость на сервере.

Сравнивать websocket и pusher этот как сравнивать notepad и пакет microsoft office с презентациями, базами данных, управлением проектов и прочее прочее (я утрирую, сам с pusher не работал).

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

Хостинга именно php websocket вы не найдете, такого SasS скорее всего нет
но из дешевых решений, вам достаточно не обслуживаемого linux vps за 1$ в месяц или даже дешевле

гуглить low cost vps, например lowendstock.com

запустить свой php websocket сервер из командной строки screen особых знаний linux не понадобится, а для тестов сойдет.