Html5的通信机制及效率的研究

吴晓东，王鹏

（长春理工大学 计算机科学技术学院，长春 130022）

随着基于浏览器访问的Web应用的变得广泛和深入，一些应用需求对Web应用提出新的要求，其中服务器推送技术是一项备受追捧的技术。例如在股票交易行情分析、聊天室和 Web版在线游戏中均使用该技术以实现服务器主动推送消息通知客户端的效果。

然而，HTTP协议是严格遵循请求-响应模型的。即客户端发送一个请求到服务器，服务器对请求做出响应并将响应信息发送回客户端。不同于C/S应用的全双工Socket连接，面向HTTP请求的连接是单向的。客户端向服务器发出请求，服务器做出响应后断开连接，一次通话结束。

在HTML5出现以前实现服务器向客户端推送消息主要有两种方式，一是服务器推送（Server Push），二是客户端拉拽（Client Pull）。然而这两种方式存在着效率低、实现稍显复杂的问题。HTML5的出现有效的解决了这些问题，解决方案出于HTML5的两个新特性：Web Socket和 Server-Sent Events。

1 传统服务器推送技术

传统的服务器推送技术的实现主要由客户端拉拽和服务器推送两种方式实现。

1.1 客户端拉拽

客户端拉拽主要是由HTML实现。在HTML的响应头标签中＜META＞能模拟HTTP协议的响应头报文，＜META＞的用处很多，其中之一就是通过指定HTTP-EQUIV="Refresh"来实现对特定的网页的刷新。如：

实现对目标网页以20秒为间隔的刷新，通过设定刷新的间隔时间可以定时的从服务器获取最新的信息，客户端拖拽优点是实现简单，缺点是隔一段时间就需要重新和服务器建立一次连接，时间间隔的选择固定，效率比较低。

1.2 服务器推送

服务器推送是指在客户端发起请求与服务器建立连接后，服务器发送数据，客户端得到这些数据，同时保证与服务器的连接。当服务器需要再次发送数据时，客户端仍接受数据并保持连接。直到客户端或者服务器端主动中断连接。和客户端拖拽相比服务器端推送主要特征是使用不同方式建立一个HTTP长连接，基于服务器端推送的架构可统一归纳为Comet应用架构，在Comet应用中，创建长连接的方式有很多种，在实现上主要分为两大类：

1.2.1 流方式（streaming）

流方式是指在服务器和客户端建立一个持久有效的HTTP长连接。服务器端向客户端源源不断地发送事件，客户端依次响应这些事件，并逐条处理获取的数据，双方并不关闭这个连接。流方式在实现上主要包括隐藏帧（hidden iframe）和XMLHttpRequest两种方式。通过隐藏帧实现主要是依靠iframe标签。iframe是很早就存在的一种 HTML标签，通过在 HTML页面里嵌入一个隐藏帧，然后将这个隐蔵帧的 SRC属性设为对服务器的长连接请求：

该方式的优点是浏览器支持比较好，缺点是会导致部分浏览器的状态条一直为读取状态且鼠标状态为忙碌，影响用户体验。Google的工程师们通过包装特定的js对象，在IE下使用htmlfile（ActiveX组件），Firefox下嵌套Iframe解决了这个问题。流方式的第二种手段是通过XMLHttpRequest的Ajax请求，在客户端通过截获XMLHttpRequest的Ready-State的状态（状态值为3时为数据读取状态）就可以获取来自服务器端源源不断地数据。但这种方式目前在IE下并不成功，原因是IE缺乏对Ajax请求数据传输状态（ReadyState为3）的有效定义和支持。

1.2.2.长轮询方式（long pooling）

长轮询方式和客户端拖拽有些相似，但是在建立连接的时间选择上有区别。客户端拖拽设定固定时间从服务器端取数据（刷新或其他方式）。长轮询方式则是客户端在一次获取数据成功而自动断开连接后再次发出请求以建立连接。长轮询方式实现方式也主要分为两种。

一种是借助XMLHttpRequest对象，通过发送Ajax请求在成功返回数据（ReadyState为4）并自动断开连接后再次调用请求函数，这样便可以实现对服务器的轮询访问。

另外一种则是通过脚本标签（Script Tag），和ifarme和XMLHttpRequest对象的同源策略不同，脚本标签能够访问任意的URL，实现跨域轮询访问。同源策略阻止从一个域上加载的脚本获取或操作另一个域上的文档属性。也就是说，受到请求的URL的域必须与当前 Web页面的域相同。但是同源策略不阻止将动态脚本元素插入文档中。通过访问来自不同域的携带JSON数据的脚本，即访问JSONP（JSON with Padding）服务，便可以达到跨域的效果。只要在接收数据成功后，再次向JSONP服务发起请求，便可以实现跨域轮询访问。

