Можно ли настроить запросы к php через вебсокет и http одновременно?

Question

[Shurik]

Приветствую. Заранее прошу прощения за возможно корявые вопросы, т.к. с технологией вебсокетов знаком лишь поверхностно. Гугл особо ничего не дал.
Итак, имеем php-fpm, nginx на сервере. В веб приложении на одной из страниц, на мой взгляд, напрашивается взаимодействие клиента и сервера через ws. Собственно созрело пару вопросов на эту тему:
1. Php вообще подходит для этого или на нем будет это в виде костылей?
2. Eсли 1п. да, можно ли одновременно настроить серверную часть на http и ws? Если да, то какие рекомендации и ньюансы могут быть по настройке.
3. Вебсокет и unix сокет - это не связанные вещи? (на всякий случай спрашиваю, понимаю, что скорее всего разные). Не обязательна ли конфигурация через unix сокет для настройки ws или тут устроит tcp взаимодействие nginx и php-fpm?

Answer 1

[Ипатьев]

Разумеется можно. Никаких нюансов в одновременной работе нет, поскольку тут нет никакой "одновременности". php-fpm и websocket - это два разных сервиса, которые могут располагаться на одном и том же сервере или на разных, но в любом случае никак не пересекаются. В добавление к текущему веб-серверу вы просто запускаете вебсокет сервер и посылаете на него вебсокет запросы из браузера.

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

1. Да.
2. Как говорилось выше - можно. Любой сервер в сети по определению обеспечивает работу множества сервисов, количество которых ограничено только количеством свободных портов. Можно поставить два веб-сервера и пять вебсокет серверов.
3. Нет, разумеется. unix сокет это как раз внутренняя кухня сервера, но мы же говорим о сетевом взаимодействии. А tcp взаимодействие nginx и php-fpm тут вообще не при чём.

Comments

[Shurik]

Спс! Т.е. проецируя на меня: у меня сейчас приложение на Symfony и в nginx блок server для него, пусть на 80 порт. Тогда мне надо в nginx создать еще один блок server на другой порт (и использовать это же приложение или другое. Или и так и так можно?) ? Или в одном блоке server как-то комбинируются настройки для php-fpm и websocket?

[Виктор Кожухарь]

Shurik, Тогда вам желательно использовать именно Ratchet. Можете либо напрямую его имплементить у себя, либо нагуглить уже готовый бандл, который вам подойдёт.

[Ипатьев]

Shurik, я ж вроде несколько раз повторил - ни nginx, ни php-fpm не имеют к вебсокету никакого отношения :)
Их надо оставить в покое и вообще не трогать.

Независимо от них поставить вебсокет сервер и работать с ним напрямую с клиента.

В теории, можно конечно настроить прокси в nginx на определённый локейшен, чтобы обращение шло по 443 порту, которое потом тупо проксируется на вебсокет сервер, но мне это кажется лишним. По крайней мере для теста точно не нужно добавлять лишнюю точку отказа. Потом, когда всё заработает, можно будет добавить такое проксирование, чтобы не настраивать SSL отдельно для вебсокета. Хотя это не такая уж и сложность.

[Shurik]

Ипатьев, я тут упоминал о том, что пробовал запустить сервер на симфони. В коносли отобразилось сообщение, что сервер запущен на порту 8080. Т.е. хотите сказать, что теперь к нему можно обращаться напрямую по ip:port? Хотя мне не совсем понятно как это будет выглядеть в приложении. Например можно ли сделать так, чтобы когда я зашел на страницу приложения, в контроллере основного приложения запускался вебсокет? Или надо же постоянно запущенный сервер websocket?)
Сори, что туплю)))

[Ипатьев]

Shurik, да, надо постоянно запущенный сервер вебсокет. Это отдельный сервис, как постгрес или nginx. То есть он по определению не "запускается" по какому-то событию, а работает постоянно.

И кстати, поэтому его лучше запускать через supervisor.

А что непонятно про обращение из приложения? JS нативно работает с вебсокетом - соединяемся, отправляем, получаем. К РНР это уже не имеет никакого отношения.

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

[Shurik]

Ипатьев, теперь понял, что это именно сервис на уровне ОС, а не библиотеки php внутри приложения. Спасибо)

Answer 2

[Виктор Кожухарь]

3. Вебсокет и unix сокет - это совершенно разные вещи. Websockets - это протокол обмена информацией по TCP/IP.
Как работают websockets:
- Клиент начинает с простого HTTP запроса с просьбой апгрейднуться до websockets.
- Сервер соглашается, и тогда между Клиентом и Сервером устанавливается постоянное TCP/IP соединение, по которому данные могут ходить туда-обратно по протоколу websockets уже без кучи церемониальных ритуалов, как принято в обычном HTTP.

