Оба WebSockets и Отправленные сервером события способны передавать данные в браузеры. Мне они кажутся конкурирующими технологиями. В чем разница между ними? Когда бы вы выбрали один над другим?
События WebSockets или Server-Sent/EventSource
Ответ 1
Websockets и SSE (Server Sent Events) способны передавать данные в браузеры, однако они не являются конкурирующими технологиями.
Соединения через веб-сокеты могут отправлять данные в браузер и получать данные из браузера. Хорошим примером приложения, которое может использовать веб-сокеты, является приложение чата.
Соединения SSE могут передавать данные только в браузер. Онлайн котировки акций или твиттеры, обновляющие сроки или фид, являются хорошими примерами приложения, которое может выиграть от SSE.
На практике, поскольку все, что можно сделать с помощью SSE, можно также сделать с помощью Websockets, Websockets привлекает гораздо больше внимания и любви, и многие другие браузеры поддерживают Websockets, чем SSE.
Тем не менее, это может быть излишним для некоторых типов приложений, и бэкэнд может быть проще реализовать с помощью протокола, такого как SSE.
Кроме того, SSE можно использовать в старых браузерах, которые изначально не поддерживают его, используя только JavaScript. Некоторые реализации полизаполнений SSE можно найти на странице gizub Modernizr.
Gotchas:
- SSE страдает от ограничения максимального количества открытых соединений, что может быть особенно болезненным при открытии различных вкладок, поскольку ограничение для каждого браузера установлено на очень низкое число (6). Эта проблема помечена как "Не устранена" в Chrome и Firefox
- .Только WS может передавать как двоичные данные, так и UTF-8, SSE ограничен UTF-8. (Спасибо Чадо Нихи).
- Некоторые корпоративные брандмауэры с проверкой пакетов испытывают трудности при работе с WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).
HTML5Rocks содержит полезную информацию о SSE. С этой страницы:
Отправленные сервером события против WebSockets
Почему вы выбрали бы Отправленные сервером события вместо WebSockets? Хороший вопрос.
Одна из причин, по которой SSE остаются в тени, заключается в том, что более поздние API, такие как WebSockets, предоставляют более богатый протокол для двунаправленной полнодуплексной связи. Наличие двустороннего канала более привлекательно для таких вещей, как игры, приложения для обмена сообщениями, а также для случаев, когда вам нужны обновления в реальном времени в обоих направлениях. Однако в некоторых случаях данные не нужно отправлять с клиента. Вам просто нужны обновления от некоторых действий сервера. Примерами могут служить обновления статуса друзей, биржевые сводки, новостные ленты или другие автоматизированные механизмы передачи данных (например, обновление клиентской базы данных Web SQL или хранилища объектов IndexedDB). Если вам нужно отправить данные на сервер, XMLHttpRequest всегда будет вашим другом.
SSE передаются по традиционному HTTP. Это означает, что они не требуют специального протокола или серверной реализации для работы. WebSockets, с другой стороны, требуют полнодуплексных соединений и новых серверов Web Socket для обработки протокола. Кроме того, события, отправляемые сервером, имеют множество функций, которые отсутствуют в WebSockets, такие как автоматическое переподключение, идентификаторы событий и возможность отправлять произвольные события.
Резюме TLDR:
Преимущества SSE перед Websockets:
- Транспортируется по простому HTTP вместо пользовательского протокола
- Может быть заполнен javascript для "обратного переноса" SSE в браузеры, которые его еще не поддерживают.
- Встроенная поддержка повторного подключения и идентификатора события
- Более простой протокол
- Нет проблем с корпоративными брандмауэрами, выполняющими проверку пакетов
Преимущества веб-сокетов перед SSE:
- В режиме реального времени, двунаправленное общение.
- Встроенная поддержка в нескольких браузерах
Идеальные варианты использования SSE:
- Поток тикера на бирже
- обновление фида в твиттере
- Уведомления для браузера
SSE получил:
- Нет бинарной поддержки
- Максимальный предел открытых соединений
Ответ 2
По данным caniuse.com:
- % 96 глобальных пользователей изначально поддерживают WebSockets
- % 92 глобальных пользователей поддерживают отправленные сервером события
Вы можете использовать клиентский полифилл, чтобы расширить поддержку SSE для многих других браузеров. Это менее вероятно с WebSockets. Некоторые полифилы EventSource:
- EventSource Реми Шарпа без других библиотечных зависимостей (IE7+)
- jQuery.EventSource Рика Уолдрона
- EventSource от Yaffle (заменяет собственную реализацию, нормализуя поведение в разных браузерах)
Если вам требуется поддержка всех браузеров, рассмотрите возможность использования библиотеки, такой как web-socket-js, SignalR или socket.io, которая поддерживает несколько транспортов, таких как WebSockets., SSE, Forever Frame и AJAX длительный опрос. Они также часто требуют изменений на стороне сервера.
Подробнее о SSE читайте в:
- HTML5 Rocks статья
- Спецификация W3C (опубликованная версия, редакторская редакция)
Подробнее о WebSockets можно узнать из:
- HTML5 Rocks статья
- Спецификация W3C (опубликованная версия, редакторская редакция)
Другие отличия:
- WebSockets поддерживает произвольные двоичные данные, SSE использует только UTF-8
Ответ 3
Opera, Chrome, Safari поддерживает SSE, Chrome, Safari поддерживает SSE внутри SharedWorker Firefox поддерживает XMLHttpRequest readyState в интерактивном режиме, поэтому мы можем сделать polyfil EventSource для Firefox
Ответ 4
Websocket VS SSE
Веб-сокеты -. Это протокол, обеспечивающий полнодуплексный канал связи по одному TCP-соединению. Например, двусторонняя связь между Сервером и Браузером
Поскольку протокол более сложный, сервер и браузер должны полагаться на библиотеку websocket
который socket.io
Example - Online chat application.
SSE (событие, отправленное сервером) -
В случае серверного события связь выполняется только с сервера на браузер, и браузер не может отправлять какие-либо данные на сервер. Такое общение в основном используется
когда необходимо показывать только обновленные данные, сервер отправляет сообщение всякий раз, когда данные обновляются. Например, односторонняя связь между сервером и браузером.
Этот протокол менее сложный, поэтому нет необходимости полагаться на внешнюю библиотеку. Сам JAVASCRIPT предоставляет интерфейс EventSource для приема отправленных сервером сообщений.
Example - Online stock quotes or cricket score website.
Ответ 5
Одно замечание:
У меня были проблемы с веб-сайтами и корпоративными брандмауэрами. (Использование HTTPS помогает, но не всегда.)
См. https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94
Я предполагаю, что проблем с Server-Sent Events не так много. Но я не знаю.
Тем не менее, WebSockets - это очень весело. У меня есть небольшая веб-игра, в которой используются websockets (через Socket.IO) (http://minibman.com)
Ответ 6
Here - это разговоры о различиях между веб-сокетами и событиями, отправленными сервером. Поскольку Java EE 7 API WebSocket уже является частью спецификации, и кажется, что отправленные сервером события будут выпущены в следующая версия версии предприятия.
Ответ 7
Максимальное ограничение соединения не является проблемой с http2 + sse.
Это была проблема на http 1