轮询以及webSocket与socket.io原理
概述:
首先,我们知道,起初的http
协议只是为了能够进行通信而被创造出来(也就是请求-响应的过程)。并没有双向通信这一说,后面随着历史业务的需求,人们使用轮询http来解决双向通信也就是使用xhr
或者jsonp
的方法进行发送请求到服务端并且进行回调获取服务端数据
通信的三种传输模式:
单工通讯:既只能客户端向服务端发送数据或者服务端向客户端发送数据(如广播,电视之类的,他可以给你传播信息,你却不能给他回应)
半双工单向通讯:客户端可以向服务端发送数据,服务端也可以向客户端发送数据,但是不能同时,只能这一端发送完后另一端才可以进行响应(对讲机,他讲一句你讲一句,但是不能同时讲)
全双工通讯:客户端可以向服务端发送数据,服务端也可以向客户端发送数据,可以同时进行(电话,qq聊天等等,可以同时讲或者发送消息)
1:轮询:隔一段时间进行一次查询或者询问
轮询分为长轮询和短轮询,长轮询是基于短轮询的一个优化结果。
短轮询:
通过客户端定期轮询来询问服务端是否有新的信息产生,如果有则返回,没有就不响应,
缺点:也是显而易见,轮询间隔大了则信息不够实时,轮询间隔过小又会消耗过多的流量,增加服务器的负担。
长轮询:
是需要服务端进行更改来进行支持,客户端向服务端发送请求时,如果此时服务端没有新的信息产生,并不立刻返回,而是Hold
住一段时间等有新的信息或者超时再返回,客户端收到服务器的应答后继续轮询。可以看到长轮询比短轮询可以减少大量无用的请求,并且客户端接收取新消息也会实时不少。减少http
请求对性能的优化是很有利的,所以他是短轮询上的一个优化
缺点:终归来讲还是一个http
请求,只是进行了变化而已,而且如果客户端不请求,服务端有数据的话,也会一直累积在那,不能实现实时的双向通信
此时的webSocket
也就应需而生了
2:webSocket协议原理
webSocket
也是基于Tcp
协议传输层连接的,跟http
相同处于协议应用层,而且它还是基于http的握手的,只是是握手的时候会传输特定的数据让协议升级成为webSocket
协议
与http与之不同的是webSocket是一个持久化协议,而http协议是一个非持久化协议,也就是http他请求然后响应就结束了,而webSocket会一直保持连接而且一直传输数据,直到你将连接断开
websocket连接过程:
客户端发送http请求:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: Y3JJCMbDL1IDUCH9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 20
其中的这俩段代码就是将http
升级为webSocket
的关键
Upgrade: websocket
Connection: Upgrade
而后面的三行代码则是一些验证信息
Sec-WebSocket-Key
:浏览器随机生成,用于给服务端使用,如果服务端支持webSocket,服务端会对该数据进行一些处理然后返回给客户端进行验证Sec-WebSocket-Protocol
:是一个列表,列表中列出客户端所支持的协议Sec-WebSocket-Version
:指定版本
然后服务端就会返回
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
服务端返回这俩段代码就说明升级成功
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept
:对Sec-WebSocket-Key进行处理后的数据。用于证明他是支持升级后的协议的,验证成功Sec-WebSocket-Protocol
:服务端最终选定的协议
做完这些以后这次连接之后就都是webSocket
连接了,既进入到全双工通讯
3:socket.io原理
介绍
首先,socket.io是一个库,一个基于engine.io
协议(封装了webSocket协议)的库,在协议上创建了Engine.io
引擎,socket.io则是该引擎的应用层框架
它相对比原生webSocket的一些特性
长轮询回退
:如果无法建立webSocket连接,socket.io将会退回到http长轮询进行连接,这也是为了兼容一些特别老的项目和极少数不支持的浏览器(现如今)自动连接
:在一些情况下,连接某一方有可能在不知情的情况下断开,它有一个心跳机制,可以定时去监测是否连接,只要不是客户端主动关闭连接,socket.io就会在连接出错后不断重试以建立连接,服务端数据会进行自动缓冲,直到再次连接,为了防止断开时间过长,缓冲时间过长,可以利用使用Socket 实例的connected属性进行处理,或者使用Volatile事件,使服务端丢弃原来的缓冲,只返回最新的数据(官网有该方法,在此就不多描述)多路复用
:Socket.io允许你在单个共享连接上创建多个namespace,这些namespace拥有单独的通信通道(room),也可设置单独的权限验证,但是可以共享原来的底层连接;例如,如果您想创建一个只有授权用户才能加入的管理员
频道支持Room功能
:room是在namespace下的,举个例子:namespace如同一片地区,room是这片地区中个房子,socket则是房子中的人,namespace是可以在别的namespace中通信的,但是room只能在该spacename下的room之间进行通信,socket也只能收到该namespace的广播
socket.io连接过程:
同样客户端发起http请求,并带有
Upgrade: websocket
Connection: Upgrade
服务端返回
"sid":"ab4507c4-d947-4deb-92e4-8a9e34a9f0b2"
"upgrades":["websocket"]
"pingInterval":25000
"pingTimeout":60000}
sid
:sid 是本次会话的ID,因为一次连接包含了多个请求,sid 的作用就相当于 SESSION ID。也是客户端的标识pingInterval
:ping的间隔时长pingTimeout
:判断连接超时的时长
当客户端收到响应之后,scoket.io会根据当前客户端环境是否支持Websocket。如果支持,则建立一个websocket连接,否则退回到长轮询
进行双向数据通信。
engine.io协议原理
engine.io的数据分为Packet和Payload,其中 Packet是数据包,有6种类型:
0. open
:从服务端发出,标识一个新的传输方式已经打开。
close
:请求关闭这条传输连接,但是它本身并不关闭这个连接。ping
:客户端周期性发送ping,服务端响应pong。pong
:服务端发送。message
:真实数据upgrade
:在转换(transport)前,engine.io会发送探测包测试新的transport(如websocket)是否可用,如果OK,则客户端会发送一个upgrade消息给服务端,服务端关闭老的transport然后切换到新的transport。用于升级协议noop
:空操作数据包,客户端收到noop消息会将之前等待暂停的轮询暂停,用于在接收到一个新的websocket强制一个新的轮询周期。
4:总结
socket.io可以说是一个很好的工具,无论是用做聊天或者是其他实时的数据通信,在使用时也遇到过一些问题,后面都慢慢解决了,本文主讲理论如需了解基本应用推荐:
webSocket的基本使用与socket.io库使用