漫扯:从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同时还定义了几个监听函数　　　　

　　　　一、onopen 当网络链接创建时触发该事件

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

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

　　　　四、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如今面临的一大隐患。