websocket 是长连接，受网络限制比较大，需要处理好重连，比如用户进电梯或电信用户打个电话网断了，这时候就需要重连，如果 ws 一直重连不上，有些较复杂的业务方会不愿意的，是不是还要搞个 http 降级？

所以大部分不重要的业务，使用 ws 不如使用 http 轮训来的简单、实在。

ws 长连接的用户收到消息是个 push 操作，http 轮训用户收消息是 pull 操作，push 都存在单生产推多消费，为广播模型，怎么处理好连接，保障每个消费推且只推一次，很多程序员这个问题不一定能够解决。
pull 就不一样了，消费方想要你就来生产方拉一下，拉几次，消息就准确的送达几次，不存在多消费和连接处理的问题，缺点当然就是消息推送的不及时，优点非常明显，简单易实现。

websocket 当然也不是楼主说的没有用，企业内部业务系统之间有时候用 http 协议，又想要消息及时推送，上个 mq 太粗暴，用 grpc 这些支持双向流的 rpc 协议太复杂，此时 ws 就非常好使了。

 

websocket 很多坑，如果只是单页面还好，涉及到多页面，定时推送，复杂的推送，就非常容易出问题了，不管是前端，还是服务端都会遇到很多很多问题

一般有实时数据要求的会考虑 websocket 

 

一、websocket与http

WebSocket是HTML5中的协议，支持持久连接；而Http协议不支持持久连接。

首先HTMl5指的是一系列新的API,或者说新规范，新技术。

WebSocket是HTML5中新协议、新API.跟HTTP协议基本没有关系。

Http协议本身只有1.0和1.1，也就是所谓的Keep-alive，把多个Http请求合并为一个。

二、Websocket是什么样的协议，具体有什么优点

首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说

HTTP的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次HTTP请求就结束了。

在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。

三、Websocket的作用

（1）ajax轮询

ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。

（2）long poll（长轮询）

long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端（对于PHP有最大执行时间，建议没消息，执行到一定时间也返回）。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。

从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。

何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。

ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）

（3）WebSocket

Websocket解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。解决了上面同步有延迟的问题。

解决服务器上消耗资源的问题：其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（php等）来处理。简单地说，我们有一个非常快速的 接线员（Nginx） ，他负责把问题转交给相应的 客服（Handler） 。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。

由于Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。

目前唯一的问题是：不兼容低版本的IE

它对开发者要求高了许多。

对前端开发者，往往要具备数据驱动使用javascript的能力，且需要维持住ws连接（否则消息无法推送）；

对后端开发者而言，难度增大了很多，一是长连接需要后端处理业务的代码更稳定（不要随便把进程和框架都crash掉），

二是推送消息相对复杂一些，

三是成熟的http生态下有大量的组件可以复用，websocket则太新了一点。

1、传统的http请求，其并发能力都是依赖同时发起多个TCP连接访问服务器实现的(因此并发数受限于浏览器允许的并发连接数)，而websocket则允许我们在一条ws连接上同时并发多个请求，即在A请求发出后A响应还未到达，就可以继续发出B请求。由于TCP的慢启动特性（新连接速度上来是需要时间的），以及连接本身的握手损耗，都使得websocket协议的这一特性有很大的效率提升。

2、http协议的头部太大，且每个请求携带的几百上千字节的头部大部分是重复的，很多时候可能响应都远没有请求中的header空间大。如此多无效的内容传递是因为无法利用上一条请求内容，websocket则因为复用长连接而没有这一问题。

3、当需要实现客户端刷新消息时，传统方案往往通过定时ajax请求实现，实际上对多数用户多数时间下这些请求都是无意义了，除了浪费资源。

不兼容低版本的IE