从WebScoket中我们了解到Ajax的轮询问题，WebScoket协议中服务器和客户端只要进行一次握手，就能创建一条通道实现数据的相互传送。而Ajax轮询，在特定的时间间隔内向服务器发送请求，以达到对数据的推送，这样导致浪费了很多无谓的网络带宽，因此产生疑问：为了达到高效且资源利用最大化的角度，WebScoket为什么没有淘汰定时轮询这种机制呢？
什么是Websocket
Websocket是HTML5中提出的新的协议，注意，这里是协议，可以实现客户端与服务器端的通信，实现服务器的推送功能。
websocket出现之前，开发者使用轮询 (Polling) 和 Comet 技术。
轮询 ：客户端以一定的时间间隔向服务端发出请求，以频繁请求的方式来保持客户端和服务器端的同步。
缺点：当客户端以固定频率向 服务器发起请求的时候，服务器端的数据可能并没有更新，这样会带来很多无谓的网络传输，所以这是一种非常低效的实时方案。
Comet--- 一种 hack 技术， ：基于 HTTP 长连接的“服务器推”技术
以即时通信为代表的web应用程序对数据的Low Latency要求，传统的基于轮询的方式已经无法满足，而且也会带来不好的用户体验。于是一种基于http长连接的“服务器推”技术便被hack出来。这种技术被命名为 Comet ，这个术语由Dojo Toolkit 的项目主管Alex Russell在博文 Comet: Low Latency Data for the Browser 首次提出，并沿用下来。其实，服务器推很早就存在了，在经典的client/server模型中有广泛使用，只是浏览器太懒了，并没有对这种技术提供很好的支持。
Comet的实现主要有两种方式：
- 基于Ajax的长轮询（long-polling）方式
浏览器发出XMLHttpRequest 请求，服务器端接收到请求后，会阻塞请求直到有数据或者超时才返回，浏览器JS在处理请求返回信息（超时或有效数据）后再次发出请求，重新建立连接。在此期间服务器端可能已经有新的数据到达，服务器会选择把数据保存，直到重新建立连接，浏览器会把所有数据一次性取回。
长 轮询是对定时轮询的改进和提高，目地是为了降低无效的网络传输。当服务器端没有数据更新的时候，连接会保持一段时间周期直到数据或状态改变或者时间过期， 通过这种机制来减少无效的客户端和服务器间的交互。当然，如果服务端的数据变更非常频繁的话，这种机制和定时轮询比较起来没有本质上的性能的提高。
2.基于 Iframe 及 htmlfile 的流（http streaming）方式
Iframe是html标记，这个标记的src属性会保持对指定服务器的长连接请求，服务器端则可以不停地返回数据，相对于第一种方式，这种方式跟传统的服务器推则更接近。
流技术方案通常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务 器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。
缺点：这种机制在用户体验上有一点问题，需要针对不同的浏览器设计不同的方案来改进 用户体验，同时这种机制在并发比较大的情况下，对服务器端的资源是一个极大的考验。