WebSocket

目标

　　WebSocket 规范的目标是在浏览器中实现和服务器端双向通信.双向通信可以拓展浏览器上的应用类型,例如实时的数据推送(股票行情),游戏,聊天/im 等.

编辑本段背景

　　目前在浏览器中通过http仅能实现单向的通信,comet可以一定程度上模拟双向通信,但效率较低,并需要服务器有较好的支持; flash中的socket和xmlsocket可以实现真正的双向通信,通过 flex ajax bridge,可以在javascript中使用这两项功能. 可以预见,如果websocket一旦在浏览器中得到实现,将会替代上面两项技术,得到广泛的使用.面对这种状况，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽并达到实时通讯。

编辑本段原理

　　websocket规范由两部分组成,一部分是浏览器中的 websocket api, 由w3c 制订, 一部分是websocket 协议, 由ietf制订,目前是draft状态.websocket的协议比较简单, 客户端和普通的浏览器一样通过80或者443端口和服务器进行请求握手,服务器根据http header识别是否一个websocket请求,如果是,则将请求升级为一个websocket连接,握手成功后就进入双向 长连接 的数据传输阶段. websocket的数据传输是基于帧的方式: 0x00 表示数据开始, 0xff表示数据结束,数据以utf-8编码.

编辑本段握手协议

　　在实现websocket连线过程中，需要透过浏览器发出websocket连线请求，然后服务器发出回应，这个过程通常称为“握手” (handshaking)。

　　PS1:握手协议在后期的版本中，会标明版本编号，下面的例子属于早期的协定之一，对于新版的 chrome 和 Firefox 皆不适用。

　　PS2:后期的版本大多属于功能上的扩充，例如使用第7版的握手协议同样也适用于第8版的握手协议。

　　 例子：

　　 浏览器请求

　　GET /demo HTTP/1.1

　　Host: 你的网址.com

　　Connection: Upgrade

　　Sec-WebSocket-Key2: 12998 5 Y3 1 .P00

　　Sec-WebSocket-Protocol: sample

　　Upgrade: WebSocket

　　Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5

　　Origin: http://你的网址.com

