Socket.io提供了基于事件的实时双向通讯
Browser和WebServer间的实时数据传输是一个很重要的需求,但最早只能通过AJAX轮询方式实现。在WebSocket标准没有推出之前,AJAX轮询是一种可行的方案。
AJAX轮询原理是设置定时器,定时通过AJAX同步服务端数据。这种方式存在延时且对服务端造成很大负载。直至2011年,IETF才标准化WebSocket - 一种基于TCP套接字进行收发数据的协议。
Socket.io将数据传输部分独立出来形成engine.io,engine.io对WebSocket和AJAX轮询进行了封装,形成了一套API,屏蔽了细节差异和兼容性问题,实现了跨浏览器/跨设备进行双向数据通信。
WebSocket 协议
WebSocket是HTML5新增的一种通信协议,其特点是服务端可以主动向客户端推送信息,客户端也可以主动向服务端发送信息,是真正的双向平等对话,属于服务器推送技术的一种。
在WebSocket API中,浏览器和服务器只需要做一个握手的动作,然后浏览器和服务端之间就形成了一条快速通道,两者之间就直接可以数据相互传送,带来的好处是
- 相互沟通的
Header
很小,大概只有2Bytes。 - 服务器不再被动的接收到浏览器的请求之后才返回数据,而是在有新数据时就主动推送给浏览器。
为了建立一个WebSocket连接,浏览器首先要向服务器发起一个HTTP请求,这个请求和通常的HTTP请求不同,包含了一些附加头信息,其中附加头信息Upgrade: WebSocket
表明这是一个申请协议升级的HTTP请求。服务端解析这些头信息,然后产生应答信息返回给客户端,客户端和服务端的WebSocket连接就建立起来了。双方就可以通过这个连接通道自由的传递信息,并且这个连接会持续直到客户端或者服务端的某一方主动关闭连接。
为什么要使用WebSocket呢?
Browser已经支持HTTP协议,为什么还要开发一种新的WebSocket协议呢?
我们知道HTTP协议是一种单向的网络协议,在建立连接后,仅允许Browser/UserAgent向WebServer发出请求资源后,WebServer才能返回对应的数据,而WebServer不能主动的推送数据给Browser/UserAgent。
最初这么设计HTTP协议的原因是,假设WebServer能主动的推送数据给Browser/UserAgent,那么Browser/UserAgent就太容易受到攻击了,一些广告商也会主动把广告在不经意间强行的传输给客户端,这不能不说是一个灾难。那么单向的HTTP协议给Web应用开发带哪些问题呢?
现在假设我们要开发一个基于Web的应用去获取当前WebServer的实时数据。例如股票实时行情、火车票剩余票数等。这就需要Browser/UserAgent与WebServer之间反复进行HTTP通信,Browser/UserAgent不断的发送请求去获取当前的实时数据。
常见的方式
- Polling
Polling轮询是通过Browser/UserAgent定时向WebServer发送HTTP请求,WebServer收到请求后把最新的数据发回给Browser/UserAgent,Browser/UserAgent得到数据后将其显示,然后再定期重复此过程。
虽然这样可以满足需求,但仍存在问题,例如某段时间内WebServer没有更新的数据,但Browser/UserAgent仍然会定时发送请求过来询问,WebServer可以把以前的老数据再传送过去,Browser/UserAgent把这些没有变化的数据再显示出来。这样既浪费网络带宽,有浪费CPU利用率。
如果说把Browser/UserAgent发送请求的周期调大一些,就可以缓解这个问题,但如果WebServer的数据更新很快时,这样又不能保证Web应用获取数据的实时性。
- LongPolling
LongPolling是对Polling的一种改进。
Browser/UserAgent发送HTTP请求到WebServer,此时WebServer可以做2件事情:
如果WebServer有新的数据需要传送,就立即把数据发回给Browser/UserAgent,Browser/UserAgent收到数据后,立即再发送HTTP请求给WebServer。
如果WebServer没有新数据需要传送,这里与Polling的方式不同的是,WebServer不是立即发送回应给Browser/UserAgent,而是将这个请求保持住,等待有新的数据来到,再去响应这个请求。当然,如果WebServer的数据长期没有更新,一段时间后,这个HTTP请求就会超时,Browser/UserAgent收到超时信息后,在立即发送一个新的HTTP请求给服务器,然后依次循环这个过程。
LongPolling的方式虽然在某种程度上减少了网络带宽和CPU利用率等问题,但仍存在缺陷。
例如WebServer的数据更新速度较快,WebServer在传送一个数据包给Browser/UserAgent后必须等待Browser的下一个HTTP请求到来,才能传递第二个更新的数据包给Browser。这样的话,Browser显示实时数据最快的时间为2 xRTT(往返时间)。另外在网络拥堵的情况下,这个应该是不能让用户接受的。另外,由于HTTP数据包的头部数据量很大(通常有400多个字节),但真正被服务器需要的数据却很少(有时只有10个字节左右),这样的数据包在网络上周期性传输,难免对网络带宽是一种浪费。
综上所述,要是在Browser有一种新的网路一些,能支持客户端和服务端的双向通信,而且协议的头部又不那么庞大就very nice了。WebSocket正是肩负这样的使命登上了Web的舞台。
WebSocket 原理
WebSocket是一种双向通信协议,它建立在TCP之上,同HTTP一样通过TCP来传输数据,但与HTTP最大不同的是:
WebSocket是一种双向通信协议,在建立连接后,WebSocket服务器和Browser/UserAgent都能主动的向对象发送或接收数据,就像Socket一样,不同的是WebSocket是一种建立在Web基础上的简单模拟Socket的协议。
WebSocket需要通过握手连接,类似TCP也需要客户端和服务端进行握手连接,连接成功后才能相互通信。
简单说明下WebSocket握手的过程
当Web应用端调用new WebSocket(url)
接口时,Browser就开始了与地址为URL的WebServer建立握手连接的过程。
Browser与WebSocket服务器通过TCP三次握手建立连接,如果这个建立连接失败,那么后面的过程就不会执行,Web应用将收到错误消息通知。
在TCP建立连接成功后,Browser/UserAgent通过HTTP协议传送WebSocket支持的版本号、协议的字版本号、原始地址、主机地址等一系列字段给服务端。
WebSocket服务器收到Browser/UserAgent发送来的握手请求后,如果数据包数据和格式正确,客户端和服务端的协议版本匹配等,就接受本次握手连接,并给出对应的数据回复,同样回复的数据包也是采用HTTP协议传输。
Browser收到服务器回复的数据包后,如果数据包内容、格式都没有问题的话,就表示本次连接成功,触发
onopen
消息,此时Web开发者就可以在此时通过send
接口向服务器发送数据。否则,握手连接失败,Web应用会收到onerror
消息,并且能知道连接失败的原因。
WebSocket与TCP、HTTP的关系
WebSocket与HTTP协议一样都是基于TCP的,所以它们都是可靠的协议,Web开发者调用的WebSocket
的send
函数在Browser的实现中最终都是通过TCP的系统接口进行传输的。
WebSocket和HTTP协议样都属于应用层协议,那么它们之间有没有什么关系呢?
答案是肯定的,WebSocket在建立握手连接时,数据是通过HTTP协议传输的。但在建立连接之后,真正的数据传输阶段是不需要HTTP参与的。
WebSocket Server
如果要搭建一个WebServer,我们会有很多选择,市场上也有很多成熟的产品供我们是使用。例如开源的Apache,安装配置后即可工作。但如果想要搭建一个WebSocket服务器就没有那么轻松,因为WebSocket是一种新的通信协议,目前还是草案,没有成为标准,市场上也没有成熟的WebSocket服务器或Library实现WebSocket协议,我们必须自己手动编码去解析和组装WebSocket的数据包。要完成一个WebSocket服务器,估计所有的人都想放弃,不过市场上有几款比较好的开源Library可供使用。例如PyWebSocket、WebSocket-Node、LibWebSockets等,这些Library已经实现了WebSocket数据包的封装和解析,我们可以调用这些接口,这在很大程度上减少了我们的工作量。
Socket.io
socket.io是一个跨浏览器支持WebSocket的实时通讯的JS。
http://socket.io/docs/
由于HTTP是无状态的协议,要实现即时通讯非常困难。因为当对方发送一条消息时,服务器并不知道当前有哪些用户等着接收消息,当前实现即时通讯功能最为普遍的方式就是轮询机制。即客户端定期发起一个请求,看看有没有人发送消息到服务器,如果有服务端就将消息发给客户端。这种做法的缺点显而易见,那么多的请求将消耗大量资源,大量的请求其实是浪费的。
现在,我们有了WebSocket,它是HTML5的新API。WebSocket连接本质上就是建立一个TCP连接,WebSocket会通过HTTP请求建立,建立后的WebSocket会在客户端和服务端建立一个持久的连接,直到有一方主动关闭该连接。所以,现在服务器就知道有哪些用户正在连接了,这样通讯就变得相对容易了。
Socket.io支持及时、双向、基于事件的交流,可在不同平台、浏览器、设备上工作,可靠性和速度稳定。最典型的应用场景如:
- 实时分析:将数据推送到客户端,客户端表现为实时计数器、图表、日志客户。
- 实时通讯:聊天应用
- 二进制流传输:socket.io支持任何形式的二进制文件传输,例如图片、视频、音频等。
- 文档合并:允许多个用户同时编辑一个文档,并能够看到每个用户做出的修改。
Socket.io实际上是WebSocket的父集,Socket.io封装了WebSocket和轮询等方法,会根据情况选择方法来进行通讯。
Node.js提供了高效的服务端运行环境,但由于Browser对HTML5的支持不一,为了兼容所有浏览器,提供实时的用户体验,并为开发者提供客户端与服务端一致的编程体验,于是Socket.io诞生了。
# npm安装socket.op
$ npm install --save socket.io
Socket.io将WebSocket和Polling机制以及其它的实时通信方式封装成通用的接口,并在服务端实现了这些实时机制相应代码。这就是说,WebSocket仅仅是Socket.io实现实时通信的一个子集,那么Socket.io都实现了Polling中那些通信机制呢?
- Adobe Flash Socket
大部分PC浏览器都支持的Socket模式,不过是通过第三方嵌入到浏览器,不在W3C规范内,可能将逐步被淘汰。况且,大部分手机浏览器并不支持此种模式。 - AJAX Long Polling
定时向服务端发送请求,缺点是给服务端带来压力并出现信息更新不及时的现象。 - AJAX multipart streaming
在XMLHttpRequest对象上使用某些浏览器支持的multi-part标志,AJAX请求被发送给服务端并保持打开状态(挂起状态),每次需要向客户端发送信息,就寻找一个挂起的HTTP请求响应给客户端,并且所有的响应都会通过统一连接来写入。 - Forever Iframem
永存的Iframe设计了一个置于页面中隐藏的iframe标签,该标签的src属性指向返回服务端时间的Servlet路径。每次在事件到达时,Servlet写入并刷新一个新的Script标签,该标签内部带有JS代码,iframe的内容被附加上script标签,标签中的内容就会得到执行。这种方式的缺点是接收数据都是由浏览器通过HTML标签来处理的,因此无法知道连接何时在哪一端被断开,而且iframe标签在浏览器中将被逐步取消。 - JSONP Polling
JSONP轮询基本与HTTP轮询一样,不同之处则是JSONP可发出跨域请求。
Socket.io 基本应用
socket.io提供了基于事件的实时双向通讯,它同时提供了服务端和客户端的API。
服务端
服务端socket.io必须绑定一个http.Server
实例,因为WebSocket协议是构建在HTTP协议之上的,所以在创建WebSocket服务时需调用HTTP模块并调用其下createServer()
方法,将生成的server作为参数传入socket.io。
var httpServer = require('http').createServer();
var io = require('socket.io')(httpServer);
httpServer.listen(3000);
绑定http.Server
可使用隐式绑定和显式绑定
- 隐式绑定
socket.io内部实例化并监听http.Server
,通过实例化时传入端口或者在实例化后调用listen
或attach
函数进行隐式绑定。
// 实例化时传入端口
require('socket.io')(3000)
// 通过listen或attach函数绑定
let io = require('socket.io')
io.listen(3000);
// io.attach(3000);
- 显式绑定
// 实例化时绑定
let httpServer = require('http').Server();
let io = require('socket.io')(httpServer);
httpServer.listen(3000);
//通过listen或attach绑定
let httpServer = require('http').Server();
let io = require('socket.io')();
io.listen(httpServer);
// io.attach(httpServer);
httpServer.listen(3000);
Express框架中使用
let app = require('express');
let httpServer= require('http').Server(app);
let io = require('socket.io')(httpServer);
app.listen(3000);
KOA框架中使用
let app = require('koa')();
let httpServer = require('http').Server(app.callback());
let io = require('socket.io')(httpServer);
app.listen(3000);
建立连接
当服务端和客户端连接成功时,服务端会监听到connection
和connect
事件,客户端会监听到connect
事件,断开连接时服务端对应到客户端的socket与客户端均会监听到disconcect
事件。
/*客户端*/
/*服务端*/
// 服务端绑定HTTP服务器实例
let httpServer = require('http').Server();
let io = require('socket.io')(httpServer);
httpServer.listen(3000);
// 服务端监听连接状态:io的connection事件表示客户端与服务端成功建立连接,它接收一个回调函数,回调函数会接收一个socket参数。
io.on('connection', (socket)=>{
console.log('client connect server, ok!');
// io.emit()方法用于向服务端发送消息,参数1表示自定义的数据名,参数2表示需要配合事件传入的参数
io.emit('server message', {msg:'client connect server success'});
// socket.broadcast.emit()表示向除了自己以外的客户端发送消息
socket.broadcast.emit('server message', {msg:'broadcast'});
// 监听断开连接状态:socket的disconnect事件表示客户端与服务端断开连接
socket.on('disconnect', ()=>{
console.log('connect disconnect');
});
// 与客户端对应的接收指定的消息
socket.on('client message', (data)=>{
cosnole.log(data);// hi server
});
socket.disconnect();
});
传输数据
服务端和客户端的socket是一个关联的EventEmitter
对象,客户端socket派发的事件可以通过被服务端的socket接收,服务端socket派发的事件也可以被客户端接收。基于这种机制,可以实现双向交流。
# 模拟:客户端不断发送随机数,当随机数大于0.95时,服务端延迟1s后向客户端发送警告以及警告次数。
/*客户端*/
/*服务端*/
let httpServer = require('http').Server();
let io = require('socket.io')(httpServer);
httpServer.listen(3000);
io.on('connection', socket=>{
socket.on('random', value=>{
console.log(value);
if(value>0.95){
if(typeof socket.warnign==='undefined'){
socket.warning = 0;// socket对象可用来存储状态和自定义数据
}
setTimeout(()=>{
socket.emit('warn', ++socket.warning);
}, 1000);
}
});
});
客户端
运行环境:NodeJS
API https://www.w3cschool.cn/socket/socket-k49j2eia.html