Comet 的诱惑

核心提示： 标准制定工作滞后HTTP 协议设计为在开始发送请求时，请求发送所使用的连接在响应完全发回之前都几乎完全锁定，Comet 的诱惑(3)，这就意味着在 Comet 流样式通信持续期间，从客户端设备到后端服务器的每个系统上都至少有一个连接处于不可用状态，但目前很难对其进行支持，大部分人都返回到混合轮询

标准制定工作滞后

HTTP 协议设计为在开始发送请求时，请求发送所使用的连接在响应完全发回之前都几乎完全锁定。这就意味着在 Comet 流样式通信持续期间，从客户端设备到后端服务器的每个系统上都至少有一个连接处于不可用状态。

同步与异步

Internet 基础设施的很多部分本质上是同步性质的。这包括服务器（如不同的防火墙）和编程模型（如 HTTP Servlet）。因此，目前的 Internet 基础设施通常并不能为 CS 样式应用程序的广泛应用提供所需的基础，因为其中的大部分系统的线程数量都有限，而每个 Comet 连接都会锁定一个线程。

有限的连接数量

代理服务器和防火墙将对大量 Comet 流应用程序的引入造成阻碍。为什么呢？目前的操作系统通常并没有做好普遍使用 Comet 流的准备。由于上面提到的关于 HTTP 的问题，Comet 流应用程序的每个用户都将锁定 HTTP 请求通过的每个防火墙和代理中的两个连接和文件描述符。很多操作系统（以及构建于这些操作系统上的软件）都限制为任何时间整个计算机的连接数少于 65,000 个。这就意味着这些系统可能会在 CPU 或内存不够之前就耗尽可用连接数，而需要更多系统——但是现有系统上仍然有大量的 CPU 和内存可用。

按照设计工作

有些系统根本就没有设计为处理这种类型的应用程序。这些系统会采用缓存 HTTP 块之类的方式处理，直到达到特定大小才将其发送给客户端。有些防火墙在接收到完整的请求并能够完整地对其进行检查后才会将 HTTP 请求发送到服务器。有时候可以通过设置更改此行为，但其他时候则不行。

浏览器并没有做好处理流的准备

现有的 API 没有针对发送简单数据块和接收简单数据块进行优化。这有时候是通过实现新客户端 Applet 或类似的东西来实现的，但目前很难对其进行支持。大部分人都返回到混合轮询机制，在独立连接中发送数据。