WebSockets和Server-Sent Events都能够将数据推送到浏览器 . 对我来说，他们似乎是竞争技术 . 它们之间有什么区别？你何时会选择一个而不是另一个？
Here是关于Web套接字和服务器发送事件之间差异的讨论 . 从Java EE 7开始，WebSocket API已经成为规范的一部分，似乎服务器发送的事件将在企业版的next版本中发布 .
最大连接限制不是http2 sse的问题 .
这是http 1上的一个问题
Web Sockets - 这是一种通过单个TCP连接提供全双工通信信道的协议 . 例如，服务器和浏览器之间的双向通信由于协议更复杂，服务器和浏览器必须依赖websocket库，这是 socket.io
socket.io
Example - Online chat application.
SSE(Server-Sent Event) - 在服务器发送事件的情况下，通信仅从服务器到浏览器执行，浏览器不能向服务器发送任何数据 . 这种通信主要用于仅需要显示更新数据的情况，然后服务器在数据更新时发送消息 . 例如，服务器到浏览器之间的单向通信 . 这个协议不太复杂，所以不需要依赖外部库JAVASCRIPT本身提供的 EventSource 接口来接收服务器发送的消息 .
EventSource
Example - Online stock quotes or cricket score website.
WebSocket and SSE 既是传统的请求 - 响应Web架构的替代品，但它们并不完全是竞争技术 . WebSocket体系结构由在客户端和服务器之间打开的套接字组成，用于全双工（双向）通信 . 客户端只是监听套接字，接收服务器更新并使用数据来启动或支持各种交互，而不是发送GET消息并等待服务器响应 . 客户端还可以使用套接字与服务器通信，例如通过在成功接收到更新时发送ACK消息 .
SSE是一个更简单的标准，是作为HTML5的扩展而开发的 . 当SSE启用从服务器到客户端的异步消息时，客户端无法向服务器发送消息 . SSE的半双工通信模型最适合客户端只需从服务器接收流更新的应用程序 . SSE优于WebSocket的一个优点是它可以通过HTTP工作，而无需额外的组件 .
对于需要在客户端和服务器之间进行广泛通信的多用途Web应用程序，WebSocket是显而易见的选择 . SSE更适合希望从服务器向客户端传输异步数据但不需要回复的应用程序 .
Source
Websockets和SSE（服务器发送事件）都能够将数据推送到浏览器，但它们不是竞争技术 .
Websockets连接既可以将数据发送到浏览器，也可以从浏览器接收数据 . 可以使用websockets的应用程序的一个很好的例子是聊天应用程序 .
SSE连接只能将数据推送到浏览器 . 在线股票报价或更新时间轴或订阅源的twitters是可以从SSE中受益的应用程序的良好示例 .
实际上，由于SSE可以完成的所有工作也可以通过Websockets完成，因此Websockets得到了更多的关注和喜爱，并且更多的浏览器支持Websockets而不是SSE .
但是，对于某些类型的应用程序来说，它可能会过度，并且使用SSE等协议可以更容易地实现后端 .
此外，SSE可以填充到较旧的浏览器中，只使用JavaScript本身不支持它 . 可以在Modernizr github page上找到SSE polyfill的一些实现 .
Gotchas:
SSE受到最大打开连接数的限制，打开各种标签时可能会特别痛苦，因为限制是按浏览器设置的，并设置为非常低的数字（6） . 该问题已在Chrome和Firefox中标记为"Won't fix"
只有WS可以传输二进制数据和UTF-8，SSE仅限于UTF-8 . （感谢Chado Nihi） .
HTML5Rocks有一些关于SSE的好信息 . 从那个页面：
服务器发送事件与WebSockets为什么要通过WebSockets选择服务器发送事件？好问题 . SSE一直处于阴影中的一个原因是因为WebSockets等后来的API提供了更丰富的协议来执行双向全双工通信 . 拥有双向渠道对于游戏，消息应用程序以及需要双向实时更新的情况更具吸引力 . 但是，在某些情况下，不需要从客户端发送数据 . 您只需要从某些服务器操作进行更新 . 一些例子是朋友的状态更新，股票行情，新闻源或其他自动数据推送机制（例如，更新客户端Web SQL数据库或IndexedDB对象库） . 如果您需要将数据发送到服务器，XMLHttpRequest始终是朋友 . SSE通过传统HTTP发送 . 这意味着他们不需要特殊的协议或服务器实现来实现工作 . 另一方面，WebSockets需要全双工连接和新的Web Socket服务器来处理协议 . 此外，服务器发送事件具有WebSockets设计缺乏的各种功能，例如自动重新连接，事件ID以及发送任意事件的能力 .
Advantages of SSE over Websockets:
通过简单HTTP而不是自定义协议传输
可以用javascript填充"backport" SSE到尚不支持它的浏览器 .
内置支持重新连接和事件ID
更简单的协议
Advantages of Websockets over SSE:
实时，双向通信 .
更多浏览器中的原生支持
Ideal use cases of SSE:
股票报价流
twitter feed更新
浏览器通知
SSE gotchas:
没有二进制支持
最大开放连接限制
有一点需要注意：我遇到了websockets和企业防火墙的问题 . （使用HTTPS有帮助，但并非总是如此 . ）
见https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94
我假设没有't as many issues with Server-Sent Events. But I don't知道 .
也就是说，WebSockets非常有趣 . 我有一个使用websockets的小型网页游戏（通过Socket.IO）（http://minibman.com）
根据caniuse.com：
%90 of global users本机支持WebSockets
%84 of global users本机支持服务器发送的事件
您可以使用仅客户端的polyfill将SSE的支持扩展到许多其他浏览器 . 使用WebSockets的可能性较小 . 一些EventSource polyfill：
Remy Sharp的
EventSource没有其他库依赖项（IE7）Rick Waldron撰写
jQuery.EventSource
EventSource by Yaffle（替换本机实现，跨浏览器规范化行为）
如果您需要支持所有浏览器，请考虑使用像web-socket-js，SignalR或socket.io这样的库，它支持多种传输，如WebSockets，SSE，Forever Frame和AJAX长轮询 . 这些通常也需要修改服务器端 .
了解更多关于SSE的信息：
HTML5 Rocks article
W3C规范（published version，editor's draft）
了解有关WebSockets的更多信息：
其他差异：
Opera，Chrome，Safari支持SSE，Chrome，Safari支持SSE内部的SharedWorker Firefox支持XMLHttpRequest readyState交互式，因此我们可以为Firefox制作EventSource polyfil
8 回答
Here是关于Web套接字和服务器发送事件之间差异的讨论 . 从Java EE 7开始，WebSocket API已经成为规范的一部分，似乎服务器发送的事件将在企业版的next版本中发布 .
最大连接限制不是http2 sse的问题 .
这是http 1上的一个问题
Websocket VS SSE
Web Sockets - 这是一种通过单个TCP连接提供全双工通信信道的协议 . 例如，服务器和浏览器之间的双向通信由于协议更复杂，服务器和浏览器必须依赖websocket库，这是
socket.ioSSE(Server-Sent Event) - 在服务器发送事件的情况下，通信仅从服务器到浏览器执行，浏览器不能向服务器发送任何数据 . 这种通信主要用于仅需要显示更新数据的情况，然后服务器在数据更新时发送消息 . 例如，服务器到浏览器之间的单向通信 . 这个协议不太复杂，所以不需要依赖外部库JAVASCRIPT本身提供的
EventSource接口来接收服务器发送的消息 .WebSocket and SSE 既是传统的请求 - 响应Web架构的替代品，但它们并不完全是竞争技术 . WebSocket体系结构由在客户端和服务器之间打开的套接字组成，用于全双工（双向）通信 . 客户端只是监听套接字，接收服务器更新并使用数据来启动或支持各种交互，而不是发送GET消息并等待服务器响应 . 客户端还可以使用套接字与服务器通信，例如通过在成功接收到更新时发送ACK消息 .
SSE是一个更简单的标准，是作为HTML5的扩展而开发的 . 当SSE启用从服务器到客户端的异步消息时，客户端无法向服务器发送消息 . SSE的半双工通信模型最适合客户端只需从服务器接收流更新的应用程序 . SSE优于WebSocket的一个优点是它可以通过HTTP工作，而无需额外的组件 .
对于需要在客户端和服务器之间进行广泛通信的多用途Web应用程序，WebSocket是显而易见的选择 . SSE更适合希望从服务器向客户端传输异步数据但不需要回复的应用程序 .
Source
Websockets和SSE（服务器发送事件）都能够将数据推送到浏览器，但它们不是竞争技术 .
Websockets连接既可以将数据发送到浏览器，也可以从浏览器接收数据 . 可以使用websockets的应用程序的一个很好的例子是聊天应用程序 .
SSE连接只能将数据推送到浏览器 . 在线股票报价或更新时间轴或订阅源的twitters是可以从SSE中受益的应用程序的良好示例 .
实际上，由于SSE可以完成的所有工作也可以通过Websockets完成，因此Websockets得到了更多的关注和喜爱，并且更多的浏览器支持Websockets而不是SSE .
但是，对于某些类型的应用程序来说，它可能会过度，并且使用SSE等协议可以更容易地实现后端 .
此外，SSE可以填充到较旧的浏览器中，只使用JavaScript本身不支持它 . 可以在Modernizr github page上找到SSE polyfill的一些实现 .
Gotchas:
SSE受到最大打开连接数的限制，打开各种标签时可能会特别痛苦，因为限制是按浏览器设置的，并设置为非常低的数字（6） . 该问题已在Chrome和Firefox中标记为"Won't fix"
只有WS可以传输二进制数据和UTF-8，SSE仅限于UTF-8 . （感谢Chado Nihi） .
HTML5Rocks有一些关于SSE的好信息 . 从那个页面：
TLDR摘要：
Advantages of SSE over Websockets:
通过简单HTTP而不是自定义协议传输
可以用javascript填充"backport" SSE到尚不支持它的浏览器 .
内置支持重新连接和事件ID
更简单的协议
Advantages of Websockets over SSE:
实时，双向通信 .
更多浏览器中的原生支持
Ideal use cases of SSE:
股票报价流
twitter feed更新
浏览器通知
SSE gotchas:
没有二进制支持
最大开放连接限制
有一点需要注意：
我遇到了websockets和企业防火墙的问题 . （使用HTTPS有帮助，但并非总是如此 . ）
见https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94
我假设没有't as many issues with Server-Sent Events. But I don't知道 .
也就是说，WebSockets非常有趣 . 我有一个使用websockets的小型网页游戏（通过Socket.IO）（http://minibman.com）
根据caniuse.com：
%90 of global users本机支持WebSockets
%84 of global users本机支持服务器发送的事件
您可以使用仅客户端的polyfill将SSE的支持扩展到许多其他浏览器 . 使用WebSockets的可能性较小 . 一些EventSource polyfill：
Remy Sharp的
EventSource没有其他库依赖项（IE7）
Rick Waldron撰写
jQuery.EventSource
EventSource by Yaffle（替换本机实现，跨浏览器规范化行为）
如果您需要支持所有浏览器，请考虑使用像web-socket-js，SignalR或socket.io这样的库，它支持多种传输，如WebSockets，SSE，Forever Frame和AJAX长轮询 . 这些通常也需要修改服务器端 .
了解更多关于SSE的信息：
HTML5 Rocks article
W3C规范（published version，editor's draft）
了解有关WebSockets的更多信息：
HTML5 Rocks article
W3C规范（published version，editor's draft）
其他差异：
Opera，Chrome，Safari支持SSE，Chrome，Safari支持SSE内部的SharedWorker Firefox支持XMLHttpRequest readyState交互式，因此我们可以为Firefox制作EventSource polyfil