websocket

一、什么是websocket

• WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。
• WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。
• Websocket是一个持久化的协议。
• 在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

重点：1.全双工，客户端与服务端可以同时相互通信，就如同打电话一样，两边可以同时说话。
2.允许服务端主动向客户端发数据，在以往的通信中是客户端向服务端发送请求，服务端再回复给客户端，一切起源只能是客户端的request，服务端无法主动发送信息给客户端；在websocket中，则可以服务端主动给客户端发送信息。
3.持久性，当服务端跟客户端通信连接成功(即建立起一个管道),这个管道将会一直存在，随时可以传送数据，无需再request。

二、websocket的原理

websocket约定了一个通信的规范，通过一个握手的机制，客户端和服务器之间能建立一个类似tcp的连接，从而方便它们之间的通信
在websocket出现之前，web交互一般是基于http协议的短连接或者长连接
websocket是一种全新的协议，不属于http无状态协议，协议名为"ws"

三、websocket  与 http

 

 相同点：

1. 都是基于tcp的，都是可靠性传输协议
2. 都是应用层协议

不同点：

1. WebSocket是双向通信协议，模拟Socket协议，可以双向发送或接受信息
2. HTTP是单向的
3. WebSocket是需要浏览器和服务器握手进行建立连接的
4. 而http是浏览器发起向服务器的连接，服务器预先并不知道这个连接

 联系：

• WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的

总结（总体过程）：

首先，客户端发起http请求，经过3次握手后，建立起TCP连接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；
然后，服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据；
最后，客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信。

四、websocket解决的问题

1.http存在的问题
http是一种无状态协议，每当一次会话完成后，服务端都不知道下一次的客户端是谁，需要每次知道对方是谁，才进行相应的响应，因此本身对于实时通讯就是一种极大的障碍
http协议采用一次请求，一次响应，每次请求和响应就携带有大量的header头，对于实时通讯来说，解析请求头也是需要一定的时间，因此，效率也更低下
最重要的是，需要客户端主动发，服务端被动发，也就是一次请求，一次响应，不能实现主动发送

2.long poll(长轮询)
对于以上情况就出现了http解决的第一个方法——长轮询
基于http的特性，简单点说，就是客户端发起长轮询，如果服务端的数据没有发生变更，会 hold 住请求，直到服务端的数据发生变化，或者等待一定时间超时才会返回。返回后，客户端又会立即再次发起下一次长轮询
优点是解决了http不能实时更新的弊端，因为这个时间很短，发起请求即处理请求返回响应，实现了“伪·长连接”
张三取快递的例子，张三今天一定要取到快递，他就一直站在快递点，等待快递一到，立马取走

从例子上来看有个问题：

假如有好多人一起在快递站等快递，那么这个地方是否足够大，（抽象解释：需要有很高的并发，同时有很多请求等待在这里）
总的来看：
推送延迟。服务端数据发生变更后，长轮询结束，立刻返回响应给客户端。

服务端压力。长轮询的间隔期一般很长，例如 30s、60s，并且服务端 hold 住连接不会消耗太多服务端资源。

3.Ajax轮询
基于http的特性，简单点说，就是规定每隔一段时间就由客户端发起一次请求，查询有没有新消息，如果有，就返回，如果没有等待相同的时间间隔再次询问
优点是解决了http不能实时更新的弊端，因为这个时间很短，发起请求即处理请求返回响应，把这个过程放大n倍，本质上还是request = response
举个形象的例子（假设张三今天有个快递快到了，但是张三忍耐不住，就每隔十分钟给快递员或者快递站打电话，询问快递到了没，每次快递员就说还没到，等到下午张三的快递到了，but，快递员不知道哪个电话是张三的，（可不是只有张三打电话，还有李四，王五），所以只能等张三打电话，才能通知他，你的快递到了）

从例子上来看有两个问题：

