Websockets 和 SSE（服务器发送事件）都能够将数据推送到浏览器，但它们不是竞争技术。
Websockets 连接既可以向浏览器发送数据，也可以从浏览器接收数据。可以使用 websockets 的应用程序的一个很好的例子是聊天应用程序。
SSE 连接只能向浏览器推送数据。在线股票报价或 Twitter 更新时间线或提要都是可以从 SSE 中受益的应用程序的很好示例。
在实践中，由于 SSE 可以完成的所有事情也可以通过 Websockets 完成，因此 Websockets 得到了更多的关注和喜爱，并且比 SSE 支持 Websockets 的浏览器更多。
但是，对于某些类型的应用程序来说，它可能有点矫枉过正，而且后端可能更容易使用 SSE 等协议来实现。
此外，SSE 可以被 polyfill 到不支持它的旧浏览器中，这些浏览器只使用 JavaScript。可以在Modernizr github 页面上找到 SSE polyfill 的一些实现。
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）时遇到问题。
为什么你会选择服务器发送的事件而不是 WebSockets？好问题。
SSE 一直处于阴影中的一个原因是因为后来的 API 像 WebSockets 提供了更丰富的协议来执行双向、全双工通信。拥有双向通道对于游戏、消息传递应用程序以及需要双向近实时更新的情况更具吸引力。但是，在某些情况下，不需要从客户端发送数据。您只需要来自某些服务器操作的更新。一些示例是朋友的状态更新、股票行情、新闻提要或其他自动数据推送机制（例如更新客户端 Web SQL 数据库或 IndexedDB 对象存储）。如果您需要向服务器发送数据，XMLHttpRequest 始终是您的好帮手。
SSE 通过传统 HTTP 发送。这意味着它们不需要特殊的协议或服务器实现即可工作。另一方面，WebSockets 需要全双工连接和新的 Web Socket 服务器来处理协议。此外，Server-Sent Events 具有 WebSockets 在设计上缺乏的各种功能，例如自动重新连接、事件 ID 以及发送任意事件的能力。
参考(文章也值得一看)：
www.html5rocks.com/en/tutorial…
SSE 相对于 Websockets 的优势：
通过简单的 HTTP 而不是自定义协议传输
可以用 javascript 填充以将 SSE“反向移植”到尚不支持它的浏览器。
内置支持重新连接和事件 ID
更简单的协议
企业防火墙进行数据包检查没有问题
Websockets 相对于 SSE 的优势：
实时，双向通信。
更多浏览器的原生支持
SSE的理想用例：
股票行情流
推特提要更新
浏览器通知
SSE 陷阱：
没有二进制支持
最大开放连接数限制
可参考：
stackoverflow.com/questions/5…
公众号《毛毛虫的小小蜡笔》
有疑问和问题，请留言。
如果觉得文章还可以，请点赞或收藏，谢谢。
