webkit HTML5 WebSocket 综合分析 1

csdn lidp  https://blog.csdn.net/perfectpdl
 
作为下一代的Web 标准，HTML5 拥有许多引人注目的新特性，如Canvas、本地存储、多媒体编程接口、WebSocket 等等。这其中有“Web 的TCP ”之称的WebSocket 格外吸引开发人员的注意。WebSocket 的出现使得浏览器提供对Socket 的支持成为可能，从而在浏览器和服务器之间提供了一个基于TCP 连接的双向通道，作为流行的开源浏览器引擎webkit 同样支持此重量级html5特性。
 
 
 
 
 
 
实时Web 应用的窘境
 
Web 应用的信息交互过程通常是客户端通过浏览器发出一个请求，服务器端接收和审核完请求后进行处理并返回结果给客户端，然后客户端浏览器将信息呈现出来，这种机制对于信息变化不是特别频繁的应用尚能相安无事，但是对于那些实时要求比较高的应用来说，比如说在线游戏、在线证券、设备监控、新闻在线播报、RSS 订阅推送等等，当客户端浏览器准备呈现这些信息的时候，这些信息在服务器端可能已经过时了。所以保持客户端和服务器端的信息同步是实时Web 应用的关键要素，对Web 开发人员来说也是一个难题。在WebSocket 规范出来之前，开发人员想实现这些实时的Web 应用，不得不采用一些折衷的方案，其中最常用的就是轮询(Polling) 和Comet 技术，而Comet 技术实际上是轮询技术的改进，又可细分为两种实现方式，一种是长轮询机制，一种称为流技术。下面我们简单介绍一下这几种技术：
 
轮询：
 
这是最早的一种实现实时Web 应用的方案。客户端以一定的时间间隔向服务端发出请求，以频繁请求的方式来保持客户端和服务器端的同步。这种同步方案的最大问题是，当客户端以固定频率向服务器发起请求的时候，服务器端的数据可能并没有更新，这样会带来很多无谓的网络传输，所以这是一种非常低效的实时方案。
 
长轮询：
 
长轮询是对定时轮询的改进和提高，目地是为了降低无效的网络传输。当服务器端没有数据更新的时候，连接会保持一段时间周期直到数据或状态改变或者时间过期，通过这种机制来减少无效的客户端和服务器间的交互。当然，如果服务端的数据变更非常频繁的话，这种机制和定时轮询比较起来没有本质上的性能的提高。
 
流：
 
流技术方案通常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。这种机制在用户体验上有一点问题，需要针对不同的浏览器设计不同的方案来改进用户体验，同时这种机制在并发比较大的情况下，对服务器端的资源是一个极大的考验。
 
综合这几种方案，您会发现这些目前我们所使用的所谓的实时技术并不是真正的实时技术，它们只是在用Ajax 方式来模拟实时的效果，在每次客户端和服务器端交互的时候都是一次HTTP 的请求和应答的过程，而每一次的HTTP 请求和应答都带有完整的HTTP 头信息，这就增加了每次传输的数据量，而且这些方案中客户端和服务器端的编程实现都比较复杂，在实际的应用中，为了模拟比较真实的实时效果，开发人员往往需要构造两个HTTP 连接来模拟客户端和服务器之间的双向通讯，一个连接用来处理客户端到服务器端的数据传输，一个连接用来处理服务器端到客户端的数据传输，这不可避免地增加了编程实现的复杂度，也增加了服务器端的负载，制约了应用系统的扩展性。
 
 
 
 
 
 
WebSocket 的拯救
 
HTML5 WebSocket 设计出来的目的就是要取代轮询和Comet 技术，使客户端浏览器具备像C/S 架构下桌面系统的实时通讯能力。 浏览器通过JavaScript 向服务器发出建立WebSocket 连接的请求，连接建立以后，客户端和服务器端就可以通过TCP 连接直接交换数据。因为WebSocket 连接本质上就是一个TCP 连接，所以在数据传输的稳定性和数据传输量的大小方面，和轮询以及Comet 技术比较，具有很大的性能优势。
 
 
 
WebSocket 规范
 
WebSocket 协议本质上是一个基于TCP 的协议。为了建立一个WebSocket 连接，客户端浏览器首先要向服务器发起一个HTTP 请求，这个请求和通常的HTTP 请求不同，包含了一些附加头信息，其中附加头信息”Upgrade: WebSocket”表明这是一个申请协议升级的HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的WebSocket 连接就建立起来了，双方就可以通过这个连接通道*的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。
 
下面我们来详细介绍一下WebSocket 规范，由于这个规范目前还是处于草案阶段，版本的变化比较快，我们选择draft-hixie-thewebsocketprotocol-76版本来描述WebSocket 协议。因为这个版本目前在一些主流的浏览器上比如Chrome,、FireFox、Opera 上都得到比较好的支持，您如果参照的是新一些的版本话，内容可能会略有差别。
 
一个典型的WebSocket 发起请求和得到响应的例子看起来如下：
 
 
view plaincopy to clipboardprint?
清单1. WebSocket 握手协议 
客户端到服务端：  
GET /demo HTTP/1.1  
Host: example.com  
Connection: Upgrade  
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00  
Upgrade: WebSocket  
Sec-WebSocket-Key1: 4@1 46546xW%0l 1 5  
Origin: https://example.com  
[8-byte security key]  
 
服务端到客户端： 
HTTP/1.1 101 WebSocket Protocol Handshake  
Upgrade: WebSocket  
Connection: Upgrade  
WebSocket-Origin: https://example.com  
WebSocket-Location: ws://example.com/demo  
[16-byte hash response] 
清单1. WebSocket 握手协议
客户端到服务端：
GET /demo HTTP/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
Upgrade: WebSocket
Sec-WebSocket-Key1: 4@1 46546xW%0l 1 5
Origin: https://example.com
[8-byte security key]
 
服务端到客户端：
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin:
WebSocket-Location: ws://example.com/demo
[16-byte hash response]
 
 
这些请求和通常的HTTP 请求很相似，但是其中有些内容是和WebSocket 协议密切相关的。我们需要简单介绍一下这些请求和应答信息，”Upgrade:WebSocket”表示这是一个特殊的HTTP 请求，请求的目的就是要将客户端和服务器端的通讯协议从HTTP 协议升级到WebSocket 协议。从客户端到服务器端请求的信息里包含有”Sec-WebSocket-Key1”、“Sec-WebSocket-Key2”和”[8-byte securitykey]”这样的头信息。这是客户端浏览器需要向服务器端提供的握手信息，服务器端解析这些头信息，并在握手的过程中依据这些信息生成一个16 位的安全密钥并返回给客户端，以表明服务器端获取了客户端的请求，同意创建WebSocket 连接。一旦连接建立，客户端和服务器端就可以通过这个通道双向传输数据了。
 
在实际的开发过程中，为了使用WebSocket 接口构建Web 应用，我们首先需要构建一个实现了WebSocket 规范的服务器，服务器端的实现不受平台和开发语言的限制，只需要遵从WebSocket 规范即可，比如JWebSoket  ，其采用java语言实现websocket服务器端协议，并提供客户端开发js接口。
 
下一篇分析webkit 上websocket js接口.