WebSocket和服务器发送事件都能够将数据推送到浏览器。在我看来，它们似乎是相互竞争的技术。他们之间有什么区别？你什么时候会选择一个而不是另一个
WebSocket和SSE（服务器发送事件）都能够将数据推送到浏览器，但它们不是相互竞争的技术
WebSocket连接既可以向浏览器发送数据，也可以从浏览器接收数据。可以使用WebSocket的应用程序的一个很好的例子是聊天应用程序
SSE连接只能将数据推送到浏览器。在线股票报价，或推特更新时间线或提要，都是可以从SSE获益的应用程序的好例子
实际上，由于使用SSE可以完成的一切都可以通过WebSocket完成，WebSocket得到了更多的关注和喜爱，支持WebSocket的浏览器也比SSE多得多
但是，对于某些类型的应用程序来说，这可能会有点过头，并且后端可以更容易地使用诸如SSE之类的协议来实现
此外，SSE可以多填充到不支持它的旧浏览器中，这些浏览器本机仅使用JavaScript。SSE polyfills的一些实现可以在Modernizer github页面上找到
Gotchas:
- SSE受到最大打开连接数的限制，打开各种选项卡时可能会特别痛苦，因为每个浏览器的限制为，并且设置为非常低的数目（6）。这个问题在Chrome和Firefox中被标记为“无法修复”。此限制为每个浏览器+域，因此这意味着您可以在所有选项卡上打开6个指向
www.example1.com的SSE连接，以及另外6个指向www.example2.com的SSE连接（感谢Phate） - 只有WS可以传输二进制数据和UTF-8，SSE仅限于UTF-8。（感谢Chado Nihi）
- 一些具有数据包检查功能的企业防火墙在处理WebSocket时遇到问题（Sophos XG防火墙、WatchGuard、McAfee Web网关）
HTML5Rocks有一些关于SSE的好信息。从该页：
服务器发送事件与WebSocket
为什么选择服务器发送的事件而不是WebSocket？好问题
SSE一直处于阴影中的一个原因是，后来的API（如WebSocket）提供了更丰富的协议来执行双向全双工通信。对于游戏、消息传递应用程序以及需要在两个方向上进行近实时更新的情况，双向通道更具吸引力。但是，在某些情况下，不需要从客户端发送数据。您只需要从某些服务器操作中进行更新。例如，朋友的状态更新、股票行情、新闻提要或其他自动数据推送机制（例如，更新客户端Web SQL数据库或IndexedDB对象存储）。如果需要向服务器发送数据，XMLHttpRequest始终是您的朋友
SSE通过传统HTTP发送。这意味着它们不需要特殊的协议或服务器实现就可以工作。另一方面，WebSocket需要全双工连接和新的Web套接字服务器来处理协议。此外，服务器发送的事件具有WebSocket设计上缺乏的各种功能，如自动重新连接、事件ID和发送任意事件的能力
TLDR摘要：
SSE相对于WebSocket的优势：
- 通过简单HTTP而不是自定义协议传输
- 可以用javascript填充多边形，将SSE“后端口”到尚不支持它的浏览器
- 内置对重新连接和事件id的支持
- 简单协议
- 公司防火墙进行数据包检查没有问题
WebSocket相对于SSE的优势：
- 实时双向通信
- 更多浏览器中的本机支持
SSE的理想用例：
- 股票代码流
- 推特提要更新
- 向浏览器发送通知
苏格兰和南方能源公司的问题：
- 没有二进制支持
- 最大开放连接限制