一 轮询:java
polling:client按设置好的时间间隔主动访问server,有可能server返回有用数据,有可能server无有用数据返回,但都是一个创建链接-request-response-关闭链接的过程。web
二 web的推:算法
1 cometspring
1)long pollingchrome
client访问server,若server有数据返回,则返回,关闭链接,client继续发请求;若server没有数据返回,链接保持,等待直到server有数据返回,关闭链接,client继续发请求。创建链接-request-(wait)-response-关闭链接。小程序
2) Iframe浏览器
iframe 是很早就存在的一种 HTML 标记, 经过在 HTML 页面里嵌入一个隐蔵帧,而后将这个隐蔵帧的 SRC 属性设为对一个长链接的请求,服务器端就能源源不断地往客户端输入数据tomcat
2 websocket服务器
websocket是一种协议,本质上和http,tcp同样。协议是用来讲明数据是如何传输的。它的url前缀是ws:// 或者wss://,后者是加密的websocket。它的url诸如这样:ws://10.16.15.64:3201/websocket
客户端和服务端进行websocket交互的方式也有人理解为“HTTP握手+TCP数据传输”的方式。
HTTP握手+TCP数据传输
握手和传输的整个流程是这样的:
浏览器(支持Websocket的浏览器)像HTTP同样,发起一个请求,而后等待服务端的响应
服务器返回握手响应,告诉浏览器请将后续的数据按照websocket制定的数据格式传过来
浏览器和服务器的socket链接不中断,此时这个链接和http不一样的是它是双工的了
浏览器和服务器有任何须要传递的数据的时候使用这个长链接进行数据传递
这里说它是HTTP握手,是由于浏览器和服务器在创建长链接的握手过程是按照HTTP1.1的协议发送的,有Request,Request Header, Response, Response Header。可是不一样的是Header里面的字段是有特定含义的。
说它是TCP传输,主要体如今创建长链接后,浏览器是能够给服务器发送数据,服务器也能够给浏览器发送请求的。固然它的数据格式并非本身定义的,是在要传输的数据外层有ws协议规定的外层包的。
握手过程
这是一个握手过程的例子。
Upgrade头表示的意思是“客户端除了http以外也支持websocket协议,并且更倾向使用websocket,服务端若是支持的话,我们就换websocket协议吧”
sec-websocket-version:是指出浏览器支持的websocket号。这里是支持hybi-13。这里是不会出现9-12的版本号的。websocket协议规定9-12是保留字段。
sec-websocket-key:算是一种验证返回回来的服务端是不是支持websocket的验证算法。与Response中的sec-websocket-accept是对应的。
sec-websocket-accept与sec-websocket-key的对应算法是:
sec-websocket-accept = base64(hsa1(sec-websocket-key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11))
若是返回的sec-websocket-accept不对,在chrome下会出现Sec-WebSocket-Accept dismatch的错误。
Response返回的HTTP Staus是101,表明服务端说“咱们双方后面就按照websocket协议来进行数据传输吧”
小程序里对ws的支持好于h5。
ws的实现:
1)javax+tomcat(7.0.47+)
2)spring