假如说，张三打电话的时间间隔为10分钟，当他收到快递前最后一次打电话，快递员说没到，他刚挂掉电话，快递入库了（就是到了），那么等下一次时间到了，张三打电话知道快递到了，那么这样的通讯算不算实时通讯？很显然，不算，中间有十分钟的时间差，还不算给快递员打电话的等待时间（抽象的解释：每次request的请求时间间隔等同于十分钟，请求解析相当于等待）
假如说张三所在的小区每天要收很多快递，每个人都采取主动给快递员打电话的方式，那么快递员需要以多快的速度接到，其他人打电话占线也是问题（抽象解释：请求过多，服务端响应也会变慢）
总的来看，Ajax轮询存在的问题：
推送延迟。

服务端压力。配置一般不会发生变化，频繁的轮询会给服务端造成很大的压力。

推送延迟和服务端压力无法中和。降低轮询的间隔，延迟降低，压力增加；增加轮询的间隔，压力降低，延迟增高
 

4.websocket的改进
一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。在客户端断开WebSocket连接或Server端中断连接前，不需要客户端和服务端重新发起连接请求。在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实现了“真·长链接”，实时性优势明显。
 

EIO=3是socket.io中engine.io子系统的版本号

http://socket.io 底层是 http://engine.io，这个库实现了跨平台的双向通信。
http://engine.io 使用了 WebSocket 和 XMLHttprequest（或JSONP） 封装了一套自己的 Socket 协议（暂时叫 EIO Socket），在低版本浏览器里面使用长轮询替代 WebSocket。一个完整的 EIO Socket 包括多个 XHR 和 WebSocket 连接.

前端：

EIO Socket 通过一个 XHR (XMLHttprequest) 握手。前端发送一个 XHR，告诉服务端我要开始 XHR 长轮询了。后端返回的数据里面包括一个 open 标志(数字 0 表示), 以及一个 sid 和 upgrades 字段。
sid 是本次 EIO Socket 的会话 ID，因为一次 EIO Socket 包含了多个请求，而后端又会同时连接多个 EIO Socket，sid 的作用就相当于 SESSION ID。
另一个字段 upgrades，正常情况下是 ['websocket']，表示可以把连接方式从长轮询升级到 WebSocket.

前端在发送第一个 XHR 的时候就开始了 XHR 长轮询，这个时候如果有收发数据的需求，是通过长轮询实现的。所谓长轮询，是指前端发送一个 request，服务端会等到有数据需要返回时再 response. 前端收到 response 后马上发送下一次 request。这样就可以实现双向通信。

前端收到握手的 upgrades 后，EIO 会检测浏览器是否支持 WebSocket，如果支持，就会启动一个 WebSocket 连接，然后通过这个 WebSocket 往服务器发一条内容为 probe, 类型为 ping 的数据。如果这时服务器返回了内容为 probe, 类型为 pong 的数据，前端就会把前面建立的 HTTP 长轮询停掉，后面只使用 WebSocket 通道进行收发数据。
EIO Socket 生命周期内，会间隔一段时间 ping - pong 一次，用来测试网络是否正常。

 

这是 WebSocket 帧的结构，绿色是发送，白色是接收。前面的数字是数据包类型，2 是 ping, 3 是 pong, 4 是 message.

http://socket.io 在 http://engine.io 的基础上做了一些封装，比如 http://socket.io 里面这样的代码：

io.emit('add user', 'm')

在 engine.io 里面是这样：

eio.send('message', '2["add user","m"]') // 2 是 socket.io 定义的包类型

再例如，engine.io-client 需要在 open 之后才能 send，而 http://socket.io 就不需要，open 之前 emit 的数据会在 open 之后再发出。

另外 http://socket.io 还提供了 namespace，复用, 自动重连等特性。

服务端：

服务端使用 ws 库实现 WebSocket 协议。
http://socket.io 服务启动时，会先启动一个 ws 服务。 http://socket.io 会监听 HTTP 服务器的 upgrade 和 request 事件。
当 upgrade 事件触发时，说明可能是 WebSocket 握手，先简单校验下，然后把请求交给 ws 服务进行处理，拿到 WebSocket 对象。
当 request 事件触发时，根据 url 路径判断是不是 http://socket.io 的 XHR 请求，拿到 res 和 res 对象。
这样就可以正确接收和返回客户端数据了，具体处理过程和前端部分是对应的。