服务端如何推送消息给客户端?

2,173 阅读3分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第9天,点击查看活动详情

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

有时候,我们希望服务端能够主动推送一些信息给客户端。但 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 协议则是专门为了解决服务推送问题而发明的协议,能够真正实现服务端的主动推送,适合服务推送比较重的场景。

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


相关阅读,

HTTP 中的常用状态码及使用场景

你需要知道的 TCP 三次握手

HTTP 缓存策略:强缓存和协商缓存

文章首发于我的公众号:前端西瓜哥