Оба WebSockets и Server-Sent Events могут передавать данные в браузеры. Для меня они, похоже, являются конкурирующими технологиями. В чем разница между ними? Когда вы выберете один за другим?
Websockets и SSE (события, отправленные сервером) могут одновременно передавать данные в браузеры, однако они не конкурируют с технологиями.
Соединения веб-соединений могут как отправлять данные в браузер, так и получать данные из браузера. Хорошим примером приложения, которое может использовать websockets, является приложение чата.
Соединения SSE могут только передавать данные в браузер. Онлайн-котировки акций или твиттеры, обновляющие временную шкалу или фид, являются хорошими примерами приложения, которое может извлечь выгоду из SSE.
На практике, поскольку все, что можно сделать с помощью SSE, также можно выполнять с помощью Websockets, Websockets получает гораздо больше внимания и любви, а многие другие браузеры поддерживают веб-узлы, чем SSE.
Однако это может быть чрезмерным для некоторых типов приложений, а бэкэнд может быть проще реализовать с помощью протокола, такого как SSE.
Кроме того, SSE можно полилизовать в более старые браузеры, которые не поддерживают его изначально, используя только JavaScript. Некоторые реализации SSF-полиполков можно найти на странице страница Modernizr github.
Gotchas:
HTML5Rocks содержит некоторую полезную информацию об SSE. С этой страницы:
События, отправленные сервером, и веб-узлы
Почему вы выбираете Server-Sent Events через WebSockets? Хороший вопрос.
Одна из причин, по которой SSE хранится в тени, заключается в том, что более поздние API, такие как WebSockets, обеспечивают более богатый протокол для выполнения двунаправленной полнодуплексной связи. Наличие двухканального канала более привлекательно для таких вещей, как игры, приложения для обмена сообщениями и для случаев, когда вам нужны почти обновления в реальном времени в обоих направлениях. Однако в некоторых сценариях данные не нужно отправлять с клиента. Вам просто нужны обновления из какого-либо действия сервера. Несколько примеров - это обновления статуса друзей, биржевые тикеры, новостные ленты или другие автоматизированные механизмы передачи данных (например, обновление клиентской базы данных веб-SQL или хранилища объектов IndexedDB). Если вам нужно отправить данные на сервер, XMLHttpRequest всегда является другом.
SSE отправляются по традиционному HTTP. Это означает, что для работы не требуется специальный протокол или реализация сервера. WebSockets, с другой стороны, требуют полнодуплексных соединений и новых серверов Socket Socket для обработки протокола. Кроме того, Server-Sent Events имеют множество функций, которые не имеют WebSockets, такие как автоматическое повторное подключение, идентификаторы событий и возможность отправки произвольных событий.
Преимущества SSE над Websockets:
Преимущества веб-узлов над SSE:
Идеальные варианты использования SSE:
SSE gotchas:
Согласно caniuse.com:
Вы можете использовать клиентский polyfill для расширения поддержки SSE во многих других браузерах. Это менее вероятно с помощью WebSockets. Некоторые полисы заполнения EventSource:
Если вам нужно поддерживать все браузеры, подумайте об использовании библиотеки, например web-socket-js, SignalR или socket.io, которые поддерживают несколько транспортов, таких как WebSockets, SSE, Forever Frame и AJAX long опрос. Они часто также требуют изменений на стороне сервера.
Узнайте больше о SSE:
Узнайте больше о WebSockets:
Другие отличия:
Opera, Chrome, Safari поддерживает SSE, Chrome, Safari поддерживает SSE внутри SharedWorker Firefox поддерживает XMLHttpRequest readyState в интерактивном режиме, поэтому мы можем сделать polyfil EventSource для Firefox
Веб-сокеты -. Это протокол, обеспечивающий полнодуплексный канал связи по одному TCP-соединению. Например, двусторонняя связь между Сервером и Браузером
Поскольку протокол более сложный, сервер и браузер должны полагаться на библиотеку websocket
который socket.io
Example - Online chat application.
SSE (событие, отправленное сервером) -
В случае серверного события связь выполняется только с сервера на браузер, и браузер не может отправлять какие-либо данные на сервер. Такое общение в основном используется
когда необходимо показывать только обновленные данные, сервер отправляет сообщение всякий раз, когда данные обновляются. Например, односторонняя связь между сервером и браузером.
Этот протокол менее сложный, поэтому нет необходимости полагаться на внешнюю библиотеку. Сам JAVASCRIPT предоставляет интерфейс EventSource
для приема отправленных сервером сообщений.
Example - Online stock quotes or cricket score website.
Одно замечание:
У меня были проблемы с веб-сайтами и корпоративными брандмауэрами. (Использование 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)
Here - это разговоры о различиях между веб-сокетами и событиями, отправленными сервером. Поскольку Java EE 7 API WebSocket уже является частью спецификации, и кажется, что отправленные сервером события будут выпущены в следующая версия версии предприятия.
Максимальное ограничение соединения не является проблемой с http2 + sse.
Это была проблема на http 1