Websocket和SSE（服务器发送事件）都能够将数据推送到浏览器，但是它们不是竞争技术。

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

SSE连接只能将数据推送到浏览器。在线股票报价或Twitter的更新时间表或提要是可以从SSE中受益的应用程序的很好示例。

实际上，由于SSE可以完成的所有事情也都可以通过Websockets完成，因此Websockets得到了更多的关注和喜爱，并且与SSE相比，更多的浏览器支持Websockets。

但是，对于某些类型的应用程序来说，它可能会显得过大，并且使用诸如SSE之类的协议可以更轻松地实现后端。

此外，可以将SSE填充到不仅使用JavaScript本身不支持它的旧版浏览器中。可以在Modernizr
github页面上找到SSE polyfills的一些实现。

陷阱：

• SSE受最大打开连接数的限制，这在打开各种选项卡时会特别痛苦，因为该限制是针对 每个浏览器的， 并且设置为一个非常低的数字（6）。该问题在Chrome和Firefox中被标记为“无法解决”。此限制是针对每个浏览器+域的，因此这意味着您可以在所有选项卡上打开6个SSE连接，并在上打开www.example1.com另外6个SSE连接www.example2.com（感谢Phate）。
• 只有WS可以传输二进制数据和UTF-8，而SSE限于UTF-8。（感谢Chado Nihi）。
• 某些具有数据包检查功能的企业防火墙在处理WebSockets时遇到问题（Sophos XG Firewall，WatchGuard，McAfee Web Gateway）。

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

服务器发送的事件与WebSockets

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

SSE被遮盖的原因之一是因为后来的API（如WebSocket）提供了更丰富的协议来执行双向全双工通信。对于游戏，消息传递应用程序以及需要双向双向实时更新的情况，拥有双向通道更具吸引力。但是，在某些情况下，不需要从客户端发送数据。您只需要某些服务器操作的更新即可。几个例子是朋友的状态更新，股票行情自动收录器，新闻提要或其他自动数据推送机制（例如，更新客户端Web
SQL数据库或IndexedDB对象存储）。如果您需要将数据发送到服务器，则XMLHttpRequest始终是朋友。

SSE通过传统的HTTP发送。这意味着它们不需要特殊的协议或服务器实现即可工作。另一方面，WebSockets需要全双工连接和新的Web
Socket服务器来处理协议。另外，服务器发送的事件具有WebSocket设计上缺少的各种功能，例如自动重新连接，事件ID和发送任意事件的功能。

TLDR摘要：

SSE相对于Websockets的优势：

• 通过简单的HTTP而不是自定义协议进行传输
• 可以用JavaScript进行多填充，以将SSE“反向移植”到尚不支持的浏览器。
• 内置对重新连接和事件ID的支持
• 更简单的协议
• 公司防火墙进行数据包检查没有问题

Websockets相对于SSE的优势：

• 实时，双向通讯。
• 更多浏览器的本机支持

SSE的理想用例：

• 股票行情自动收录
• Twitter提要更新
• 通知浏览器

SSE陷阱：

• 没有二进制支持
• 最大开放连接数限制