Fork me on GitHub

Ajax、Comet 与 Websocket

1、从 http 协议说起

1996年IETF  HTTP工作组发布了HTTP协议的1.0版本 ,到现在普遍使用的版本1.1,HTTP协议经历了17 年的发展。这种分布式、无状态、基于TCP的请求/响应式、在互联网盛行的今天得到广泛应用的协议,相对于互联网的迅猛发展,它似乎进步地很慢。互联网从兴起到现在,经历了门户网站盛行的web1.0时代,而后随着ajax技术的出现,发展为web应用盛行的web2.0时代,如今又朝着web3.0的方向迈进。反观http协议,从版本1.0发展到1.1,除了默认长连接之外就是缓存处理、带宽优化和安全性等方面的不痛不痒的改进。它一直保留着无状态、请求/响应模式,似乎从来没意识到这应该有所改变。

2、Ajax 脚本发送的 http 请求

传统的web应用要想与服务器交互,必须提交一个表单(form),服务器接收并处理传来的表单,然后返回全新的页面,因为前后两个页面的数据大部分都是相同的,这个过程传输了很多冗余的数据、浪费了带宽。于是Ajax技术便应运而生。

Ajax是Asynchronous JavaScript and 的简称,由Jesse James Garrett 首先提出。这种技术开创性地允许浏览器脚本(JS)发送http请求。Outlook Web Access小组于98年使用,并很快成为IE4.0的一部分,但是这个技术一直很小众,直到2005年初,google在他的goole groups、gmail等交互式应用中广泛使用此种技术,才使得Ajax迅速被大家所接受。

Ajax的出现使客户端与服务器端传输数据少了很多,也快了很多,也满足了以丰富用户体验为特点的web2.0时代 初期发展的需要,但是慢慢地也暴露了他的弊端。比如无法满足即时通信等富交互式应用的实时更新数据的要求。这种浏览器端的小技术毕竟还是基于http协议,http协议要求的请求/响应的模式也是无法改变的,除非http协议本身有所改变。

3、Comet  一种 hack 技术

以即时通信为代表的web应用程序对数据的Low Latency要求,传统的基于轮询的方式已经无法满足,而且也会带来不好的用户体验。于是一种基于http长连接的“服务器推”技术便被hack出来。这种技术被命名为Comet,这个术语由Dojo Toolkit 的项目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出,并沿用下来。

其实,服务器推很早就存在了,在经典的client/server模型中有广泛使用,只是浏览器太懒了,并没有对这种技术提供很好的支持。但是Ajax的出现使这种技术在浏览器上实现成为可能, google的gmail和gtalk的整合首先使用了这种技术。随着一些关键问题的解决(比如 IE 的加载显示问题),很快这种技术得到了认可,目前已经有很多成熟的开源Comet框架。

以下是典型的Ajax和Comet数据传输方式的对比,区别简单明了。典型的Ajax通信方式也是http协议的经典使用方式,要想取得数据,必须首先发送请求。在Low Latency要求比较高的web应用中,只能增加服务器请求的频率。Comet则不同,客户端与服务器端保持一个长连接,只有客户端需要的数据更新时,服务器才主动将数据推送给客户端。

Comet 的实现主要有两种方式:

【1】基于 Ajax 的长轮询(long-polling)方式

浏览器发出

【2】基于 Iframe 及 htmlfile 的流(http streaming)方式

Iframe是html标记,这个标记的src属性会保持对指定服务器的长连接请求,服务器端则可以不停地返回数据,相对于第一种方式,这种方式跟传统的服务器推则更接近。

在第一种方式中,浏览器在收到数据后会直接调用JS回调函数,但是这种方式该如何响应数据呢?可以通过在返回数据中嵌入JS脚本的方式,如“<script type="text/javascript">js_func(“data from server ”)</script>”,服务器端将返回的数据作为回调函数的参数,浏览器在收到数据后就会执行这段JS脚本。

但是这种方式有一个明显的不足之处:IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成,而且 IE 上方的图标会不停的转动,表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题,并将这种方法应用到了 gmail+gtalk 产品中。

4、Websocket 未来的解决方案

