大家好，我是前端西瓜哥，今天带大家了解一下服务端如何推送消息给客户端。
有时候，我们希望服务端能够主动推送一些信息给客户端。但 HTTP 协议只能让客户端发起请求然后服务端响应，而无法让服务端主动去发送信息。
为了解决这个问题，我们有三种常见的解决方案：短轮询、长轮询、WebSocket。
短轮询，就是不停地间隔一段时间发一个 HTTP 请求，直到拿到需要的信息才结束。
假设用户用支付平台支付了我们的订单，但因为支付平台是异步通知到我们的服务器，前端页面无法拿到支持是否成功的信息，需要服务器去告知前端。
我们用短轮询，大概是这样子：
A：订单完成了吗？
B：没有。
A：（200ms 后）订单完成了吗？
B：没有。
A：（接收请求再200ms 后）订单完成了吗？
B：没有。
…（问答持续了好几次）
A：订单完成了吗？
B：完成了。
轮询结束，这样 A 就拿到了订单完成的信息，进行订单完成的 UI 展示。
短轮询实现简单，服务端不需要做太多特殊处理，但频繁地发送请求，会更消耗带宽。
长轮询：客户端发一个 HTTP 请求，服务端长时间将连接挂起，长时间不返回数据，直到拿到需要信息才返回。
大概这样子：
A：订单完成了吗？
…（过了好一段时间）
B：完成了。
这样轮询就结束了。
长轮询的问题是 HTTP 变成了一个长连接，长时间没有反应，有可能因为资源不足被意外关闭。极端情况下可能还会触发网关的超时错误，返回 504 网关超时。这些情况都需要一些策略进行处理。
此外代码实现上相比短轮询也复杂，比如订单是否完成，你要监听某个订单的状态变化，然后通知到特定的请求上，比短轮询的直接读数据库返回数据要麻烦得多。
因为有服务端主动推送消息的需求，所以 WebSocket 协议出现了。
WebSocket 和 HTTP 协议一样，是应用层协议，上层也是依靠传输层的 TCP 协议进行数据传输。
不同的是，WebSocket 有完整的全双工能力，支持服务端主动推送，且具有较低的开销。在服务端推送比较重的应用中，比如聊天室，WebSocket 是不二人选。
浏览器建立 WebSocket 的过程：先发送 HTTP 请求，其中带上请求升级为 WebSocket 的相关头字段，服务端如果支持，就会返回 101 状态码，表示可以切换协议，建立好 WebSocket 连接。
之后浏览器就可以通过监听事件的方式获取服务端主动推送消息了。
短轮训的特点是实现简单，不需要太多改造工作。
长轮询会将 HTTP 请求挂起，直到状态变化时才返回数据给客户端，可以减少请求数量和带宽，但需要考虑意外关闭的情况，且实现复杂。
WebSocket 协议则是专门为了解决服务推送问题而发明的协议，能够真正实现服务端的主动推送，适合服务推送比较重的场景。
我是前端西瓜哥，欢迎关注我，学习更多前端面试题。