基于NETTY引擎的WEBSOCKET 新草案支持.doc

基于Netty引擎的WebSocket 新草案支持：介绍：首先需要介绍下什么叫做WebSokcet。这个在维基百科上解释的很清楚，WebSocket 是HTML5一种新的协议。现在很多网站为了实现实时通讯，所采用的技术基本上是轮询策略。即每一个时间间隔，由浏览器像服务器发送一个HTTP 请求，服务器收到请求之后，将最新的数据发送给浏览器。应用在EMMA中，就相当于，为了获取实时message信息，由EMMA客户端每隔一个较短的时间间隔向EMMA服务器发送一个getMessage url request，EMMA服务器收到该url request之后，检查database和memory cache，然后将最新的消息发送给客户端。这种处理方法获得的消息带有明显的滞后性（取决于设置的时间间隔大小），并且会浪费带宽和服务器资源（比如没有更新消息，还需要走一遍基本流程）。现在比较新的轮询技术是Comet，但是普遍采用长链接，也会大量消耗服务器资源。面对这种状况，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽并达到实时通讯。它是实现了浏览器与服务器的双向通讯。在 WebSocket API 中，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。WebSocket技术还在不断的发展阶段，历史上提出了各种协议草案，但是还没有一个稳定的协议供所有浏览器和服务器使用。因此，在浏览器方面，不同的浏览器可以支持不同版本的WebSokcet协议草案，而且传输的数据加密解密方式也不尽相同。在服务器方面，也有支持不同版本WebSocket协议草案的服务器，例如PHP，Jetty，Netty，Ruby，Kaazing。其中，Netty的传输效率最高，也是我们搭建Web Socket Server所采用的通讯服务器引擎。目前，jWebSocket所封装的Netty引擎只能支持到7.x版本的WebSocket协议草案，并不支持10.x版本的新协议。我们对其进行了修改，修复了其中的bug，使之能支持与不同浏览器的通讯。不同WebSocket协议草案的数据传输1. WebSocket请求链接格式（head）：Chrome：GET / HTTP/1.1Upgrade: websocketConnection: UpgradeHost: :1337Sec-WebSocket-Origin: :8000Sec-WebSocket-Key: erWJbDVAlYnHvHNulgrW8Q=Sec-WebSocket-Version: 8Cookie: csrftoken=xxxxxx; sessionid=xxxxxFirefox：GET / HTTP/1.1Host: :1337User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip, deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-alive, UpgradeSec-WebSocket-Version: 8Sec-WebSocket-Origin: :8000Sec-WebSocket-Key: 1t3F81iAxNIZE2TxqWv+8A=Cookie: xxxPragma: no-cacheCache-Control: no-cacheUpgrade: websocketSafari：GET / HTTP/1.1Upgrade: WebSocketConnection: UpgradeHost: :1337Origin: :8000Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000Sec-WebSocket-Key1: cVp1* 42#7 9_ 647 08Sec-WebSocket-Key2: O8 415 8x37R A8 4;#IE7GET / HTTP/1.1Upgrade: WebSocketConnection: UpgradeHost: :1337Origin: :8000Cookie: sessionid=xxxx; calView=day; dayCurrentDate=1314288000000Sec-WebSocket-Key1: cVp1* 42#7 9_ 647 08Sec-WebSocket-Key2: O8 415 8x37R A8 4;#IE8GET / HTTP/1.1Host: :1337User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20100101 Firefox/8.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip, deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-alive, UpgradeSec-WebSocket-Version: 8Sec-WebSocket-Origin: :8000Sec-WebSocket-Key: 1t3F81iAxNIZE2TxqWv+8A=Cookie: xxxPragma: no-cacheCache-Control: no-cacheUpgrade: websocket对于协议草案7.x之前的版本，只包含有一个key，一般浏览器已经不支持7.x以前的版本；对于协议草案7.x（Safari和IE7），链接请求中包含有3个key，分别是Sec-WebSocket-Key1，Sec-WebSocket-Key2以及在报头末尾的一串字符；对于协议草案10.x（Chrome，Firefox, IE8）又回归到只有一个key：Sec-WebSocket-Key，但另外多了Sec-WebSocket-Version，Sec-WebSocket-Origin两个相关域。因此，对于一个WebSocket链接请求，只要判断存在Sec-WebSocket-Key，Sec-WebSocket-Version和Sec-WebSocket-Origin三个域，则可以确定是10.x草案，而包含有Sec-WebSocket-Key1和Sec-WebSocket-Key2两个域则可以确定是7.x草案 2数据传输格式： 在收到浏览器发送的WebSocket请求链接消息之后，服务器需要根据收到的key，计算出accept key返回给浏览器，浏览器验证accept key如果正确，则可以正确建立链接。不同协议草案计算accept key的方法和加密格式都不尽相同。 对于协议7.x，以Safari的输入为例：取出Sec-WebSocket-Key1中的所有数字字符形成一个数值，这里是1427964708，然后除以Key1中的空格数目，这里好像是6个空格，得到一个数值，保留该数值整数位，得到数值N1；对Sec-WebSocket-Key2如法炮制，得到第二个整数N2；把N1和N2按照Big-Endian字符序列连接起来，然后再与另外一个Key3连接，得到一个原始序列ser_key。那么Key3是什么呢？大家可以看到在Safari发送过来的握手请求最后，有一个8字节的奇怪的字符串“;”#”，这个就是Key3。回到ser_key，对这个原始序列做md5算出一个16字节长的digest，这就是老版本协议需要的accept key，然后将这个token附在握手消息的最后发送回Client，即可完成握手。 对于协议10.x，生成accept key的方法比较简单：首先把Sec-WebSocket-Key和一串固定的UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”做拼接，然后对这个拼接后的字符串做SHA1加密，得到digest以后，做一次base64编码，即可获得Token。 完成握手只是WebSocket Server的一半功能，现在只能保证这个Server能够和两个版本的浏览器建立链接了，但是如果试着把Chrome中的消息发送给Safari，会发现Safari无法接收。导致这个结果的原因，是因为两个版本的协议的Data Framing结构不同，也即是在握手建立连接后，Client发送和接收的数据结构都不一样。 首先第一步需要获取不同版本协议下Client发送过来的原始数据。老版本协议比较简单，实际上就是在原始数据前加了个x00，在最后面加上了一个xFF，所以如果Safari的Client发送一个字符串test，实际上WebSocket Server收到的数据是：x00testxFF，所以只需要剥离掉首尾那两个字符就可以了。 比较麻烦的是新版本协议的数据，按照新版draft的解释，Chrome和Firefox发过来的数据报文由以下几个部分组成：首先是一个固定的字节（1000 0001或是1000 0002），这个字节可以不用理会。麻烦的是第二个字节，这里假设第二个字节是1011 1100，首先这个字节的第一位肯定是1，表示这是一个”masked”位，剩下的7个0/1位能够计算出一个数值，比如这里剩下的是 011 1100，计算出来就是60，这个值需要做如下判断： 如果这个值介于0000 0000 和 0111 1101 (0 125) 之间，那么这个值就代表了实际数据的长度；如果这个数值刚好等于0111 1110 (126)，那么接下来的2个字节才代表真实数据长度；如果这个数值刚好等于0111 1111 (127)，那么接下来的8个字节代表数据长度。 有了这个判断之后，能够知道代表数据长度的字节在第几位结束，比如我们举得例子60，这个值介于0125之间，所以第二个字节本身就代表了原始数据的长度了（60个字节），所以从第三个字节开始，我们能抓出4个字节来，这一串字节叫做 “masks” (掩码?)，掩