脚本标签在实现轮询访问方式上和XMLHttpRequest对象一致，都是在成功收到数据后再次发起访问。但是基于JSONP访问服务的错误处理机制并不完善，这是因为使用JSONP不能从服务器得到有效的反馈提示，既不能得到错误提示，也无法获取其他异常的错误信息码。

除了客户端拉拽和服务器端推送外，还可以通过Flash提供的XMLSocket类，Java Applet套接口来实现。使用Flash XMLSocket需要在客户端安装Flash播放器，而且XMLSocket需要单独的通信端口，无法自动穿过防火墙。而Java Applet套接口不足在于 Java applet在收到服务器端返回的信息后，无法通过 JavaScript去更新 HTML页面的内容。

2 Web Socket

WebSocket是HTML5的新标准，它通过定义一个建立在TCP协议之上的套接字（Socket）来支持建立双向的通信信道。首先，WebSocket利用已有的HTTP协议实现服务器端和客户端的“握手”认证。“握手”的通信的格式如下：

“握手”的过程实际是在HTTP报头中加入交互的信息，服务器端按照协议的格式响应这种请求后，连接便成功建立。在连接建立成功后，Web-Socket会以定义的数据帧的格式进行全双工的通信。根据最新的工作草案（working draft 76）Web-Socket数据帧的格式分为文本帧和text frame）和二进制帧（binary frame）。文本帧以字节0x00开头，以字节0xFF结尾，文本帧的内容则以UTF8格式进程编码传送。二进制帧以字节0x80开始，没有结束标志。WebSocket定义四种消息响应事件：onopen，onclose，onerror，onmessage。和 Http 类似，在创建WebSocket对象时也有两种方式，一种是普通创建方式（ws），另一种则是基于安全机制的创建方式（wss），创建格式如下：

与传统的服务器推送技术相比，WebSocket有以下特点：

1.简约的报文传送。由于长轮询在每次请求/响应后都会有额外的消息头信息，在报文内容并不复杂且客户端连接数目巨大的情况下，这种额外的报文头部噪音数据对网络资源的消耗无疑十分巨大。

2.更完善的浏览器支持。实际上，流技术已经在传统的推送技术中占有一席之地。但是碍于其不同方面的缺陷和最新浏览器对WebSocket的广泛支持（WebSocket功能内置），WebSocket也渐渐成为一种好的选择。

3.实现更加简单。在客户端只需要创建Web-Socket对象同时对其的相应的事件进行监听；在服务器端可以使用的技术也很多，如PHP，Java，Asp.net，NodeJS或是任意一种支持Socket通信的服务器脚本语言，在服务器端实现“握手”协议后便可以进行通信。以下是通过NodeJS实现的服务器端的简单模拟环境：

3 Server-Sent Events

和WebSocket的全双工通信不同，HTML5的Server-Sent Events事件是基于单工信道通信的，即只能由服务器端向客户端发送消息。实现Server-Sent Events的方式如下：

Server-Sent Events要求在服务器端传回的消息的MIME类型为text/event-stream格式，在每次接受数据时因为没有额外的消息头等信息，使得消息的报文同样简约有效。

虽然与WebSocket比较起来在功能上有欠缺，但是Server-Sent Event不需要进行“握手”认证等操作，在服务器和客户端实现上也更加简单。而且在一部分实际应用中更直接的需求是服务器对消息的实时有效的推送，对客户端与服务器端的实时交互并不严格。因此，在一些情况下使用Server-Sent Events能够以更简便的方式完成和Web-Socket同样效果的功能。

4 实验

图1 WebSocket、Server-Sent Events、XHR流和Iframe流请求/响应过程图Fig.1 Request/response process diagram of WebSocket，Server-Sent Events，XHR and Iframe stream

由于WebSocket和Server-Sent Events是由传统的Comet技术发展而来，且在实现方式上和传统的流方式实现类似，所以在实验过程中将Web-Socket和Server-Sent Events并入流方式的讨论范围，实验一将比较基于WebSocket、Server-Sent Events、XHR（XmlHttpRequest）流和 Iframe流四种不同流的实现方式下数据帧在收发上的异同。实验二则从流机制（以Server-Sent Event为例）和轮询机制进行比较，观察两者的效率差异。实验一结果如图1所示。

在图1中保持连接发送的帧为TCP格式控制帧，以保持客户端和服务器端长久的连接，大小为54字节，帧格式（十六进制）如下：

