События, связанные с сервером и опросом

Ответ 1

Опрос Ajax добавляет много накладных расходов HTTP, поскольку он постоянно устанавливает и разрушает HTTP-соединения. Поскольку HTML5 Rocks ставит его "Server-Sent Events, с другой стороны, были разработаны с нуля, чтобы быть эффективными."

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

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

События, отправленные сервером, довольно хорошо поддерживаемые в большинстве браузеров, примечательным исключением, конечно, являющимся IE. Но есть пара polyfills (и a jQuery plugin), который исправит это.

Если вы делаете то, что требует только односторонней связи, я бы определенно пошел с событиями, отправленными сервером. Как вы упомянули, события, отправленные сервером, как правило, проще и чище реализовать на стороне клиента. Вам просто нужно настроить слушателей на сообщения и события, и браузер позаботится о низкоуровневых вещах, таких как повторное подключение, если отключено, и т.д. На стороне сервера его также довольно легко реализовать, поскольку он просто использует простой текст. Если вы отправляете объекты, закодированные JSON, вы можете легко превратить их в объекты JavaScript на клиенте с помощью JSON.parse().

Если вы используете PHP на сервере, вы можете использовать json_encode(), чтобы превращать строки, числа, массивы и объекты в правильно закодированный JSON. Другие базовые языки могут также предоставлять аналогичные функции.

Ответ 2

Я бы добавил только более высокую оценку того, что было сказано, и это то, что SSE является моделью публикации-подписки, а не постоянным опросом в случае AJAX.

Как правило, оба способа (опрос и публикация-подписка) пытаются решить проблему, как поддерживать на клиенте современное состояние.

1) Модель опроса

Это просто. Сначала клиент (браузер) получает начальное состояние (страница) и для его обновления, он должен периодически запрашивать состояние (страницу или его часть) и обрабатывать результат в текущем состоянии (обновлять целую страницу или делать ее интеллектуально часть в случае AJAX).

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

Другим примером опроса является спинвейт в потоковом режиме.

2) Опубликовать-подписать модель

Он работает следующим образом:

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

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