大家好，我是前端西瓜哥，今天带大家了解一下服务端如何推送消息给客户端。

有时候，我们希望服务端能够主动推送一些信息给客户端。但 HTTP 协议只能让客户端发起请求然后服务端响应，而无法让服务端主动去发送信息。

为了解决这个问题，我们有三种常见的解决方案：短轮询、长轮询、WebSocket。

短轮询

短轮询，就是不停地间隔一段时间发一个 HTTP 请求，直到拿到需要的信息才结束。

假设用户用支付平台支付了我们的订单，但因为支付平台是异步通知到我们的服务器，前端页面无法拿到支持是否成功的信息，需要服务器去告知前端。

我们用短轮询，大概是这样子：

A：订单完成了吗？

B：没有。

A：（200ms 后）订单完成了吗？

B：没有。

A：（接收请求再200ms 后）订单完成了吗？

B：没有。

......（问答持续了好几次）

A：订单完成了吗？

B：完成了。

轮询结束，这样 A 就拿到了订单完成的信息，进行订单完成的 UI 展示。

短轮询实现简单，服务端不需要做太多特殊处理，但频繁地发送请求，会更消耗带宽。

长轮询

长轮询：客户端发一个 HTTP 请求，服务端长时间将连接挂起，长时间不返回数据，直到拿到需要信息才返回。

大概这样子：

A：订单完成了吗？

.....（过了好一段时间）

B：完成了。

这样轮询就结束了。

长轮询的问题是 HTTP 变成了一个长连接，长时间没有反应，有可能因为资源不足被意外关闭。极端情况下可能还会触发网关的超时错误，返回 504 网关超时。这些情况都需要一些策略进行处理。

此外代码实现上相比短轮询也复杂，比如订单是否完成，你要监听某个订单的状态变化，然后通知到特定的请求上，比短轮询的直接读数据库返回数据要麻烦得多。

WebSocket

因为有服务端主动推送消息的需求，所以 WebSocket 协议出现了。

WebSocket 和 HTTP 协议一样，是应用层协议，上层也是依靠传输层的 TCP 协议进行数据传输。

不同的是，WebSocket 有完整的全双工能力，支持服务端主动推送，且具有较低的开销。在服务端推送比较重的应用中，比如聊天室，WebSocket 是不二人选。

浏览器建立 WebSocket 的过程：先发送 HTTP 请求，其中带上请求升级为 WebSocket 的相关头字段，服务端如果支持，就会返回 101 状态码，表示可以切换协议，建立好 WebSocket 连接。

之后浏览器就可以通过监听事件的方式获取服务端主动推送消息了。

结尾

短轮训的特点是实现简单，不需要太多改造工作。

长轮询会将 HTTP 请求挂起，直到状态变化时才返回数据给客户端，可以减少请求数量和带宽，但需要考虑意外关闭的情况，且实现复杂。

WebSocket 协议则是专门为了解决服务推送问题而发明的协议，能够真正实现服务端的主动推送，适合服务推送比较重的场景。

我是前端西瓜哥，欢迎关注我，学习更多前端面试题。