如果说 Ajax 的出现是互联网发展的必然,那么 Comet 技术的出现则更多透露出一种无奈,仅仅作为一种 hack 技术,因为没有更好的解决方案。Comet 解决的问题应该由谁来解决才是合理的呢?浏览器,html 标准,还是 http 标准?主角应该是谁呢?本质上讲,这涉及到数据传输方式,http协议应首当其冲,是时候改变一下这个懒惰的协议的请求/响应模式了。

W3C 给出了答案,在新一代 html 标准 html5 中提供了一种浏览器和服务器间进行全双工通讯的网络技术 Websocket。从 Websocket 草案得知,Websocket 是一个全新的、独立的协议,基于TCP协议,与http协议兼容、却不会融入http协议,仅仅作为html5的一部分。于是乎脚本又被赋予了另一种能力:发起 websocket 请求。这种方式我们应该很熟悉,因为 Ajax 就是这么做的,所不同的是,Ajax 发起的是 http 请求而已。 

与http协议不同的请求/响应模式不同,Websocket 在建立连接之前有一个 Handshake(Opening Handshake)过程,在关闭连接前也有一个 Handshake(Closing Handshake)过程,建立连接之后,双方即可双向通信。

【1】Opening Handshake

客户端发起连接 Handshake 请求:

  GET /chat HTTP/1.1

        Host: server.example.com

        Upgrade: websocket

        Connection: Upgrade

        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

        Origin: http://example.com

        Sec-WebSocket-Protocol: chat, superchat

        Sec-WebSocket-Version: 13

服务器端响应:

        HTTP/1.1 101 Switching Protocols

        Upgrade: websocket

        Connection: Upgrade

        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

        Sec-WebSocket-Protocol: chat

“Upgrade:WebSocket”  表示这是一个特殊的 HTTP 请求,请求的目的就是要将客户端和服务器端的通讯协议从 HTTP 协议升级到 WebSocket 协议。

“Sec-WebSocket-Key” 是一段浏览器 base64 加密的密钥

“Sec-WebSocket-Accept” 服务器端在接收到的Sec-WebSocket-Key密钥后追加一段神奇字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”,并将结果进行sha-1哈希,然后再进行base64加密返回给客户端。

“Sec-WebSocket-Protocol” 表示客户端请求提供的可供选择的子协议,及服务器端选中的支持的子协议,“Origin” 服务器端用于区分未授权的websocket浏览器

“HTTP/1.1 101 Switching Protocols”中101 为服务器返回的状态码,所有非101的状态码都表示handshake并未完成。

【2】Data Framing

Websocket 协议通过序列化的数据包传输数据。数据封包协议中定义了 opcode、payload length、Payload data 等字段。具体封包格式如下图所示:

FIN: 标识是否为此消息的最后一个数据包,占 1 bit

RSV1, RSV2, RSV3:  用于扩展协议,一般为0,各占1bit

Opcode:数据包类型(frame type),占4bits

         0x0:标识一个中间数据包

         0x1:标识一个text类型数据包

         0x2:标识一个binary类型数据包

         0x3-7:保留

         0x8:标识一个断开连接类型数据包

         0x9:标识一个ping类型数据包

         0xA:表示一个pong类型数据包

         0xB-F:保留

Payload length:Payload data的长度,占7bits,如果这个值等于126,则此后16bits用于表示Payload length,如果这个值等于127,则此后64bits用于表示Payload length

Payload data:应用层数据

【3】Closing Handshake

相对于 Opening Handshake,Closing Handshake 则简单得多,主动关闭的一方向另一方发送一个关闭类型的数据包,对方收到此数据包之后,再回复一个相同类型的数据包,关闭完成。

关闭类型数据包遵守封包协议,Opcode为 0x8,Payload data 可以用于携带关闭原因或消息。 

虽然现阶段 websocket 协议还处于草案阶段,不过浏览器早就开始开始支持了,以下是不同浏览器兼容列表:

从浏览器支持角度来看,Websocket 还有很长的路要走,特别是在中国这个IE6依然盛行的国家,即便在 Websocket 标准化之后,旧版本浏览器的消亡也需要很长一段时间,因此现阶段 comet 依然是最好的解决方案。

 

原文链接:http://www.shaoqun.com/a/54588.html

 

posted @ 2017-09-26 11:50  一像素  阅读(867)  评论(0编辑  收藏  举报