Python实现同时兼容老版和新版Socket协议的一个简单WebSocket服务器
最近在做的一个项目中需要使用到html5中引入的websocket技术，本来以为应该很容易就能搞定，谁知道在真正上手开发了以后才发现有很多麻烦的地方，虽然我们是一个以前端开发和设计见长的团队，而且作为一个二手程序猿又长期不被待见，但是为了让有同样需求的朋友少走些弯路，我还是决定把实现方法贴在这个地方。
关于websocket的基本概念，*上解释的很清楚，而且网上也能搜出来一大把，这里就略过不表，直接进入正题。
这次的问题首先有一个前提，就是得用python来实现这个服务器，如果对具体语言没有限制的话，推荐大家首选node.js的一个第三方库：socket.io，非常好用，10分钟不打针不吃药搞定websocket server，而且用js来写后端，相信也能对上很多文艺开发者的胃口。
但是如果选择用python，google搜索的结果几乎都不能用，最要命的问题是，websocket协议本身还是一个草案，所以不同浏览器支持的协议版本有所不同，safari 5.1支持的是老版本协议hybi-02，chrome 15以及firefox 8.0支持的是新版本协议hybi-10，老版本协议和新版本协议在建立通信的握手方法还有数据传输的格式要求上都有所不同，导致网上大多数实现方式只能适用于safari浏览器，并且safari和c&f浏览器之间无法互相通信。
首先第一步需要解释的是新、旧版本websocket协议的握手方式。我们先来看看三个不同浏览器发送的握手数据的结构：
chrome：
get / http/1.1
upgrade: websocket
connection: upgrade
host: 127.0.0.1:1337
sec-websocket-origin: http://127.0.0.1:8000
sec-websocket-key: erwjbdvalynhvhnulgrw8q==
sec-websocket-version: 8
cookie: csrftoken=xxxxxx; sessionid=xxxxx
firefox：
host: 127.0.0.1:1337
user-agent: mozilla/5.0 (macintosh; intel mac os x 10.7; rv:8.0) gecko/20100101 firefox/8.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: en-us,en;q=0.5
accept-encoding: gzip, deflate
accept-charset: iso-8859-1,utf-8;q=0.7,*;q=0.7
connection: keep-alive, upgrade
sec-websocket-version: 8
sec-websocket-origin: http://127.0.0.1:8000
sec-websocket-key: 1t3f81iaxnize2txqwv+8a==
cookie: xxx
pragma: no-cache
cache-control: no-cache
upgrade: websocket
safari：
upgrade: websocket
connection: upgrade
host: 127.0.0.1:1337
origin: http://127.0.0.1:8000
cookie: sessionid=xxxx; calview=day; daycurrentdate=1314288000000
sec-websocket-key1: cv`p1* 42#7 ^9}_ 647 08{
sec-websocket-key2: o8 415 8x37r a8 4
;"######
可以看出，chrome和firefox实现的是新版协议，因此只传输了一个”sec-websocket-key”头以供服务端生成握手token，但是遵循老版本的safari的数据中有两个key：”sec-websocket-key1″和”sec-websocket-key2″，因此服务端在生成握手token的时候，需要做一次判断。先来看使用老版本协议的safari，token生成算法如下：
取出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，这就是老版本协议需要的token，然后将这个token附在握手消息的最后发送回client，即可完成握手。
新版协议生成token的方法比较简单：首先把sec-websocket-key和一串固定的uuid “258eafa5-e914-47da-95ca-c5ab0dc85b11”做拼接，然后对这个拼接后的字符串做sha1加密，得到digest以后，做一次base64编码，即可获得token。
另外需要注意的是，新版本和老版本握手协议回传给client的数据结构有所不同，在附件中的server源码中写得很清楚了，看看就能明白。
完成握手只是websocket server的一半功能，现在只能保证这个server能够和两个版本的浏览器建立链接了，但是如果试着把chrome中的消息发送给safari，会发现safari无法接收。导致这个结果的原因，是因为两个版本的协议的data framing结构不同，也即是在握手建立连接后，client发送和接收的数据结构都不一样。
首先第一步需要获取不同版本协议下client发送过来的原始数据。老版本协议比较简单，实际上就是在原始数据前加了个'\x00′，在最后面加上了一个'\xff'，所以如果safari的client发送一个字符串'test'，实际上websocket server收到的数据是：'x00test\xff'，所以只需要剥离掉首尾那两个字符就可以了。
比较麻烦的是新版本协议的数据，按照新版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，这个值介于0~125之间，所以第二个字节本身就代表了原始数据的长度了（60个字节），所以从第三个字节开始，我们能抓出4个字节来，这一串字节叫做 “masks” (掩码?)，掩码之后的数据，就是实际的data…的兄弟了。说是兄弟，是因为这个数据是实际data根据掩码做过一次位运算后得到的，获得原始data的方法是，将兄弟数据的每一位x，和掩码的第i%4位做xor运算，其中i是x在兄弟数据中的索引。看得眼花是吧，看看下面这个代码片段也许就能明白了：
def send_data(raw_str):
back_str = []
back_str.append('\x81')
data_length = len(raw_str)
if data_length < 125:
back_str.append(chr(data_length))
else:
back_str.append(chr(126))
back_str.append(chr(data_length >> 8))
back_str.append(chr(data_length & 0xff))
back_str = "".join(back_str) + raw_str
这样生成的back_str，就能够发送给使用新版协议的chrome或是firefox了。
至此，这个简单的websocket server就完成了，能够同时兼容老版协议和新版协议的socket连接，以及不同版本之间的数据传输。该server的源码请点击这里下载，需要注意的是里面用到了twisted框架来跑tcp服务，代码写得不怎么样，仅供大家参考。