几种Web通信方式的概念定义

以前写的一些Web通信相关的文章好像只是对各种Web通信方式在浏览器上的实现给出了解决方案，对于这些Web通信方式本身的概念没有明确的做过定义。造成了大家可能看得一头雾水了，于是这篇文章就来梳理一下这些概念，也顺便做一些优劣比较。
　　 概念
　　不知道大家小时候有没有玩过捉迷藏。捉迷藏时就有一个问题，如何让当鬼的小朋友知道其它小朋友已经躲好了？当鬼的小朋友可能会这么做，每隔一小段时间就喊“躲好了没”，来确定其它小朋友的状态。这就是轮询，无论其它小朋友的状态如何，当鬼的小朋友总是在喊，这显然很不科学。于是聪明点的小朋友就说“你们都藏好了之后给我个信号”，于是其它小朋友藏好了之后就自己喊“我藏好了”。这就是长轮询，只在每一轮游戏的开头做了这个声明，游戏中确认其它小朋友状态的步骤就被省略了。但捉迷藏这个游戏是一轮一轮的，要在每一轮都做一次这个声明，有些小朋友就觉得太麻烦了。于是在整个游戏开始时就做一次声明。这就是数据流，如此一来，又省去了每次都约定规则的时间。
　　 优劣
　　就效率而言， 数据流 > 长轮询 > 轮询。但实际情况要复杂的多，如果只是几个小朋友捉迷藏的程度，那很容易解决。捉迷藏本身没有国际化规则来约束，我们可以随意制定规则，只要大家同意就行。但我们的工作并不能完全违背规则，只能以现有的规则来实我们的定义。这就意味着，我们最大的敌人是兼容性问题。
　　就兼容性而言， 轮询 > 长轮询 > 数据流。也许有人会问，为什么说轮询的兼容性比长轮询好？他们不都是一回事吗？他们在前端的实现确实是一回事，但在服务器端的程序中要实现长轮询就不太容易。因为像ASP之类的语言甚至都不自带挂起线程的方法，要实现“长”是非常麻烦的。但好在ASP之类的语言已经渐渐退出历史舞台，以目前来看轮询和长轮询的实现成本并没有太大区别。数据流的兼容性问题在于低版本IE的XHR对象无法在连接断开前访问数据，它必须用IFRAME去接收（所以有时候数据流的Comet方式也被称为IFRAME流）。
　　 定义
　　这些名词都是通用概念，没法对它们直接做定义。就说长轮询这个概念，是连小朋友都会用的，它不限于Web技术。如果非要定义它，必须有一个范围。比如： Comet在 Web技术中的定义是“ 服务器推送技术”、 轮询在“ 基于HTTP”中的定义是“ 客户端每隔一段时间向服务器发起HTTP请求来获取服务器数据。”。这里要注意的是， 轮询本身并不属于 Comet，因为它的主动权在于客户端，不能说它是服务器推送的。最后是 长轮询和 数据流在“ 基于HTTP”中的概念
　　长轮询： 在轮询的基础上扩展，服务器如果没有最新数据就不做处理，使请求陷入等待，直到服务器产生最新数据。
　　数据流： 把HTTP的内容流作为“传输层”来使用。