最大连接限制不是http2 + sse的问题。

这是http 1上的问题

这里讨论Web套接字和服务器发送事件之间的区别。从Java EE 7开始，WebSocket API已经成为规范的一部分，并且服务器发送的事件似乎将在企业版的下一版本中发布。

Opera，Chrome，Safari支持SSE，Chrome，Safari在SharedWorker内部支持SSE。Firefox支持XMLHttpRequest readyState交互，因此我们可以为Firefox创建EventSource polyfil

需要注意的一件事：
我在使用websocket和公司防火墙时遇到了问题。（使用HTTPS有帮助，但并非总是如此。）

参见https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94

我认为服务器发送事件没有那么多问题。但是我不知道。

就是说，WebSocket充满了乐趣。我有一个使用websockets的小型网络游戏（通过Socket.IO）（http://minibman.com）

Websocket VS SSE

Web套接字-它是一种协议，可通过单个TCP连接提供全双工通信通道。例如，服务器和浏览器之间的双向通信由于协议更加复杂，因此服务器和浏览器必须依赖于websocket库socket.io

Example - Online chat application.

SSE（服务器发送事件）- 如果发生服务器发送事件，则仅在服务器与浏览器之间进行通信，而浏览器无法向服务器发送任何数据。这种通信主要在只需要显示更新的数据时使用，然后服务器在数据更新时发送消息。例如，服务器与浏览器之间的单向通信。该协议不太复杂，因此无需依赖外部库JAVASCRIPT本身就提供了EventSource接收服务器发送的消息的接口。

Example - Online stock quotes or cricket score website.

根据caniuse.com：

• 96％的全球用户本机支持WebSockets
• 全球用户中有92％本地支持服务器发送的事件

您可以使用仅客户端的polyfill将对SSE的支持扩展到许多其他浏览器。WebSockets不太可能这样。一些EventSource polyfills：

• Remy Sharp的EventSource，没有其他库依赖项（IE7 +）
• Rick Waldron的jQuery.EventSource
• EventSource的由Yaffle（替代原生实现，跨浏览器的行为正常化）

如果需要支持所有浏览器，请考虑使用诸如web-socket-js，SignalR或socket.io之类的库，该库支持多种传输方式，例如WebSockets，SSE，Forever Frame和AJAX长轮询。这些通常也需要修改服务器端。

从以下位置了解有关SSE的更多信息：

• HTML5 Rocks文章
• W3C规范（已发布的版本，编辑的草稿）

从以下位置了解有关WebSocket的更多信息：

• HTML5 Rocks文章
• W3C规范（已发布的版本，编辑的草稿）

其他差异：

• WebSockets支持任意二进制数据，SSE仅使用UTF-8

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

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

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

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

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

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

陷阱：

• SSE受最大打开连接数的限制，这在打开各种选项卡时会特别痛苦，因为该限制是针对每个浏览器的，并且设置为一个非常低的数字（6）。该问题在Chrome和Firefox中被标记为“无法解决”
• 只有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始终是朋友。

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
• No trouble with corporate firewalls doing packet inspection

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