1WhyWebSocket?
WebSocket[1]是一种在TCP连接上进行全双工网络通信的协议，之所以在有了Http协议之后，仍旧诞生了WebSocket的原因在于Http的缺陷：通信只能由客户端发起。
举例来说，我们想象一个在线客服聊天场景，任何的数据传输都有可能由双方中的任意一方发起。HTTP1.x协议做不到服务器在最快时间将客户的上一句话发给客服，以及将客服的回复立刻向客户推送，每次获取对方的最新消息，都必须由我方发起一个HTTP请求。这使得HTTP在很多场景的应用上大打折扣，WebSocket因此应运而生。
1.1满足推送场景的几种技术方案
在WebSocket出现之前，在Web或者C/S架构上，不论是实现服务端向客户端推送实时消息或者实现双向通信，不得不基于以下几种方案：
Polling(轮询)
浏览器定期发送HTTP请求并接收响应，作为服务器推送。如果消息传递的确切时间已知，这是一个尚可的解决方案，每次轮询都可以获取到服务器最新的数据信息。
然而，实际应用中，实时数据的什么时候需要传输通常是不可预测的，这必然造成许多不必要的请求，因此，在低频率消息的情况下，许多连接被不必要地打开和关闭，这也就需要不停地建立连接并传输较长的Header信息，在不断请求的过程中这将产生资源的浪费。如果减少轮询频率，又会造成消息推送的不及时，轮询间隔很难把控。
Long-Polling(长轮询)
为了减少无效的连接次数，最简单方便的优化，就是拉长单个HTTP连接的保持时间。
长轮询是让服务器在接收到浏览器所送出HTTP请求后，服务器等待一段时间，若在这段时间里面服务器有新的消息，服务器会把最新的消息传回给浏览器，如果等待的时间到了之后也没有新的消息的话，服务器也会送一个回应给浏览器，告知浏览器消息没有更新。
长轮询可以在低频通信的情况下减少产生原本轮询造成网络带宽浪费的情况，但在实际应用中，频率往往是不可预测的，因此长轮询实现的依然是伪即时。此外，开发一套双向通信应用如在线客服聊天,服务端通过请求接受消息和客户端轮询必定是两套机制，处理收/发消息的机制是割裂的，这和我们对一个在线客服聊天的直观理解有所不同。
iframe流（streaming）或者Flashsocket等插件内嵌长连接
iframe流方式是在页面中插入一个隐藏的iframe，利用其src属性在服务器和客户端之间创建一条长连接，服务器向iframe传输数据，来实时更新页面。客户端只请求一次，然而服务端却是源源不断向客户端发送数据。Flashsocket则是使用了flash提供的一套协议，但客户端必须安装Flash插件（被淘汰的技术），无法自动穿越防火墙。这些方案虽然在历史上广泛使用，但并不属于主流方案，部分浏览器对其的兼容较差，例如firefox使用iframe+streaming的实现方式，浏览器页面会一直显示loading，最新版本的Chrome也已经不再支持flash。
SSE(Server-sentEvents)
SSE（Server-sentEvents）是WebSocket的一种轻量代替方案，使用HTTP协议。Server-sentEvents规范是HTML5通讯协议是基于纯文本的简单协议。服务器端的响应的内容类型是“text/event-stream”。响应文本的内容可以看成是一个事件流，由不同的事件所组成。每个事件由类型和数据两部分组成，同时每个事件可以有一个可选的标识符。SSE是单向通道，只能服务器向客户端发送消息，如果客户端需要向服务器发送消息，则需要一个新的HTTP请求。也就是说，SSE是只解决了服务器实时推送，但未解决客户端发起的通信。
1.2WebSocket的优势
可以看出以上场景的一些特点，websocket拥有以下优势，更好得切合了这些场景。
支持双向通信很强的实时性更好的二进制支持，对传输的内容格式不作限制。这就使得发送内容不受协议本身限制。较少的控制开销。连接创建后，ws客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有2~10字节（取决于数据包长度），客户端到服务端的的话，需要加上额外的4字节的掩码。而HTTP协议每次通信都需要携带完整的头部。支持扩展。ws协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议。（比如支持自定义压缩算法等）
总结，几种实时获取服务端的技术比较
/p>PollingLong-Pollingiframe流/FlashWebSocketSSE通讯方式HTTPHTTP基于TCP的长连接通讯基于TCP的长连接通讯HTTP触发方式轮询轮询事件事件事件优点简单，兼容性好相对短轮询资源占用少实现真正的即时通信，而不是伪即时。全双工通讯，性能好，安全(最新协议版本)，扩展性实现简单,占用很少的资源实现推送缺点资源占用高资源占用高兼容性差缺乏通用的子协议，传输资源要进行二次解析，一定的开发门槛低版本浏览器不支持(Safari10.1+,Edge14+,IE不支持)常见的适用范围B/S服务中的推送B/S服务中的推送B/S或者内嵌Flash的任何应用比较通用仅推送1.3WebSocket适用场景
不只是在线客服聊天，决定手头的工作是否需要使用WebSocket技术的方法可以主要可以参考以下两点：
1.你的应用提供多方互相且频繁的数据传输吗？
2.你的应用是需要实时展示服务器端经常变动的数据吗？
类似于以下场景：
社交/订阅
