Як WebSockets, так і серверні події можуть надсилати дані до браузерів. Мені вони здаються конкуруючими технологіями. У чому різниця між ними? Коли б ви вибрали одне над іншим?

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

З'єднання веб-розетки можуть як надсилати дані до браузера, так і отримувати дані від браузера. Хорошим прикладом програми, яка може використовувати веб-розетки, є програма для чату.

З'єднання SSE можуть передавати дані лише в браузер. Котирування акцій в Інтернеті або щебетати, що оновлюють часові шкали або канал, є хорошими прикладами програми, яка може отримати користь від SSE.

На практиці, оскільки все, що можна зробити з SSE, можна зробити і за допомогою Websockets, Websockets отримує набагато більше уваги та любові, і багато інших браузерів підтримують Websockets, ніж SSE.

Однак це може бути надмірним для деяких типів додатків, і бекенд може бути простіше реалізувати з таким протоколом, як SSE.

Крім того, SSE можна переповнити старими веб-переглядачами, які не підтримують його за допомогою JavaScript. Деякі реалізації поліелементів SSE можна знайти на сторінці Modernizr github .

Отримав:

• SSE страждає від обмеження максимальної кількості відкритих з'єднань, що може бути особливо болючим при відкритті різних вкладок, оскільки обмеження визначено для браузера і встановлене на дуже низьке число (6). У Chrome і Firefox проблему було позначено як "Не вдасться виправити" . Цей ліміт призначений для одного браузера + домену, тобто це означає, що ви можете відкрити 6 SSE-з'єднань на всіх вкладках до www.example1.comта ще 6 підключень SSE www.example2.com(спасибі Phate).
• Лише WS може передавати як бінарні дані, так і UTF-8, SSE обмежений UTF-8. (Спасибі Чадо Ніхі).
• У деяких корпоративних брандмауерах при перевірці пакетів виникають проблеми з веб-розетками (брандмауер Sophos XG, WatchGuard, McAfee Web Gateway).

HTML5Rocks має хорошу інформацію про SSE. З цієї сторінки:

Події, надіслані сервером проти WebSockets

Чому б ви вибрали серверні події через WebSockets? Хороше питання.

Однією з причин, що SSE залишаються в тіні, є те, що пізніші API, такі як WebSockets, надають більш багатий протокол для здійснення двонаправленого, дуплексного зв'язку. Наявність двостороннього каналу привабливіше для таких речей, як ігри, додатки для обміну повідомленнями, а також для випадків, коли вам потрібно оновити в реальному часі в обох напрямках. Однак у деяких сценаріях дані не потрібно надсилати від клієнта. Вам просто потрібні оновлення від деяких дій сервера. Кілька прикладів - оновлення статусу друзів, біржові запаси, канали новин або інші автоматизовані механізми передачі даних (наприклад, оновлення клієнтської бази даних SQL на базі даних або об’єктного магазину IndexedDB). Якщо вам потрібно буде надіслати дані на сервер, XMLHttpRequest завжди є другом.

SSE передаються через традиційний HTTP. Це означає, що їм не потрібен спеціальний протокол або реалізація сервера для роботи. З іншого боку, для обробки протоколу WebSockets вимагають повного дуплексного з'єднання та нових серверів Web Socket. Окрім того, серверні події мають різні функції, яких WebSockets не вистачає в дизайні, такі як автоматичне повторне підключення, ідентифікатори подій та можливість надсилання довільних подій.

Підсумок TLDR:

Переваги SSE над Websockets:

• Транспортується через простий HTTP замість спеціального протоколу
• Можна наповнити javascript, щоб "підтримувати" SSE для браузерів, які ще не підтримують його.
• Вбудована підтримка повторного підключення та ідентифікатора події
• Простіший протокол
• Немає проблем з корпоративними брандмауерами, які роблять перевірку пакетів

Переваги Websockets над SSE:

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

Ідеальні випадки використання SSE:

• Поточний тикер потоку
• оновлення каналу Twitter
• Повідомлення для браузера

SSE отримали:

• Немає бінарної підтримки
• Максимальна межа відкритого з'єднання

За інформацією caniuse.com:

• % 96 глобальних користувачів споконвічно підтримують WebSockets
• % 92 глобальних користувачів споконвічно підтримують події, що надсилаються сервером

Для розширення підтримки SSE для багатьох інших веб-переглядачів можна використовувати лише поліфункцію для клієнта. Це менш ймовірно для WebSockets. Деякі поліфіли EventSource:

• EventSource від Remy Sharp без інших залежностей від бібліотеки (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

Opera, Chrome, Safari підтримує SSE, Chrome, Safari підтримує SSE всередині SharedWorker Firefox підтримує XMLHttpRequest readyState інтерактивним, тому ми можемо зробити EventSource поліфільмом для Firefox

Websocket VS SSE

Веб-розетки - це протокол, який забезпечує повнодуплексний канал зв'язку по одному TCP-з'єднанню. Наприклад, двосторонній зв'язок між сервером та браузером Оскільки протокол складніший, сервер і браузер повинні покладатися на бібліотеку веб-сокета, яка єsocket.io

Example - Online chat application.

SSE (Server-Sent Event) - У разі події, надісланої сервером, зв’язок здійснюється з сервера лише в браузер, і браузер не може надсилати будь-які дані на сервер. Цей вид зв'язку в основному використовується, коли потрібно лише показати оновлені дані, тоді сервер надсилає повідомлення щоразу, коли дані оновлюються. Наприклад, односторонній зв'язок між сервером та браузером. Цей протокол менш складний, тому не потрібно покладатися на зовнішню бібліотеку. Сам 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/isissue/94

Я припускаю, що з подіями, надісланими сервером, не так багато проблем. Але я не знаю.

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

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

Максимальна межа з'єднання не є проблемою для http2 + sse.

Це було проблемою на http 1