不久前，我们收到一个关于如何在 lighttpd 中实现 COMET 的请求。我提出了一个关于 mod_multiplex 的想法，它将允许客户端打开一个 COMET 通道，并使后端能够同时向多个通道推送数据，以便客户端轮询新数据。

基本上，它将 HTTP 请求-响应周期与底层连接分离。 HTTP 将用于打开连接并在连接断开时重新打开，但除此之外，它将只是一个数据通道，用于在我们（内容提供者）需要时向客户端发送 JavaScript/AJAX 内容。

让我们再次引用我对 COMET 的理解

我对此的想法是将请求与 COMET 流解耦。
AFAI（据我所知）理解 COMET，它是一个“一个接收者-多个发送者”的概念。
通道（一个 HTTP 响应）保持打开状态，服务器/应用程序即使没有浏览器交互也能向客户端发送多个响应。

这就是你在网页聊天应用程序中看到的功能，或者用于向大量用户实时发送股票报价的功能。

在经典的 HTTP 世界中，你必须每隔几秒钟就轮询一次新数据，或者保持连接打开并让它流式传输数据给你。轮询不是即时的，即使没有数据也会产生负载。流式传输会将 FastCGI（或类似）后端绑定到连接上，这会限制并行用户的数量。

将连接与内容解耦

我们希望

• 服务器和客户端之间建立持久连接，以最大限度地降低设置成本（保持连接）并实现即时响应
• 一种将数据从后端发送到多个连接的方式
• 只运行后端以生成内容

由于这不符合经典模型，我们必须稍微打破它。经典模型意味着

1. 服务器读取 HTTP 请求
2. 服务器将请求转发到后端并等待其响应
3. 服务器将 HTTP 响应发送到客户端

一旦后端关闭与服务器的连接，服务器将假定没有更多数据可传输，并等待下一个客户端请求。

这就是我们想要改变的。我们希望将后端与客户端连接解耦。更进一步，我们想实现一个我们非常熟悉的东西：一个邮箱。

在邮箱中排队消息

如果你在家时，邮递员按了两次门铃……嗯，让我们重新开始。

如果你在家时邮递员送信，你可以马上阅读。他按门铃，你打招呼，收信，阅读。

如果你在办公室努力工作，邮递员也会送达信件，只是送到你的邮箱。实际上，好几家公司都会把信件、包裹……都送到你的邮箱。你回家时再去取。

mod_mailbox

首先我们需要为邮箱命名。客户端在服务器上打开一个邮箱，服务器将客户端连接绑定到此邮箱，并立即将为该邮箱收到的所有数据发送到客户端。

如果客户端断开连接，它要么重新建立连接，要么服务器会在一段时间后移除该邮箱。

后端照常启动，可以将其响应发送到多个邮箱，无需关心连接是否建立或断开。它只交付给 mod_mailbox 管理的邮箱（队列）。

如果后端在连接暂时关闭时向邮箱传递了新内容，那么一旦客户端重新打开邮箱，内容就会立即发送。

我能用它吗？

暂时不能。这是一个如何以优雅且高性能的方式实现 COMET 的想法。在通往 1.5.0 的路上它将被实现。同时，我正在征求对此想法的评论，以及它是否符合您对 COMET 和 AJAX 的需求。