　　^n:ds[4U

　　 服务器回应

　　HTTP/1.1 101

　　WebSocket Protocol Handshake

　　Upgrade: WebSocket

　　Connection: Upgrade

　　Sec-WebSocket-Origin: http://你的网址.com

　　Sec-WebSocket-Location: ws://你的网址.com/demo

　　Sec-WebSocket-Protocol: sample

　　8jKS’y:G*Co,Wxa-

编辑本段浏览器

　　目前实现了websocket的浏览器：

　　

Chrome	Supported in version 4+
Firefox	Supported in version 4+
Internet Explorer	Supported in version 10+
Opera	Supported in version 10+
Safari	Supported in version 5+

编辑本段服务器

　　在服务器端,也出现了一些实现websocket协议的项目:

　　 jetty  7.0.1 包含了一个初步的实现

　　resin 包含有websocket 实现

　　pywebsocket, apache http server 扩展

　　apache tomcat 7.0.27 版本

　　websocket api在浏览器端的广泛实现似乎只是一个时间问题了, 值得注意的是目前服务器端没有标准的api, 各个实现都有自己的一套api, 并且jcp也没有类似的提案, 所以使用websocket开发服务器端有一定的风险.可能会被锁定在某个平台上或者将来被迫升级.

一、WebSocket的前世今生

Web 应用的信息交互过程通常是客户端通过浏览器发出一个请求，服务器端接收和审核完请求后进行处理并返回结果给客户端，然后客户端浏览器将信息呈现出来，这种机制对于信息变化不是特别频繁的应用尚能相安无事，但是对于那些实时要求比较高的应用来说就显得捉襟见肘了。我们需要一种高效节能的双向通信机制来保证数据的实时传输。有web TCP之称的WebSocket应运而生，给开发人员提供了一把强有力的武器来解决疑难杂症。
(PS：其实，在早期的HTML5规范中，并没有包含WebSocket的定义，一些早期的HTML5书籍中，完全没有WebSocket的介绍。直到后来，才加入到当前的草案中。)

二、WebSocket是什么？

其实，从背景介绍中，我们大致的可以猜出，WebSocket是干什么用的。前面我们提到，WebSocket有web TCP之称，既然是TCP，肯定是用来做通信的，但是它又有不同的地方，WebSocket作为HTML5中新增的一种通信协议，由通信协议和编程API组成，它能够在浏览器和服务器之间建立双向连接，以基于事件的方式，赋予浏览器原生的实时通信能力，来扩展我们的web应用，增加用户体验，提升应用的性能。何谓双向？服务器端和客户端可以同时发送并响应请求，而不再像HTTP的请求和响应。

三、为什么使用WebSocket

在WebSocket出现之前，我们有一些其它的实时通讯方案，比较常用的有轮询，长轮询，流，还有基于Flash的交换数据的方式，接下来，我们一一分析一下，各种通信方式的特点。

①　轮询
这是最早的一种实现实时web应用的方案；原理比较简单易懂，就是客户端以一定的时间间隔向服务器发送请求，以频繁请求的方式来保持客户端和服务器端的数据同步。但是问题也很明显：当客户端以固定频率向服务器端发送请求时，服务器端的数据可能并没有更新，这样会带来很多无谓的请求，浪费带宽，效率低下。

②　长轮询
长轮询是对定时轮询的改进和提高，目地是为了降低无效的网络传输。当服务器端没有数据更新的时候，连接会保持一段时间周期直到数据或状态改变或者时间过期，通过这种机制来减少无效的客户端和服务器间的交互。当然，如果服务端的数据变更非常频繁的话，这种机制和定时轮询比较起来没有本质上的性能的提高。

③　流
长轮询是对定时轮询的改进和提高，目地是为了降低无效的网络传输。当服务器端没有数据更新的时候，连接会保持一段时间周期直到数据或状态改变或者时间过期，通过这种机制来减少无效的客户端和服务器间的交互。当然，如果服务端的数据变更非常频繁的话，这种机制和定时轮询比较起来没有本质上的性能的提高。

④　基于Flash的实时通讯方式
Flash有自己的socket实现，这为实时通信提供了可能。我们可以利用Flash完成数据交换，再利用Flash暴露出相应的接口，方便JavaScript调用，来达到实时传输数据的目的。这种方式比前面三种方式都要高效，而且应用场景比较广泛；因为flash本身的安装率很高；但是在当前的互联网环境下，移动终端对flash的支持并不好，以IOS为主的系统中根本没有flash的存在，而在android阵营中，虽然有flash的支持，但实际的使用效果差强人意，即使是配置较高的移动设备，也很难让人满意。就在前几天(2012年6月底)，Adobe官方宣布，不在支持android4.1以后的系统，这基本上宣告了flash在移动终端上的死亡。

下面是轮询和长轮询的信息流转图：

对比完四种不同的实时通信方式，不难发现，除了基于flash的方案外，其它三种方式都是用AJAX方式来模拟实时的效果，每次客户端和服务器端交互时，都是一次完整的HTTP请求和应答的过程，而每一次的HTTP请求和应答都带有完整的HTTP头信息，这就增加每次的数据传输量，而且这些方案中客户端和服务端的编程实现比较复杂。

接下来，我们再来看一下WebSocket，为什么要使用它呢？高效节能，简单易用。
下图是来自websocket.org的测试结果：

在流量和负载增大的情况下，WebSocket 方案相比传统的 Ajax 轮询方案有极大的性能优势；而在开发方面，也十分简单，我们只需要实例化WebSocket，创建连接，查看是否连接成功，然后就可以发送和相应消息了。我们会在后面的实例中去详细的说明API。

WebSocket不同版本的三种握手方式以及一个Netty实现JAVA类

http://blog.csdn.net/fenglibing/article/details/7100070

基于Websocket草案10协议的升级及基于Netty的握手实现

http://blog.csdn.net/fenglibing/article/details/6852497