您有两个选择（其他选择已在上面详述）。如果您不熟悉每个选项背后的一些概念性想法，我想我会就它们给出一两行。请注意，我是在非常非常高的层次上介绍这些概念。

您的三个选择是：

1. 短轮询
2. 网络插座
3. 彗星/长轮询

短轮询

短轮询 通过强制客户端向表单服务器连续发送请求，从而克服了客户端与服务器之间的单向通信：

Client: Do you have a message for me?
Server: No.
Client: (wait x seconds)
Client: Do you have a message for me?
Server: No.
Client: (wait x seconds)
Client: Do you have a message for me?
Server: Yes. Here it is!
Client: Yay!
Client: (update message)

代表客户的持续na叫 轮询
。为了实现此结构，您需要将服务器设置为“侦听”来自客户端的这些轮询请求。服务器还必须将这些消息存储在某个地方，以便在消息准备就绪时，服务器可以传递它们。在非常简单的级别上，您的服务器需要：

• 接受一般的网络请求
• 接受轮询请求
• 运行后台作业以获取消息
• 将这些消息存储在某处，以便在收到轮询请求时，服务器可以对其进行检查。

您还需要将这些轮询请求与用户的某种会话ID绑定在一起，以便正确的消息到达正确的人。总体而言，该范式很复杂，我认为效率很低。

网络插座

Web套接字是HTML5的新功能。它们背后的基本思想是，客户端可以保持与服务器的直接连接，并且它们可以相互来回 推送
信息。因此，与通常的情况不同：客户端发送GET请求>>服务器以内容进行响应，Web套接字使您可以保持连续的对话。

为了进行此设置，您需要：

• 兼容WebSocket的浏览器（并非全部）。
• 可以处理Web套接字的服务器（不确定如何明确说明，但并非所有服务器都针对这种设置而设置）。

设置有些复杂，尽管比长轮询更简单：

• 客户端维护与已启用Web套接字的服务器的连接
• 服务器通过Web套接字 将 结果 推 送到客户端
• 客户端根据结果更新页面

您将看到称为“ 推送通知”的 这种模式（当然，如果您拥有iPhone，您会遇到这种情况），因为服务器已被授权 将 “内容” 推
送到客户端（多么不礼貌！）。由于客户端和服务器之间存在许多细微差别，因此我建议您测试一下Pusher之类的东西，它基本上是一种Web服务，用于处理Web套接字的所有困难部分。在您自己进行设置之前，这将是您测试并使用模式的一种简便方法。它同时具有客户端和服务器端库。

希望这些信息能为您解决问题提供基线。其他答案对如何解决每种情况有更直接的信息。

彗星/长轮询

Web套接字的另一种看似跨浏览器的方法是长轮询（请参阅Comet）。在这种情况下，您的客户端将建立与服务器的连接，并使其保持挂起状态，等待数据被推送回去。这样做的设置有些复杂，但确实代表了
Short Polling 和 Web Sockets 之间的中间立场。