Comet 的诱惑

为了更好地支持 Comet 流，需要进行什么工作？

我们认为，我们可以进行很多工作来更好地支持 Comet 样式应用程序。首先，我们需要处理上面的问题。

标准

HTTP 管道在很多人眼里不可行，因为它不允许在单个连接上按顺序发送数据块。通过序列号和请求标识，浏览器、防火墙、代理或应用服务器可以在单个连接上传送多个 Comet 流请求。

同步与异步

需要对我们的应用程序和基础设施进行更新，从而以异步方式处理所有东西。这就包括 HTTP Servlet 规范，这方面可以从 Jetty 中的 Continuations 支持或其他 SIP Servlet 的异步本质得到启发。我们大部分人都预期 Servlet 3.0 规范将采用异步方式进行处理。

有限的连接数量

如果有更为高级的 HTTP 管道支持，则可能就不需要处理这个问题了。但是，如果没有这方面的改进，系统则需要比目前更多的连接数量可用。

更好的 JavaScript API

需要更好的 API 来处理 Comet 流样式服务器端应用程序的成块消息的发送和接收。

处理了这些问题后，Comet 流将得到更广泛的接受，因为此模式可以帮助提高基于 Web 的界面的互操作性。股票报价、聊天、体育赛事比分以及很多应用程序都将得到广泛的应用，而且不会对基础设施造成太大的压力。到那个时候，我估计可能需要对 Internet 上的每个服务器软件进行检查，确定其是否能够应对这个新的基于 Comet 流的世界。

我们是否应该使用混合轮询？

混合轮询支持快速（但并不一定是即时的）通知。此方法之所以受到今天基础设施的青睐，是因为有以下这些原因：

Javascript API（具体来说就是 XMLHttpRequest）能更好地支持此方法。

混合轮询在服务器基础设施上更容易实现，因为请求之间有断层。

两个间隔（客户端轮询间隔和服务器在没有响应的情况下保持连接的时长）中较短的间隔将决定混合轮询将在基础设施上造成的资源使用影响。如果可能，请将服务器保持时间设置为最小，而将客户端轮询时间设置为最大。

现在我们能做些什么？

将您的 Comet 流使用限制为仅用于需要即时事件通知的应用程序。

使用支持更快事件通知但不会对基础设施造成大负荷的方法，如混合轮询。调整混合轮询时间，以让连接尽可能多地关闭。

了解您所购买的新基础设施的限制。例如，如果您购买防火墙，如果知道以下信息将很有帮助：其可以处理的最大连接数、是否支持 Comet 样式应用程序以及所需的功能（如入侵检测）是否需要对消息进行缓存。