WebSockets与服务器
WebSockets和Server-Sent Events都可以将数据推送到浏览器。 对我来说，他们似乎是竞争技术。 他们有什么区别？ 你什么时候选择一个呢？
Websockets和SSE（Server Sent Events）都能够将数据推送到浏览器，但它们不是竞争技术。
Websockets连接既可以将数据发送到浏览器，也可以从浏览器接收数据。 一个可以使用websockets的应用程序的好例子是一个聊天应用程序。
SSE连接只能将数据推送到浏览器。 在线股票报价或更新时间线或订阅源的推文是可以从SSE中受益的应用的好例子。
在实践中，因为所有可以用SSE完成的事情都可以通过Websockets完成，所以Websockets得到了更多的关注和热爱，并且许多浏览器支持Websockets而不是SSE。
但是，对于某些类型的应用程序来说这可能是过分的，而后端可能更容易使用SSE等协议来实现。
此外，SSE可以填充到旧式浏览器中，而这些浏览器本身不支持JavaScript。 在Modernizr github页面上可以找到SSE polyfills的一些实现。
陷阱：
HTML5Rocks在SSE上有一些很好的信息。 从该页面：
服务器发送的事件与WebSockets
为什么你会选择通过WebSockets的Server-Sent Events？ 好问题。
SSE一直处于阴影之中的原因之一是因为后来的API如WebSockets提供了更丰富的协议来执行双向全双工通信。 拥有双向频道对游戏，消息应用程序等事物更具吸引力，以及您需要双向接近实时更新的情况。 但是，在某些情况下，数据不需要从客户端发送。 你只需要一些服务器动作的更新。 一些例子是朋友的状态更新，股票报价，新闻提要或其他自动数据推送机制（例如，更新客户端Web SQL数据库或IndexedDB对象存储）。 如果你需要发送数据到服务器，XMLHttpRequest永远是朋友。
SSE通过传统的HTTP发送。 这意味着他们不需要特殊的协议或服务器实施就可以工作。 另一方面，WebSocket需要全双工连接和新的Web Socket服务器来处理协议。 另外，Server-Sent Events具有WebSockets在设计时缺乏的各种功能，例如自动重新连接，事件ID以及发送任意事件的能力。
TLDR总结：
SSE优于Websockets的优势：
Websockets比SSE的优势：
SSE的理想用例：
SSE陷阱：
根据caniuse.com：
您可以使用仅客户端的polyfill将SSE的支持扩展到许多其他浏览器。 WebSockets的可能性较小。 一些EventSource填充：
如果您需要支持所有浏览器，请考虑使用像web-socket-js，SignalR或socket.io这样的库，它支持多种传输方式，例如WebSockets，SSE，Forever Frame和AJAX长轮询。 这些通常也需要对服务器端进行修改。
了解更多关于SSE的信息：
通过以下网址了解更多关于WebSockets
其他差异：
Opera，Chrome，Safari支持SSE，Chrome，Safari支持SSE里面的SharedWorker Firefox支持XMLHttpRequest readyState交互，所以我们可以为Firefox制作EventSource polyfil
链接地址: http://www.djcxy.com/p/31325.html