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丧失了无状态高并发的特点，大量消耗了服务器带宽和资源。 |
