webSocket了解

websocket应用场景

在实际的生活中我们经常会遇到：服务端会主动推送给客户端数据的业务场景，比如数据大屏的实时数据，比如消息中心的未读消息，比如聊天功能。

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

1.轮询
2.webSocket
3.SSE

轮询：

轮询的实际也是客户端向服务端发送一个单向传输的请求，服务端对这个请求做出响应而已，通过不断地请求来实现服务端向客户端发送消息的错觉，并不是服务向客户端推送数据，这种方式是比较差的。

轮询缺点：
1.每次轮询都是发送请求，建立HTTP连接，都要进行三次握手，四次挥手，这是没必要的消耗
2.如果打开页面就处理，每次都有要进行消耗，是没有必要的消耗
3.浏览器的请求是由限制的，比如Chrome最大并发是6，这个限制还有一个前提是针对的是同一个域名，超过这个限制后续的请求会被阻塞的，而轮询意味着会有一个请求长时间占用并发的名额。

websocket

webSocket是一个双向通讯协议：

优点：它的优点是，可以同时支持客户端和服务端彼此相互进行通讯，功能强大。

缺点：他是新的协议：ws/wss,也就是说，支持HTTP协议的浏览器不一定支持ws协议。

对于SEE来说：webSocket功能强大，但是也相对较重。

SEE

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

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

优点：
轻量级的协议，see是HTTP协议，同时对客户端消耗少，（但是IE不支持see协议）

websocket 是双工通道，可以双向通信，功能强大，SEE单向通道，只能是服务端对客户端通信
2.webSocket是一个新的协议，需要服务端支持，SEE是建立在HTTP上的，现有的服务器就能支持。
3.SEE支持断线重连，webSocket则需要额外部署。

webSocket和SEE分别使用什么场景？

SSE来说轻量级的，webSocket重
1.对于需要服务端单方面的推送而不需要服务端反馈的：比如消息推送，大屏实时数据，就可以使用SEE，没必要webSocket
2.对于双工websocket来说：就类似聊天功能，这种需要服务端主动向客户端推送，同时客户端也要向服务端推送信息。