现在,很多网站为了实现推送技术,所用的技术都是轮询。轮询是指在特定的时间间隔 (如每一秒),由浏览器对服务器发起 HTTP 请求,然后由服务器返回数据给浏览器
。由于 HTTP 协议是惰性的,只有客户端发起请求,服务器才会返回数据。轮询技术实现的前提条件同样是基于这种机制。而 webSocket 属于服务端推送技术,本质是一种应用层协议,可以实现持久连接的全双工双向通信。在介绍 WebSocket 之前,先谈谈轮询技术和 HTTP 流技术。
文章目录
Ajax 短轮询即客户端周期性的向服务器发起 HTTP 请求,不管服务器是否真正获取到数据,都会向客户端返回响应。每个 request 对应一个 response,由于 HTTP/1.1 的持久连接 (建立一次 TCP 连接,发送多个请求) 和管线化技术(异步发送请求),使得 HTTP 请求可以在建立一次 TCP 连接之后发起多个异步请求。
这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而 HTTP 请求在每次发送时都会带上很长的请求头部字段,其中真正有效的数据可能只是很小的一部分 (如 Cookie 字段),显然服务器会浪费带宽等资源。
有朋友可能会想,那可以加大 Ajax 的传输时间,如改为 3s 为一个周期。但是时间长了,对于实时性要求比较高的项目来说,页面更新的数据也就太慢了。
而比较新的技术向服务器轮询获取数据的实现是 Comet,即服务端推送。简单的说,服务端推送就是在客户端发起 HTTP 请求之后,服务器可以主动的向客户端推送数据。实现 Comet 的方式有两种:Ajax 长轮询和 HTTP 流。
Ajax 长轮询本身不是一个真正的推送。长轮询是短轮询的一种变体。在客户端向服务器发起 HTTP 请求之后,服务器并不是每次都立即响应:当服务器得到最新数据时,会向客户端传输数据;当数据没有更新时,服务器会保持这个连接,等待更新数据之后,才向客户端传输数据。当然,如果服务端数据长时间没有更新,一段时间后,请求就会超时。客户端收到超时信息后,会重新发送一个 HTTP 请求给服务器。
也就是说,只有在服务器获取更新后的数据,才会向客户端传输数据。这种方式也存在弊端。虽然服务端可以主动的向客户端传输数据,但是依然需要反复发出请求 (HTTP 请求数量比短轮询少很多)。
短轮询和长轮询的相同点在于客户端都需要向服务器发起 HTTP 请求,不同点在于服务器如何响应:短轮询是服务器立即响应,不管数据是否有效;长轮询是等待数据更新后响应。
HTTP 流不同于轮询技术,HTTP 流只建立一次 TCP 连接,在 3 次握手之后进行 HTTP 通信,此时客户端向服务器发起一个 HTTP 请求,而服务器保持连接打开,周期性的向客户端传输数据。双方在没有明确提出断开连接时,服务器就会持续向客户端传输数据。也就是说,假如服务器数据没有更新,服务器不会返回响应,而是保持连接;如果数据更新了,会立即将数据传输给客户端。此时会发起下一个 HTTP 请求,过程周而复始。
在 JS 中,可以通过侦听 readystatechange 事件及检测 readyState 的值是否为 3 来实现 HTTP 流。随着不断从服务器接收数据,readyState 的值会周期性的变为 3。当 readyState 值变为 3 时,responseText 属性就会保存接受到的所有数据。此时,就需要比较此前接收到的数据,决定从什么位置开始取得最新的数据。用 XHR 对象实现 HTTP 流的方式如下:
- let httpStream = (url, processor, finished) => {
- let xhr = new XMLHttpRequest()
- let received = 0
- xhr.open(url, 'get', true)
- xhr.addEvetntListener('readystatechange', () => {
- let result
- if (xhr.readyState === 3) {
- result = xhr.responseText.slice(received)
- received += result.length
- processor(result)
- } else if (xhr.readyState === 4) {
- finished(xhr.responseText)
- }
- })
- }
只要 readyState 为 3,就对 responseText 进行分隔以获取最新数据。这里的 received 表示记录已经处理了多少字符。然后通过 processor 回调函数来处理最新数据。而当 readyState 为 4 时,表示数据已经完全获取到,则直接将 xhr.responseText 传入 finished 回调函数处理即可。
调用方式如下.
- httpStream(url, data => {
- console.log(data)
- }, finishedData => {
- console.log(data)
- })
对 (长、短) 轮询和 HTTP 流做一个小小的总结
由于服务器推送的重要性 (实现赛事结果更新、聊天室等),HTML5 实现了两个服务端推送接口,SSE 和 WebSocket。
SSE(Server-Sent Eevents,服务器发送事件) 用于创建到服务器的单向连接,服务器通过这个连接可以发送任意数量的数据。实现 SSE 有以下几点要求
用法如下,其实理解了服务器推送之后,SSE 使用起来相对简单
- // EventSource接受的参数必须同源。
- // 使用message事件监听从服务器收到的消息,并存储在event.data对象里。
- let source = new EventSource('index.php')
- source.onmessage = e => {
- console.log(e.data)
- }
SSE 在 IE 下都不支持,ios4.0 以上、android4.4 以上都支持 SSE。
铺垫了那么久的前文,终于到 WebSocket 了... :) 感谢各位朋友不嫌弃的耐心阅读。
简单来说,WebSocket 是一种协议,与 HTTP 协议一样位于应用层,都是 TCP/IP 协议的子集。HTTP 协议是单向通信协议,只有客户端发起 HTTP 请求,服务端才会返回数据。而 WebSocket 协议是双向通信协议,在建立连接之后,客户端和服务器都可以主动向对方发送或接受数据。WebSocket 协议建立的前提需要借助 HTTP 协议,建立连接之后,持久连接的双向通信就与 HTTP 协议无关了。
WebSocket 协议的目标是在一个独立的持久连接上提供全双工双向通信。客户端和服务器可以向对方主动发送和接受数据。在 JS 中创建 WebSocket 后,会有一个 HTTP 请求发向浏览器以发起请求。在取得服务器响应后,建立的连接会使用 HTTP 升级将 HTTP 协议转换为 WebSocket 协议。也就是说,使用标准的 HTTP 协议无法实现 WebSocket,只有支持那些协议的专门浏览器才能正常工作。
请认真阅读、记住上面一段话。: )
由于 WebScoket 使用了自定义协议,所以 URL 与 HTTP 协议略有不同。未加密的连接为 ws://,而不是 http://。加密的连接为 wss://,而不是 https://。
使用 JavaScript 是实现 WebScoket 协议相对简单,以下是 WebSocket APIs
- // 打开WebSocket, 传递的参数url没有同源策略的限制。
- let websocket = new WebSocket(url)
- // 监听open事件,在成功建立websocket时向url发送纯文本字符串数据(如果是对象则必须序列化处理)。
- websocket.onopen = () = >{
- if (websocket.readyState === WebSocket.OPEN) {
- websocket.send('hello world')
- }
- }
- // 监听message事件,在服务器响应时接受数据。返回的数据存储在事件对象中。
- websocket.onmessage = e = >{
- let data = e.data console.log(data)
- }
- // 监听error事件,在发生错误时触发,连接不能持续。
- websocket.onerror = () = >{
- console.log('websocket connecting error!!')
- }
- // 监听close事件,在连接关闭时触发。只有close事件的事件对象拥有额外的信息。可以通过这些信息来查看关闭状态
- websocket.onclose = e = >{
- let clean = e.wasClean // 是否已经关闭
- let code = e.code // 服务器返回的数值状态码。
- let reason = e.reason //服务器返回的消息。
- }
注意,WebScoket 不支持 DOM2 语法为事件绑定事件处理程序,因此必须使用 DOM0 级语法来每个事件绑定事件处理程序。
- // correct!
- websocket.onerror = () = >{}
- // error!
- websocket.addEventListener('error', () = >{})
看完了 WebSocket APIs 之后,再来看看 WebSocket 是如何实现连接的(奶思,看到这里的朋友耐心真棒.. 只剩下一点点了:) )
WebSocket 是应用层协议,是 TCP/IP 协议的子集,通过 HTTP/1.1 协议的 101 状态码进行握手。也就是说,WebSocket 协议的建立需要先借助 HTTP 协议,在服务器返回 101 状态码之后,就可以进行 websocket 全双工双向通信了,就没有 HTTP 协议什么事情了。
参照 wiki 握手协议的例子:并对一些字段进行说明。
Connection:Connection 必须设置为 Upgrade,表示客户端希望连接升级
Upgrade:Upgrade 必须设置为 WebSocket,表示在取得服务器响应之后,使用 HTTP 升级将 HTTP 协议转换 (升级) 为 WebSocket 协议。
Sec-WebSocket-key: 随机字符串,用于验证协议是否为 WebSocket 协议而非 HTTP 协议
Sec-WebSocket-Version: 表示使用 WebSocket 的哪一个版本。
Sec-WebSocket-Accept: 根据 Sec-WebSocket-Accept 和特殊字符串计算。验证协议是否为 WebSocket 协议。
Sec-WebSocket-Location: 与 Host 字段对应,表示请求 WebSocket 协议的地址。
HTTP/1.1 101 Switching Protocols:101 状态码表示升级协议,在返回 101 状态码后,HTTP 协议完成工作,转换为 WebSocket 协议。此时就可以进行全双工双向通信了。
WebSocket 协议的浏览器兼容性较好。
参考资料:
1.《JavaScript 高级程序设计 第三版》
3. wiki 服务端推送技术
4. WebSocket 教程
6. WebSocket 是什么原理?为什么可以实现持久连接?
来源: http://www.cnblogs.com/unclekeith/p/8087182.html