Можно ли заставить WordPress поддерживать WebSockets?

Question

Можно ли заставить WordPress поддерживать WebSockets?

19 сент. 2011 г., 21:36:22

Просмотры: 19.5K

Голосов: 23

WebSockets — это современная технология, встроенная в HTML5. По сути, вы можете открыть websocket-соединение для установления постоянного двустороннего обмена данными с веб-сервером. Клиент (пользовательский интерфейс) может спонтанно отправлять сообщения, и сервер также может отправлять сообщения.

Существующие технологии (JavaScript) требуют, чтобы все инициировалось клиентом — сервер не может отправить клиенту ничего, что клиент не запросил. Поэтому скриптам приходится постоянно обновлять и повторно запрашивать данные, которые могли не измениться. WebSockets работают по принципу "push", позволяя новым данным поступать в любое время.

К сожалению, большинство (если не все) реализаций WebSockets требуют наличия специального серверного приложения. Обычно люди запускают Apache на портах 80 и 443 (http и https), а другую систему (чаще всего Node.js) на другом порту (например, 8000 или 8080) для обработки websocket-запросов.

Это работает, но имеет некоторые недостатки.

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

Итак, для тех, у кого есть опыт: как сделать WordPress совместимым с WebSockets? Стоит ли заставить WordPress обрабатывать соединение самостоятельно или включить в плагин дополнительный мини-сервер? Если вы уже делали это, как вы реализовали это без поломки WordPress?

Возможные ресурсы:

Обновление от 21.09.11

Учитывая все разговоры о том, что Apache (наиболее часто используемый сервер для WordPress на shared-хостинге) не поддерживает WebSockets нативно, я задумался об альтернативе. Несколько плагинов (например, JetPack) взаимодействуют с внешними сервисами или API для генерации контента.

Stats запрашивает контент у Automattic. Akismet обменивается данными с внешним сервером. After the Deadline отправляет контент при публикации. Некоторые SEO-инструменты передают данные через внешние системы.

Так что, в качестве альтернативы размещению websocket-кода внутри плагина WordPress, будет ли целесообразно разместить websocket-сервис в централизованном месте и организовать взаимодействие WordPress-интерфейса с ним?

EAMann

32.2K

javascript сервер html5

Комментарии

Суть в следующем: если веб-сокеты плохо работают с нативным веб-сервером, то вы не сможете легко реализовать это на этом сервере. Это не проблема специфичная для WordPress. Как вы отметили, веб-сокеты обычно требуют отдельного сервера, такого как node.js или подобного, они вообще плохо работают с Apache. Так что ваш вопрос не в том "как сделать это совместимым с WordPress", а в том "как заставить это работать на самом базовом хостинге", что уже совсем другая история.

Otto

21 сент. 2011 г. 22:49:05

Поддержку WebSocket можно было бы добавить в ядро WordPress, со встроенным WebSocket-сервером и конечной точкой типа admin-ajax.php, не так ли? Также существует библиотека для фронтенда на JavaScript / бэкенда на Node.js Socket.IO для работы с WebSocket с опцией отката на polling, которая разработана Automattic, компанией, стоящей за WordPress.

baptx

2 нояб. 2017 г. 21:12:46

Все ответы на вопрос

Комментарии

Существует несколько библиотек на чистом PHP, которые заявляют о поддержке WebSocket. Интересно было бы проверить, насколько эффективно они работают внутри Apache. Смотрите ссылки в моем обновлении...

EAMann

20 сент. 2011 г. 01:19:33

Отвечая на ваше обновление, по моему мнению и на основе проведённых мной исследований, это будет самым оптимальным вариантом. Ещё лучше было бы создать фронтенд-плагин и внешний сервис на основе WebSocket для взаимодействия с плагинами, а также взимать плату за его использование, если вы хотите монетизировать свою идею. Вы даже можете предоставить исходный код для WebSocket-сервиса и добавить настройку в плагине для указания, где (какой домен/IP и порт) расположен этот сервис.

user15143

31

13 апр. 2012 г. 08:06:06

Забудьте о "классическом" apache2 - apache2-mpm-prefork - для этой цели. Возможно, apache2-mpm-event справится с этим, но он экспериментальный. Поскольку apache2 не является событийно-ориентированным, проблема, описанная @marfarma, действительно существует. Для такого рода задач вам понадобится событийно-ориентированный веб-сервер, например cherokee или nginx.

nginx может быть действительно полезен для WordPress (так как wordpress.com также использует его в качестве сервера), и он может проксировать определенные запросы, например, к сервису node.js.

Некоторые примеры по теме:

Я также сделал небольшой туториал по настройке nginx + php-fpm + WordPress.

petermolnar

1K

20 сент. 2011 г. 09:04:49

Комментарии

Забыть "классический" подход - не вариант для создания плагина, который будет легко установить обычным пользователям. Да, использование nginx, cherokee или node.js для обработки запросов на сервере - это вариант, но нельзя просто написать это в readme плагина и надеяться, что пользователи а) поймут это или б) смогут что-то с этим сделать.

EAMann

20 сент. 2011 г. 16:55:13

apache2-mpm-prefork не был разработан для обработки такого типа нагрузки. Существуют плагины, требующие memcached, APC и т.д., поэтому здесь может потребоваться событийно-ориентированный веб-сервер. Это требование к серверной части, mpm-prefork и mpm-worker для этого не подходят.

petermolnar

20 сент. 2011 г. 17:10:34

Еще одно возможное решение — использовать стороннего провайдера веб-сокетов. Я немного экспериментировал с Pusher (http://pusher.com/), у них есть API, который может хорошо подойти для ваших задач. Я размышлял, как можно интегрировать его в свои WordPress-сайты.

Недостаток в том, что другим пользователям вашего плагина также придется заводить аккаунт в Pusher для его работы. Однако это гораздо проще, чем устанавливать и поддерживать собственный Web Sockets сервер. На самом деле, это даже преимущество, когда речь идет о других пользователях вашего плагина.

Rick Curran

1.08K

22 сент. 2011 г. 00:46:10

Короткий ответ: да, это возможно. Однако я бы рассмотрел что-то более распределенное, чем единую точку отказа в виде VPS, который вы хостите. Может, стоит взглянуть на балансировку нагрузки в EC2 или что-то подобное? (Предполагаю, что у вас есть доход, позволяющий позволить себе такие удобства. ухмылка)

ZaMoose

1.67K

21 сент. 2011 г. 22:22:01

Комментарии

"поток доходов для обеспечения таких удобств" ... было бы неплохо :-)

EAMann

21 сент. 2011 г. 22:23:11

marfarma 2.61K · Accepted Answer · 2011-09-19T23:27:17Z

WebSockets используют протокол websockets: WS:/example.com/yourscript.js и открывают синхронное соединение — это означает, что соединение остается открытым и выделено для браузера.

HTTP-серверы, такие как apache2 (используемые большинством провайдеров shared-хостинга), используют протокол HTTP: http://example.com/yourscript.js и открывают асинхронное соединение — это означает, что между сервером и браузером не поддерживается постоянное соединение. (Можно немного продлить открытые соединения, установив определенные параметры конфигурации, но в целом соединение остается асинхронным.)

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

Хотя некоторые shared-хосты могут иметь установленный mod_python, что позволяет пользователям вашего плагина запускать pywebsocket, документация pywebsocket явно указывает, что "pywebsocket предназначен для тестирования или экспериментальных целей."

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