1. Изначально PHP совершенно не подходил для постоянного соединения, потому что он создавался как скриптовый язык. Скрипт должен был отработать один раз и почистить все следы своего выполнения. Поэтому создатели особо не заботились об утечках памяти и т.д. В результате было очень обременительно создавать постоянно-живущие процессы, необходимые для websockets. Но в настоящее время PHP очень сильно развивается, разработчики уделяют очень много внимания такому сценарию использования языка. PHP стал производительнее и гораздо надёжнее работает с памятью. Однако, напрямую реализовывать долгоживущий сервис самому всё еще муторно, поэтому лучше всего использовать отличные сторонние фреймворки/библиотеки.

2. Что можно использовать:
- Ratchet
- Swoole / OpenSwoole
- Workerman

У каждой из этих асинхронных библиотек/фреймворков есть свои особенности и нюансы. Но это всё очень хорошо описано в их документации, так что просто следуйте тому, что там написано, и не волнуйтесь. Советовать что-то одно не буду, потому что на вкус и цвет все фломастеры разные, и выберете то, что будет отвечать вашим конкретным задачам.

Comments

[Shurik]

Спасибо за разъяснение принципов работы websocket и рекомендации по библиотекам. Кстати пробовал до того как задать этот вопрос тут в своем приложении (оно на Symfony) использовать библиотеку snoke /
symfony-websocket. Сервер запустился, но на тесте соединения вываливается ошибка. Не можете ничего сказать про него? И ваши предложенные варианты заведутся ли с Symfony? Боюсь дело в неправильных настройках nginx (я к комментарию выше задал вопрос про настройки) или в моем случае все еще осложняется докер контейнерами.

Кстати про unix сокеты - пользуясь случаем задам вам Вопрос) Если у меня все это дело крутиться в докер контейнерах, то сокетах настройка php тут не уместна? Т.к., насколько я понял, это используется когда на одной машине веб сервер и php, а в случае докера получается nginx и php-fpm на разных контейнерах, что сравнимо на разных машинах и тут уже нужно tcp подключение к php? Поправьте пожалуйста если не так)
И если не так, стоит ли переделывать на сокеты с tcp? Намного ли выигрыш в производительности или еще в чем может. Просто не особо разобрался как подключаться через сокеты именно в ситуации с докером.

[Виктор Кожухарь]

Shurik, Мне интересен один момент. А вам именно вебсокеты нужны? Какую задачу вы решаете.
Потому как если вам нужно только периодически отправлять какие-то сообщения с сервера на фронтенд, то есть гораздо более простое решение.

[Ипатьев]

Виктор Кожухарь, например?

[Shurik]

Виктор Кожухарь, совместно изменяемый список. Т.е. изменил один человек, у другого отобразилось. Раньше у меня было реализовано с запросами из клиента с интервалом сек 10 и это более чем устраивает. Не так важен в моей ситуации этот интервал. Вебсокеты в моем приложении - это лишь повод для ознакомления с технологией!

[Ипатьев]

Shurik, если честно, то в контейнерах я не очень.

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

И мне тоже интересен такой момент. В чем причина вашего повышенного интереса к юникс сокетам? Какую проблему вы решаете? У меня складывается ощущение, что вы её себе выдумали исходя их каких-то туманных теоретических представлений, при том что никакой реальной проблемы использовать tcp сокеты у вас нет. Я прав?

[Shurik]

Ипатьев, выше Виктору ответил про цель сокетов - и да наполовину она надумана) Но хочу разобраться.
Про контейнеры чуть не так. Сейчас разрабатываю локально, поэтому в контейнерах. Их, в моей ситуации 3: nginx, php-fpm и postgres. Все они находятся как бы в своей сети докеровской и по сути имеют разные ip. В nginx настройка для php сейчас такая fastcgi_pass php:9000. Интересно стоит ли пытаться переделывать контейнеры на сокеты unix.
На проде уже все стоит без контейнеров, там все понятно как это делать.

[Виктор Кожухарь]

Shurik, Очень часто люди влезают в вебсокеты, даже не зная о существовании такой прекрасной технологии, как SSE (Server-Sent Events). Это вебсокеты "для бедных". Канал связи однонаправленный, с сервера в браузер. Работает через HTTP

Браузер подписывается на получение событий от SSE-сервера. PHP шлёт на SSE-сервер запрос о том, что событие возникло, и SSE-сервер уже рассылает это событие всем подписанным на него браузерам.

Таким образом: Если один человек изменяет список, то всем подписанным на это событие браузерам сообщается, что список изменился, и они могут получить новые данные обычным HTTP-запросом. Либо можно даже новые данные передавать в этом же событии.

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

