漫扯:从polling到Websocket

Http被设计成了一个单向的通信的协议，即客户端发起一个request，然后服务器回应一个response。这让服务器很为恼火：我特么才是老大，我居然不能给小弟发消息。。。

轮询

　　老大发火了，小弟们自然不能无动于衷，为了能及时获得老大的消息，小弟们只好每隔一段时间跑去老大那里问问，有没有新的指示发出。这便是最早实现实时获得服务器数据的技术轮询（Polling）。

　　客户端通过ajax不停去向服务器获得数据，检查是否有新的数据更新。这种使用轮询实现一种伪实时的状态很容易，但效率偏低，一般而言，这种实时获得的数据，本身数据量不是非常大，而通过这种反复地发起request的方式，往往造成的可能是http的header信息比数据本身还多，而且大多数时候获得的数据都是重复无用的。（据说最早还有通过不断刷新客户端页面，来实现web实时通信的情况～ 我想应该木有哪个客户会受得了这种体验。）

Comet

　　“不值啊！咱哥几个每天跑来跑去。拿到的都是一堆没用的数据。”

 

　　于是大家坐在一起想，有什么好办法能不用老是跑腿又可以获得新的信息及时行动呢？小的们灵机一动，下次我们跑去老大那里等着，等他老人家下了命令再回来。这就是基于 AJAX 的长轮询（long-polling）方式实现的一种comet方式。因为ajax的调用是异步的，我们可以在页面加载完毕之后，发起一个request请求，服务器端会阻塞request直到有数据传递或超时（timeout）才返回。客户端处理完服务器返回的信息后，再次发出请求，重新建立连接。这样周而复始。

　　基于 AJAX 的long-polling

　　另外还有一种comet模型，他的名字玄乎比长轮询邪乎的多。。。叫The forever iframe technique。这名儿听起来就高大上很多。其实就是在页面中隐藏一个iframe标签，然后将这个iframe的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。但是这种方法有一个很明显的问题，各个浏览器会一直显示页面加载没有完成，如果用户是个强迫症，他一定会分分钟关掉页面的。TAT......

　forever iframe技术

 

　　不管怎么样comet技术第一次实现了真正的实时通信，而且能支持大量用户，小的们从此总是能准确地获得老大的消息了。但是comet不会是一个没有副作用的解决方案，由于长期占用连接，让web丧失了无状态高并发的特点，大量消耗了服务器带宽和资源。

WebSocket登场

　　“跑来跑去真是麻烦诶～http肿么这么麻烦呀。咱们和老大之间整个新协议吧。”　　

　　这个想法在小弟们中炸开了锅！！！ 在大家的千呼万唤中，WebSocket协议登场了。哈哈哈哈哈～让我来拯救各位吧～～～～

　　WebSocket协议是HTML5定义的一种新协议，它实现了浏览器与服务器全双工通信(full-duplex)。通过浏览器发出websocket连线请求，然后服务器发出回应，建立一个联系的通道。小的们只用发个信息问老大：“首长好～”，老大回一个信儿：“同志们辛苦了！”这样握手（handshaking）就完成了，websocket连线完成，通过websocket，我们可以完成真正的实时通信了。

　　websocket允许通过JavaScript建立与远程服务器的连接，从而实现客户端与服务器间双向的通信。在websocket中有两个方法：　　

　　　　1、send() 向远程服务器发送数据

　　　　2、close() 关闭该websocket链接

　　websocket同时还定义了几个监听函数　　　　

　　　　1、onopen 当网络连接建立时触发该事件

　　　　2、onerror 当网络发生错误时触发该事件

　　　　3、onclose 当websocket被关闭时触发该事件

　　　　4、onmessage 当websocket接收到服务器发来的消息的时触发的事件，也是通信中最重要的一个监听事件。

　　websocket还定义了一个readyState属性，这个属性可以返回websocket所处的状态：

　　　　1、CONNECTING(0) websocket正尝试与服务器建立连接

　　　　2、OPEN(1) websocket与服务器已经建立连接

　　　　3、CLOSING(2) websocket正在关闭与服务器的连接

　　　　4、CLOSED(3) websocket已经关闭了与服务器的连接

　　websocket的url开头是ws，如果需要ssl加密可以使用wss，当我们调用websocket的构造方法构建一个websocket对象（new WebSocket(url)）的之后，就可以进行即时通信了。

　　

　　哈哈哈哈哈哈～老大通过websocket发话了：

　　　　晚上请吃饭！

　　小弟们赶紧行动起来～

总结

　　相比comet技术，websocket不仅节约了header的问题（websocket的head信息只有短短的2个字节）。更加重要的是是通信的稳定性，comet在遇到网络问题之后，想要在不刷新页面的情况下恢复通信，非常困难，而websocket中提供了onclose函数来处理断开网络后的情况，这为我们与服务器的通信提供了可靠的保障。在github上有一个js库（https://github.com/joewalnes/reconnecting-websocket）就是通过这种方式来处理websocket断网重连。

　　websocket看起来广泛实现只是时间问题了，当然这么好用的websocket也不是没有它的问题，websocket目前来看最大的问题是浏览器的支持（幸好大部分的服务器软件在比较新的版本中都已经支持了websocket），ie直到10才开始支持这种协议，而且每个浏览器最近在升级浏览器的时候，都会对websocket做出细微的调整。而且，想象你打开一个页面，当这个页面打开websocket连接并且执行一个内部IP地址的端口扫描,如果端口扫描发现了内部网络上发现了一个开启的80端口，一个隧道就可能通过你的浏览器建立。这样做很可能最终绕过防火墙，并且允许访问内部内容。所以安全问题，也是websocket现在面临的一大隐患。