Вопросы Теги

WebSocket или SSE [дубликат] 

//Get data from database, then sort list by staff name:

List<StaffMember> staffList = staffHandler.GetStaffMembers();

var sortedList = from staffmember in staffList
                 orderby staffmember.Name ascending
                 select staffmember;
624
задан Mads Mobæk 4 March 2011 в 16:07
поделиться

8 ответов

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

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

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

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

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

Кроме того, SSE может быть заполнен в старых браузерах, которые не поддерживают его, используя только JavaScript. Некоторые реализации SSF-полиполков можно найти на странице gg-файла Modernizr .

Gotchas:

  • SSE имеет ограничение на максимальное число открытые соединения, которые могут быть особенно болезненными при открытии различных вкладок, поскольку предел равен на каждого браузера и установлен на очень низкое число (6). Проблема была отмечена как «Не исправлена» в Chrome и Firefox
  • Только WS может передавать как двоичные данные, так и UTF-8, SSE ограничивается UTF-8. (Спасибо Chado Nihi).

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

События с сервером и веб-узлами

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

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

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

Резюме TLDR:

Преимущества SSE над веб-сокетами:

  • Транспортировано по простому HTTP вместо пользовательского протокола
  • Может быть заполнено с помощью javascript на «backport» SSE для браузеров, которые еще не поддерживают его.
  • Встроенная поддержка повторного подключения и идентификатора события
  • Упрощенный протокол

Преимущества Веб-разъемы над SSE:

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

Идеальные варианты использования SSE:

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

SSE gotchas:

  • Нет двоичной поддержки
  • Максимальное ограничение открытых подключений
720
ответ дан Alex Recarey 19 August 2018 в 16:23
поделиться
  • 1
    Чат отлично справляется с SSE - вы можете использовать обычный POST для отправки сообщений на сервер. WebSockets потребуется только в том случае, если вы реализуете чат a'la Google Wave. – Kornel 18 July 2011 в 10:45
  • 2
    Это правда, что чат и другие приложения реального времени могут быть выполнены с помощью SSE. Однако для этого требуются ответы POSTing «вне диапазона», т. Е. Это не контролируется протоколом SSE и не является хорошим примером базового объяснения различий между SSE и веб-узлами. Вы можете реализовать чат с базовым HTTP-опросом сервера каждую секунду и POSTing новых ответов. Это не значит, что это лучший / самый элегантный способ сделать это. – Alex Recarey 9 January 2013 в 04:45
  • 3
    Я думаю, что решение pomeL является большим компромиссом для большинства случаев, поскольку JS всегда может «push & quot; вещи на сервер с помощью AJAX POST. По моему опыту, основной проблемой, как правило, была потребность в JS для опроса новой информации, но SSE позаботится об этом. : D – Jacob Pritchett 2 March 2013 в 16:45
  • 4
    @MattDiPasquale Wave посылает каждую клавишу по отдельности, когда вы ввели ее, а не сразу. 200 байтов POST накладных расходов за 1 нажатие клавиши было бы расточительным по сравнению с примерно 6 для WebSocket. – Kornel 2 November 2013 в 16:15
  • 5
    Я предлагаю книгу удивительного Даррена Кука о SSE (в сравнении с веб-сайтами) и недостатки (проблемы с задержкой в ​​сетях 3G и т. Д.): shop.oreilly.com/product/0636920030928.do и я тестирую успешно SSE с моим микропроектом: github.com/solyaris/pere – Giorgio Robino 27 November 2014 в 13:11

Согласно caniuse.com:

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

  • EventSource Remy Sharp без каких-либо других зависимостей библиотеки (IE7 +)
  • jQuery.EventSource Rick Waldron
  • EventSource by Yaffle (заменяет собственную реализацию, нормализует поведение в браузерах)

Если вы необходимо поддерживать все браузеры, подумайте об использовании библиотеки, такой как web-socket-js , SignalR или socket.io , которые поддерживают несколько транспортов, таких как WebSockets, SSE, Forever Frame и длинный опрос AJAX. Они также требуют модификации на стороне сервера.

Подробнее о SSE:

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

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

  • WebSockets поддерживает произвольные двоичные данные, SSE использует только UTF-8
87
ответ дан Community 19 August 2018 в 16:23
поделиться
  • 1
    Я хотел бы указать в 2016 году. 95% глобальных пользователей изначально поддерживают WebSockets. Все браузеры и устройства поддерживают WebSockets более 4 лет. Socket.IO вернется к длинному опросу AJAX и справится с сложностями эмуляции WebSockets для вас, если он не поддерживается, что обеспечивает поддержку 100%. Если вы используете что-либо, кроме WebSockets, в 2016 году, вы используете устаревшую технологию. – Nick Steele 19 August 2016 в 17:03

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

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

I предположить, что не так много проблем с Server-Sent Мероприятия. Но я не знаю.

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

3
ответ дан Drew LeSueur 19 August 2018 в 16:23
поделиться

Websocket VS SSE

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

Example - Online chat application.

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

Example - Online stock quotes or cricket score website.
4
ответ дан Gaurav Tiwari 19 August 2018 в 16:23
поделиться

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

0
ответ дан Patrick Leitermann 19 August 2018 в 16:23
поделиться

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

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

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

Источник

0
ответ дан Srikrushna Pal 19 August 2018 в 16:23
поделиться

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

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

-4
ответ дан user1948585 19 August 2018 в 16:23
поделиться
  • 1
    Http2 позволяет обрабатывать несколько запросов в одном домене как потоки. Этот метод называется мультиплексированием. Это позволяет сэкономить ограничения на доступ к браузере для каждого домена, что является причиной того, что люди обмениваются данными с Http1. – user1948585 25 February 2018 в 13:43
  • 2
    Потоки HTTP / 2 также ограничены в количестве, что защищает серверы от бомбардировок одним браузером и заставляет браузеры ограничивать их мультиплексирование ограниченным количеством потоков, что в нашем случае совпадает с HTTP / 1.1 соединениями. который возвращает вас к пределу соединения SSE. – Myst 13 April 2018 в 01:13
  • 3
    Я предполагаю, что соединение с websocket также потребляет ресурсы сервера. samsaffron.com/archive/2015/12/29/websockets-caution-required . Его всегда хорошо иметь возможность настраивать столько, сколько позволяет ваш карман. – user1948585 21 July 2018 в 11:58
  • 4
    вполне вероятно, что SSE будет потреблять аналогичные ресурсы на большинстве серверов (если не больше ресурсов из-за существующего HTTP-стека и его ограничений). – Myst 21 July 2018 в 13:58

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

13
ответ дан Yaffle 19 August 2018 в 16:23
поделиться
Другие вопросы по тегам:

Похожие вопросы: