服务端向客户端推送数据的实现方案

                                                          前言

在日常的开发中，我们经常能碰见服务端需要主动推送给客户端数据的业务场景，比

如 数据大屏的实时数据 ，比如消息中心的未读消息，比如聊天功能等等。

服务端向客户端推送数据的实现方案有哪几种？

我们常规实现这些需求的方案有以下三种：

▪ 轮询

▪ websocket

▪ SSE（Server-Send Events）

轮询简介：

前端一般使用轮询来进行服务端向客户端进行消息的伪推送，为什么说轮询是伪推送？

因为轮询本质上还是通过客户端向服务端发起一个单项传输的请求，服务端对这个请求做出响应而已。通过不断的请求来实现服务端向客户端推送数据的错觉。并不是服务端主动向客户端推送数据。显然，轮询一定是上述三个方法里最下策。

轮询的缺点：

▪ 首先轮询需要不断的发起请求，每一个请求都需要经过 http 建立连接的流程 （比如三次握手，四次挥手），是没有必要的消耗。

▪ 客户端需要从页面被打开的那一刻开始就一直处理请求。虽然每次轮询的消耗不大，但是一直处理请求对于客户端来说一定是不友好的。

▪ 浏览器请求并发是有限制的。比如 Chrome 最大并发请求数目为 6，这个限制还有一个前提是针对同一域名的，超过这一限制的后续请求将会被阻塞。而轮询意味着会有一个请求长时间的占用并发名额。

▪ 而如果轮询时间较长，可能又没有办法非常及时的获取数据

websocket 简介：

websocket 是一个 双向通讯的协议 ，他的优点是，可以同时支持客户端和服务端彼此相互进行通讯。功能上很强大。

缺点也很明显，websocket 是一个新的协议， ws/wss 。也就是说，支持 http 协议的浏览器不一定支持 ws 协议。

相较于 SSE 来说，websocket 因为功能更强大。结构更复杂。所以相对比较重。

websocket 对于各大浏览器的兼容性：

SSE 简介

sse 是一个单向通讯的协议也是一个 长链接 ，它 只能支持服务端主动向客户端推送数 据 ，但是无法让客户端向服务端推送消息。

长链接是一种 HTTP/1.1 的持久连接技术，它允许客户端和服务器在一次 TCP 连接上进行多个 HTTP 请求和响应，而不必为每个请求/响应建立和断开一个新的连接。长连接有助于减少服务器的负载和提高性能。

SSE 的优点是，它是一个 轻量级的协议 ，相对于 websocket 来说，他的复杂度就没有那么高，相对于客户端的消耗也比较少。

而且 SSE 使用的是 http 协议（websocket 使用的是 ws 协议），也就是现有的服务端都支持 SSE，无需像 websocket 一样需要服务端提供额外的支持。

注意:IE 大魔王不支持 SSE

SSE 对于各大浏览器的兼容性：

注意哦，上图是 SSE 对于浏览器的兼容不是对于服务端的兼容。

总结

websocket 和 SSE 有什么区别？

轮询

对于当前计算机的发展来说，几乎很少出现同时不支持 websocket 和 sse 的情况，所以轮询是在极端情况下浏览器实在是不支持 websocket 和 sse 的下策。

Websocket 和 SSE

我们一般的服务端和客户端的通讯基本上使用这两个方案。首先声明:这两个方案没有绝对的好坏，只有在不同的业务场景下更好的选择。

SSE 的官方对于 SSE 和 Websocket 的评价是

▪ WebSocket 是全双工通道，可以双向通信，功能更强；SSE 是单向通道，只能服务器向浏览器端发送。

▪ WebSocket 是一个新的协议，需要服务器端支持；SSE 则是部署在 HTTP 协议之上的，现有的服务器软件都支持。

▪ SSE 是一个轻量级协议，相对简单；WebSocket 是一种较重的协议，相对复杂。

▪ SSE 默认支持断线重连，WebSocket 则需要额外部署。

▪ SSE 支持自定义发送的数据类型。

Websocket 和 SSE 分别适用于什么业务场景？

对于 SSE 来说，它的优点就是轻，而且对于服务端的支持度要更好。换言之，可以使用 SSE 完成的功能需求，没有必要使用更重更复杂的 websocket。

比如：数据大屏的实时数据，消息中心的消息推送等一系列只需要服务端单方面推送而不需要客户端同时进行反馈的需求，SSE 就是不二之选。

对于 Websocket 来说，他的优点就是可以同时支持客户端和服务端的双向通讯。所适用的业务场景：最典型的就是聊天功能。这种服务端需要主动向客户端推送信息，并且客户端也有向服务端推送消息的需求时，Websocket 就是更好的选择。