现在确实有不少这样的场景，当后台数据发生变化，需要主动“通知”前台进行页面刷新，实现方案有这么几种：

轮询

很容易理解，实现起来也非常简单的一种方法：客户端每隔一段时间向后台发送一次请求，把最新的数据取回来。

当然缺点也比较明显，如果定时任务的时间设置比较长，那么数据更新和展示会不及时；如果定时任务的时间设置的比较短，那么频繁地访问后台，也会增加后台服务器的压力。

看到各位的没有抓住题主问题，WEB实时推送，不是WEB实时交互。

WEB实时推送指的是服务器端向客户端用户推送。

以下是我的，每个答案和各个场景有关。

1、ajax轮询 -简单开发成本小

ajax轮询是客户端发起的，可以根据自己的需要，指定一个合理的时间。这种方法非常简单，几乎不需要什么改动。

2、服务端推送SSE-简单可靠性能好

SSE是Server-sent Events的简称，它是HTML5中的一种规范。目前为止那些老旧的浏览器是不直接支持SSE规范的，比如IE内核的浏览器。

SSE这个东西是可以实现服务端主动向客户端进行通信的，但是它仅仅是单向的。如果客户端与服务器端的数据交互不是特别频繁，那么我们是可以使用SSE技术来实现的。

什么年代了，还轮训，只有一种方案 websocket

随着 Web 的发展，用户对于 Web 的实时推送要求也越来越高 ，比如，工业运行监控、Web 在线通讯、即时报价系统、在线游戏等，都需要将后台发生的变化主动地、实时地传送到浏览器端，而不需要用户手动地刷新页面。本文对过去和现在流行的 Web 实时推送技术进行了比较与总结。

本文完整的源代码请猛戳Github博客，纸上得来终觉浅，建议大家动手敲敲代码。

HTTP 协议有一个缺陷：通信只能由客户端发起。举例来说，我们想了解今天的天气，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。在WebSocket协议之前，有三种实现双向通信的方式：轮询（polling）、长轮询（long-polling）和iframe流（streaming）。

轮询是客户端和服务器之间会一直进行连接，每隔一段时间就询问一次。其缺点也很明显：连接数会很多，一个接受，一个发送。而且每次发送请求都会有Http的Header，会很耗流量，也会消耗CPU的利用率。

很高兴能够看到和这个问题,作为一个科技爱好者，我简单地一下这个问题！

首先，我觉得这是一个非常好的问题，也是很多小白用户困惑之处，下面我将根据自己的经验认真这个问题。

当前，信息技术正在蓬勃发展，实时网站聊天应用程序（例如股票价格控制系统）和其他Web应用程序具有新的实时需求。解决与传统实时Web应用程序相关的问题已成为实时Web应用程序的关键问题之一。随着HTML5技术的引入，WebSocket协议允许浏览器以完全双重通信模式与服务器一起工作，从而可以更好地节省服务器资源和带宽并提供实时通信。Web实时推送方案总体架构图如下：

微服务架构是一种用于在云中部署应用程序和服务的新技术，它可以通过将应用程序和服务转换为较小的组件来有效地加速应用程序的开发和维护，从而促进其现代化和扩展。我的旨在使用WebSocket技术提供基本的实时Web通信服务，在此基础上，结合微服务的模块化结构的思想，提出了一套扩展实时Web广播的通用解决方案。

通过websocket实现

我们用mqtt中间件，实时推送难易程度暴击websocket

我知道的有两种：

1， ajax定时刷新。单方通讯。

2，websocket实时双方通讯。

web的推送的话，最优方案是用websocket，其次长轮询，再其次ajax定时向后台请求数据。如果是. net平台开发的程序，可以用SignalR，它包含了以上三种方案并优先使用webSocket进行通讯

如果后端用的是.net，可以用signalr，很方便的，5分钟就能上手。