对图1中服务器返回数据内容帧分析如表1。

表1 服务器返回数据帧内容大小分析（A：XHR流；B：XHR长轮询；C：WebSocket；D：Server-Sent Events）Tab.1 Analysis of the frame and data size from server

从图1可以看出WebSocket和Server-Sent Events和传统的流方式在实现上很相似，都是发送保持连接的TCP格式的数据报文以达到建立长连接的效果，从表1的统计数据可以看出，每次从服务器端获取更新数据时，噪音数据（除数据外的其他报文）还是比较低的，在表1中WebSocket由于定义数据起始格式（0x00开始，0xFF结束），比其他方式多出2个字节。

实验二结果如图2。

图2 Ajax轮询请求/响应过程图Fig.2 Request/response process diagram of Ajax

在初次建立连接上，轮询和流方式没有明显的差别，但是在以后的获取服务器数据过程中轮询过程每次消耗在连接请求上的带宽和时间消耗是巨大的，而流方式则通过发送TCP连接报文建立长连接来替代连接请求。以下是两者在每次从服务器获取数据的资源消耗比较情况（不包含数据帧）。

表2 流方式和轮询方式在每次更新数据时资源消耗比较Tab.2 Comparison of resource consuming on updating in streaming and pooling manner

同时，在获取的数据帧产生的噪音数据上，两种方式也存在明显差别，轮询方式返回的数据内容帧大小比较如表3所示。

表3 流方式和轮询方式在数据帧大小上的比较情况（流方式数据来自表1）Tab.3 Comparison of the frame size in streaming and pooling manner

从图2可以看出与流方式实现不同，轮询方式在一次通信完毕后需要再次发起请求以便从服务器再次更新数据。而流方式的实现则比较简单，仅仅需要发送一个TCP连接报文便可以继续从服务器获得数据。表2则表明在重新建立连接和保持连接两种实现方式下的带宽和时间上的消耗存在着明显的差异。轮询方式需要消耗更多的时间发送更大的报文来更新客户端数据。通过表3也可以看出，轮询方式不仅仅在重新建立连接上有消耗，在返回数据帧所产生的噪音数据方面也远远大于流方式下的数据帧报文。

5 结论

WebSocket和Server-Sent Events在实现机制上和以流方式建立长连接很相似，都是在发送TCP连接请求报文下建立长久的连接以达到实时通信的目的。同时，WebSocket和Server-Sent Events在连接方式稍有区别，前者为全双工通信，后者为单工通信方式。

轮询方式和流方式在资源消耗上产生巨大的差异。轮询方式在每次建立连接的过程中使用更长的时间消耗了更多的带宽资源，同时在返回的数据帧格式上产生了更大的噪音数据。在多用户访问的情况下，这种带宽的消耗是惊人的。相比而言，流方式的有着更为有效的控制方式和简约的数据格式。

然而在基于XHR（XmlHttpRequest）流和Iframe流的实现上都存在着明显的缺陷，这些缺陷限制了其在服务器推送方面的应用，随着浏览器支持的深入，基于HTML5的WebSocket和Server-Sent Events无疑成为更好的选择，这两个特性不仅继承了流方式的优点，在实现上也更为简单。

［1］Client Pull/Server Push［EB/OL］.http：//www.kiv.zcu.cz/～ledvina/vyuka/books/HTMLnya/ch38.htm，2005.

［2］Infrequently Noted［EB/OL］.http：//infrequently.org/2006/03/comet-low-latency-data-for-the-browser/，2006.

［3］使用Iframe来实现Streaming模式的Comet［EB/OL］.http：//www.tech126.com/iframe-streaming-comet/，2010.

［4］Comet：基于 HTTP 长连接的“服务器推”技术［EB/OL］.http：//www.ibm.com/developerworks/cn/web/wa-lo-comet/，2007.

［5］Mark Pilgrim.HTML5：Up and Running［M］.O’Reilly press，2010.

［6］The WebSocket protocol draft-hixie-the websocketprotocol-76［EB/OL］.http：//tools.ietf.org/html/drafthixie-thewebsocketprotocol-76，2010.

［7］Peter Lubbers，Brain Albers，Frank Salim.Pro HTML5 Programming［M］.Apress press，2010.

［8］王鹏，吴晓东，杨华民.基于不同数据传输格式对Aiax实时性响应的研究［J］.长春理工大学学报：自然科学版，2011，34（2）：146-149.

［9］李国帅，范惠林，竹武林.武器模拟训练系统软件通机制的设计［J］.长春理工大学学报：自然科学版，2010，33（4）：81-83.