Веб-сокетов и сервер-отправлено событий/тип EventSource

и WebSockets и Сервер-Отправлено Событий способны передавать данные в браузерах. Мне они кажутся конкурирующими технологиями. В чем разница между ними? Когда ты предпочтешь одно другому?

632
html5 server-sent-events websocket

8 ответов

Websockets и SSE (Server Sent Events) способны передавать данные в браузеры, однако они не являются конкурирующими технологиями.

соединения Websockets могут как отправлять данные в браузер, так и получать данные из браузера. Хорошим примером приложения, которое может использовать websockets, является приложение чата.

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

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

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

кроме того, SSE может быть заполнен в старые браузеры, которые не поддерживают его изначально используя только JavaScript. Некоторые реализации SSE polyfills можно найти на Modernizr странице GitHub.

Gotchas:

  • SSE страдает от ограничения максимального количества открытых соединений, что может быть особенно болезненным при открытии различных вкладок, так как предел в браузере и установите очень низкое число (6). Проблема была отмечена как "не будет исправлена" в хром и в Firefox
  • только WS может передавать как двоичные данные, так и UTF-8, SSE ограничен UTF-8. (Спасибо чадо НИХИ).

HTML5Rocks имеет некоторую хорошую информацию о SSE. С этой страницы:

сервер-отправленные события против WebSockets

Почему вы выбираете серверные события через WebSockets? Лучший вопрос.

одна из причин, по которой SSEs были сохранены в тени, заключается в том, что более поздние API как WebSockets обеспечивают более богатый протокол для выполнения двунаправленной, полнодуплексной связи. Наличие двустороннего канала более привлекательно для таких вещей, как игры, приложения для обмена сообщениями и для случаев, когда вам нужны обновления в реальном времени в обоих направлениях. Однако в некоторых сценариях данные не нужно отправлять от клиента. Вам просто нужны обновления от некоторых действий сервера. Несколькими примерами могут быть обновления статуса друзей, биржевые тикеры, ленты новостей или другие автоматизированные механизмы передачи данных (например, обновление клиентской базы данных Web SQL или хранилища объектов IndexedDB). Если вам нужно отправить данные на сервер, XMLHttpRequest всегда будет другом.

SSEs отправляются по традиционному HTTP. Это означает, что они не требуют специального протокола или сервера, чтобы получить работу. WebSockets, с другой стороны, требуют полнодуплексных соединений и новых серверов веб-сокетов для обработки протокола. Кроме того, события, отправленные сервером, имеют множество функций, которых не хватает WebSockets по дизайну например, автоматическое переподключение, идентификаторы событий и возможность отправки произвольных событий.

резюме TLDR:

преимущества SSE над Websockets:

  • транспортируется по простому HTTP вместо пользовательского протокола
  • может быть Поли-заполнен javascript для "backport" SSE для браузеров, которые его еще не поддерживают.
  • встроенная поддержка повторного подключения и event-id
  • проще протокол

преимущества Websockets над SSE:

  • Реальное время, двухнаправленная связь.
  • родная поддержка в других браузерах

идеальные случаи использования SSE:

  • тикер потокового
  • обновление ленты twitter
  • уведомления в браузер

SSE gotchas:

  • нет поддержки бинарных
  • максимальное ограничение открытых соединений
730

по данным caniuse.com:

вы можете использовать polyfill только для клиента, чтобы расширить поддержку SSE для многих других браузеров. Это менее вероятно, с WebSockets. Некоторые поля EventSource:

Если вам нужно поддерживать все браузеры, рассмотрите возможность использования библиотеки, такой как web-socket-js, помощью SignalR или гнездо.Ио которые поддерживают множественные переходы как WebSockets, SSE, навсегда рамка и AJAX длиной голосование. Они также часто требуют изменений на стороне сервера.

Узнайте больше о SSE от:

Узнайте больше о WebSockets от:

другие отличия:

  • WebSockets поддерживает произвольные двоичные данные, SSE использует только UTF-8
89

Opera, Chrome, Safari поддерживает SSE, Chrome, Safari поддерживает SSE внутри SharedWorker Firefox поддерживает XMLHttpRequest readyState interactive, поэтому мы можем сделать EventSource polyfil для Firefox

14

Websocket VS SSE

Web Сокеты - это протокол, который обеспечивает полнодуплексный канал связи через одно TCP-соединение. Например, двусторонняя связь между сервером и браузером Поскольку протокол более сложный, сервер и браузер должны полагаться на библиотеку websocket которая составляет socket.io

Example - Online chat application.

SSE (отправленное сервером событие) - В случае отправленного сервером события общение осуществляется от сервера к браузеру и браузер не может отправить данные на сервер. Этот вид связи главным образом использован когда требуется только показать обновленные данные, сервер отправляет сообщение при каждом обновлении данных. Например, односторонняя связь между сервером и браузером. Этот протокол менее сложен, поэтому не нужно полагаться на внешнюю библиотеку, которую JAVASCRIPT сам предоставляет EventSource интерфейс для получения отправленных сервером сообщения.

Example - Online stock quotes or cricket score website.
4

одно замечание:
У меня были проблемы с websockets и корпоративными брандмауэрами. (Использование HTTPS помогает, Но не всегда.)

см.https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94

Я предположим не так много проблем с событиями, отправленными сервером. Но я не знаю.

тем не менее, WebSockets-это тонны удовольствия. У меня есть немного веб-игра, которая использует websockets (через сокет.IO) (http://minibman.com)

3

здесь это разговор о различиях между веб-сокетами и отправленными сервером событиями. Начиная с Java EE 7 a WebSocket API уже является частью спецификации, и кажется, что события, отправленные сервером, будут выпущены в далее версия enterprise edition.

0

WebSocket и SSE являются альтернативами традиционной веб-архитектуры запроса-ответа,но они не являются конкурирующими технологиями. Архитектура WebSocket состоит из сокета, открытого между клиентом и сервером для полнодуплексной (двунаправленной) связи. Вместо отправки сообщения GET и ожидания ответа сервера клиент просто прослушивает сокет, получая обновления сервера и используя данные для запуска или поддержки различных взаимодействия. Клиент также может использовать сокет для связи с сервером, например, отправив сообщение ACK после успешного получения обновления.

SSE-это более простой стандарт, разработанный как расширение HTML5. Хотя SSE включает асинхронные сообщения с сервера на клиент, клиент не может отправлять сообщения на сервер. Модель полудуплексной связи SSE лучше всего подходит для приложений, где клиенту просто нужно получать потоковые обновления от сервер. Одним из преимуществ SSE над WebSocket является то, что он работает через HTTP, не требуя дополнительных компонентов.

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

источник

0

максимальный предел соединения не является проблемой с http2 + sse.

Это была проблема на http 1

-4