前言
因为项目需要，前端页面中需要不断向后台请求获取一个及一个以上的状态值。最初的方案是为每个状态值请求都建立一个定时器循环定时发起Ajax请求，结果显而 易见。在HTTP1.1协议中，同一客户端浏览器发起二个及以上请求时，服务器都会进行队列阻塞，即前一请求个执行完后才能执行下一个请求。而在当前前端异步请求十分频繁的情况下，一个页面同时开始一个及以上的长轮询，不仅服务器要承担非常大的压力，前端页面也会因为轮询的挤占而导致性能低下，用户体验不好。依据以上原因，曾经做过多次调研，无论是Comet技术，还是Iframe流技术，都不是很符合要求。而HTML5中新定义的Websocket协议，因为前期调研时发现没有合适的基于C#的类库而止步。现有的类库基本都是基于.net Framework4.5以上，并且都是封装好的。直到最近看到IBM上有一篇基于C#的开源Websocket应用构建，才开始再次尝试。
(附赠相关论文地址：http://www.ibm.com/developerworks/cn/web/1112_huangxa_websocket/)
握手
其实WebScoket的基本原理和Socket一样，只不过客户端和服务器想建立连接需要一次额外的握手。
客户端发送内容：
GET / HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: 127.0.0.1:8080 Origin: http://test.com Pragma: no-cache Cache-Control: no-cache Sec-WebSocket-Key: OtZtd55qBhJF2XLNDRgUMg== Sec-WebSocket-Version: 13 Sec-WebSocket-Extensions: x-webkit-deflate-frame User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
服务器端返回内容:
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: xsOSgr30aKL2GNZKNHKmeT1qYjA=
以上需要注意的是，请求中的【Sec-WebSocket-Key】是随机发送的。而服务器返回的【Sec-WebSocket-Accept】是将【Sec-WebSocket-Key】加上一个固定字符串【258EAFA5-E914-47DA-95CA-C5AB0DC85B11】，并使用SHA-1加密后，再进行BASE-64编码生成的。
流程
因为本文讲的是在MVC中搭建WebSocket服务，所以和很多网上介绍的聊天服务器有所差别。
以下就是WebSocket服务运行的基本流程。
与Ajax的并发阻塞测试
因为使用WebSocket的目的之一就是为了能够避免与Ajax之间的并发线程阻塞问题，对此还进行相关的测试。
测试手段：
1.WebSocket后台每隔15秒执行两个方法，并且这两个方法执行期间会延迟2秒中。
2.前台Ajax连续发起10次请求，每次请求时后台会延迟4秒返回。
测试结果：
测试结论：
1.开启WebSocket长连接后，并没有阻塞Ajax的异步请求。也就是说在开启WebSocket的同时，也能保证Ajax的正常运行。
2.从两次WebSocket返回结果的时间间隔来看，Ajax的线程阻塞对WebSocket的运行没有影响。