Вот описание процесса для Symfony. Нужно будет дополнительно установить Mercure Hub. Это сервис, написанный на Go, который как раз занимается реализацией схемы publish/subscribe для SSE
https://symfony.com/doc/current/mercure.html

У себя в PHP приложении вы будете отправлять сообщения через банальшейший Symfony messenger, а Mercure Hub автоматом разошлёт его всем клиентам

[Shurik]

Виктор Кожухарь, спасибо за наводку. Обязательно займусь изучением этой возможности! Возможно и правда меня это более чем устроит)

[Ипатьев]

Виктор Кожухарь, спасибо, вот мне как раз очень подойдёт!

[Виктор Кожухарь]

Shurik, Не надо вам лезть в unix сокеты.
У вас несколько контейнеров на одном сервере. У каждого контейнера открыты свои специфические порты.

Nginx у вас должен работать в качестве reverse-proxy для ваших внутренних контейнеров с разными частями приложения.

Поэтому Nginx желательно вынести в отдельный контейнер. PHP-FPM - еще один контейнер. А вебсокеты - третий контейнер, которому в докере нужно будет назначить автоматический рестарт.

reverse-proxy в контейнере Nginx будет заниматься пробросом данных в тот или иной контейнер с теми или иными параметрами соединения в зависимости от урла.

Рекомендую все три конейнера объединить в docker-compose, который создаёт между контейнерами внутреннюю сеть, и тогда вам даже порты открывать не придётся, а слать запросы на хостнеймы, описанные в docker-compose.yaml

[Виктор Кожухарь]

Shurik, Вот я попросил у ИИ накидать как объединить всё что вам нужно в докере. Не проверял ничего, глянул по-быстрому, вроде всё там норм. Но идея вам должна быть понятна.

https://vitiok78.notion.site/symfony-mercure-21155...

[Shurik]

Виктор Кожухарь, спасибо огромное)

[Shurik]

Виктор Кожухарь, у меня так и было сделано через docker-compose все в своем контейнере. Единственное вы подсказали еще про вебсокеты на отдельном, а то я его хотел на томже, что и php-fpm как то крутить. Понял теперь ошибку)

[Виктор Кожухарь]

Shurik, Погуглите, как правильно настраивать nginx location под вебсокеты. Там есть ряд особенностей, на которые стоит обратить внимание. В таком конкретном вопросе вам Гугл поможет больше меня

[Shurik]

Виктор Кожухарь, ок! Спасибо)

[rPman]

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

[Виктор Кожухарь]

rPman, Вебсокеты сложнее вообще для всех. И для клиента и для сервера. А зачем? Просто чтобы получить сигнал о том, что данные изменились? Их надо выбирать, если вы пишете чат в реальном времени для кучи народу, игру или аналог Google Docs. Для большинства остальных случаев это чудовищный оверкилл.

SSE работает тупо на HTTP. EventSource API поддерживается напрямую браузером со всеми ретраями, реконнектами и стандартными сообщениями об ошибках. Нужен просто Javascript и ничего более.

[rPman]

Виктор Кожухарь , websocket отличается от sse исключительно заголовками, и то и другое это http.

Особенно хорошо видно все, если смотреть чистые реализации без библиотек, на сокетах. sse выглядит проще, но это два разных места, где ты работаешь на прием и на передачу данных (и это будут буквально два соединения и да я знаю что в http2/3 в принципе соединения объединяются в одно), в websocket это одно и то же место, одно и то же открытое соединение.

На клиенте, в браузере, у sse и websocket уже давно нативная поддержка, и разницы для разработчика особой нет

[Виктор Кожухарь]

rPman, websockets - это не http. Это совершенно другой протокол. Соединение только инициируется через http с заголовком Upgrade: websocket. И далее общение по http заменяется общением по websocket по тому же самому TCP/IP соединению.

А в SSE используется тот же http.

И хоть поддержка в браузере есть и у того и у другого, но обрабатывать SSE на клиенте всё равно значительно проще. В SSE можно подписываться на конкретные события. А у вебсокетов один общий хэндлер. Реконнект у SSE автоматический, а не ручной, как у websockets.

Answer 3

[rPman]

Да, подходит.

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

Для этого приложение на php нужно реализовывать в виде http сервера (готовых библиотек тьма, включая штатные расширения), рекомендуется использовать swoole ну или по старинке на сокетах (библиотеки phpreact)

Comments

[Shurik]

Спс за рекомендации. По поводу стандартных расширений - это некий класс или функция который можно уже использовать или надо какое-то расширение устанавливать?

[rPman]

swoole это pecl расширение, оно собирается автоматически во время установки командой
pecl install swoole
вот тесты (6-летней давности)

[Shurik]

rPman, спасибо!

[Vitsliputsli]

rPman,

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

Websocket это отдельный независимый от http протокол. Это не расширение http запроса.