WebSockets与Server-Sent事件/ EventSource [英] WebSockets vs. Server-Sent events/EventSource

问题描述

WebSockets 和服务器发送事件能够将数据推送到浏览器。对我来说，他们似乎是竞争技术。他们有什么区别？ Web服务器和SSE（服务器发送事件）都能够将数据推送到浏览器上但是，它们不是竞争技术。

Websockets连接既可以将数据发送到浏览器，也可以从浏览器接收数据。一个可以使用websockets的应用程序的好例子是一个聊天应用程序。

SSE连接只能将数据推送到浏览器。在线股票报价或更新时间线或订阅源的推文是可以从SSE中受益的应用程序的好例子。

在实践中，因为SSE所能做的一切都可以使用Websockets，Websockets得到了更多的关注和喜爱，并且更多的浏览器支持Websockets而不是SSE。

然而，对于某些类型的应用程序来说，它可能有点过分，并且使用SSE等协议可以更容易地实现后端。

此外，SSE可以复制到旧式浏览器中，而这些浏览器本身仅使用JavaScript来支持它。可以在 Modernizr github页面上找到SSE polyfill的一些实现。 。

陷阱：

• 限制打开连接的最大数量，当打开各种标签时特别痛苦，因为限制为每个浏览器 并且设置为非常低的数字（6）。该问题已在 Chrome 和 Firefox


• 只有WS可以传输二进制数据和UTF-8，SSE仅限于UTF-8。 （感谢Chado Nihi）。

HTML5Rocks 对SSE有一些很好的信息。从该页面：

服务器发送的事件与WebSockets

为什么会你选择通过WebSockets发送服务器事件？好问题。

SSE一直处于阴影中的一个原因是因为后来的WebSockets等API提供了更丰富的协议来执行双向全双工通信。拥有双向频道对游戏，消息应用程序等事物更具吸引力，以及您需要双向接近实时更新的情况。但是，在某些情况下，不需要从客户端发送数据。您只需要从某些服务器操作进行更新。一些例子是朋友的状态更新，股票报价，新闻提要或其他自动数据推送机制（例如，更新客户端Web SQL数据库或IndexedDB对象存储）。如果你需要发送数据到服务器，XMLHttpRequest永远是朋友。

SSE通过传统的HTTP发送。这意味着他们不需要特殊的协议或服务器实现来实现。另一方面，WebSocket需要全双工连接和新的Web Socket服务器来处理协议。另外，Server-Sent Events具有WebSockets在设计时缺乏的各种功能，例如自动重新连接，事件ID以及发送任意事件的能力。

---

TLDR概要：

SSE优于Websockets的优点 p>

• 可以通过简单的HTTP而不是自定义协议传输
  
• 可以用JavaScript填充backport SSE到尚不支持它的浏览器。


• 内置支持重新连接和事件ID


• 简单协议





Websocket优于SSE的优势：





• 实时，双向沟通。


• 更多浏览器的本地支持





上海证券交易所的理想用例：






• 股票代码流


• twitter Feed更新


• 浏览器通知
  




SSE陷阱：






• 无二进制支持


• 最大开放连接数限制
  



Both WebSockets and Server-Sent Events are capable of pushing data to browsers. To me they seem to be competing technologies. What is the difference between them? When would you choose one over the other?

解决方案

Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.

Websockets connections can both send data to the browser and receive data from the browser. A good example of an application that could use websockets is a chat application.

SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.

In practice since everything that can be done with SSE can also be done with Websockets, Websockets is getting a lot more attention and love, and many more browsers support Websockets than SSE.

However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.

Furthermore SSE can be polyfilled into older browsers that do not support it natively using just JavaScript. Some implementations of SSE polyfills can be found on the Modernizr github page.

Gotchas:

• SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox
• Only WS can transmit both binary data and UTF-8, SSE is limited to UTF-8. (Thanks to Chado Nihi).

HTML5Rocks has some good information on SSE. From that page:

Server-Sent Events vs. WebSockets

Why would you choose Server-Sent Events over WebSockets? Good question.

One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you'll need to send data to a server, XMLHttpRequest is always a friend.

SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.

---

TLDR summary:

Advantages of SSE over Websockets:

• Transported over simple HTTP instead of a custom protocol
• Can be poly-filled with javascript to "backport" SSE to browsers that do not support it yet.
• Built in support for re-connection and event-id
• Simpler protocol

Advantages of Websockets over SSE:

• Real time, two directional communication.
• Native support in more browsers

Ideal use cases of SSE:

• Stock ticker streaming
• twitter feed updating
• Notifications to browser

SSE gotchas:

• No binary support
• Maximum open connections limit

这篇关于WebSockets与Server-Sent事件/ EventSource的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！