你的三个选择是：

>短轮询
> Web Socket
> Comet / Long-Polling

短轮询

短轮询通过强制客户端不断向表单的服务器发送请求来克服Client-Server之间的单向通信：

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)

代表客户的不断唠叨称为轮询.为了实现此结构,您需要将服务器设置为“侦听”来自客户端的这些轮询请求.服务器还必须在某处存储这些消息,以便在消息准备就绪时,服务器可以提供它们.在非常简单的级别,您的服务器需要：

>接受一般Web请求
>接受轮询请求
>运行获取消息的后台作业
>将这些消息存储在某处,以便在轮询请求进入时,服务器可以检查它们.

您还需要将这些轮询请求绑定到用户的某种会话ID,以便正确的消息到达正确的人.总的来说,范式很复杂,在我看来,效率低下.

Web套接字

Web套接字是HTML5的新增功能.它们背后的基本思想是客户端可以保持与服务器的直接连接,并且可以相互推送信息.因此,而不是通常：客户端发送GET请求>>服务器响应内容,Web套接字允许您保持持续对话.

但是,为了进行此设置,您需要：

>符合WebSocket的浏览器(并非所有浏览器都是).
>可以处理Web套接字的服务器(不确定如何清楚地说明这一点,但并非所有服务器都设置为这种安排).

设置有点复杂,虽然比长轮询更简单：

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

你会看到这种模式被称为推送通知(当然,如果你拥有一台你已经体验过的iPhone),因为服务器已被授权将“东西”推送给客户端(多么不礼貌！).由于存在许多客户端和服务器的细微差别,我建议测试像Pusher这样的东西,它基本上是一个Web服务来处理Web套接字的所有难点部分.在开始自己设置之前,这将是一种简单的方法,您可以测试和玩模式.它有客户端和服务器端库.

希望信息为您提供解决问题的基准.其他答案有关于如何解决每个方案的更直接信息.

彗星/长轮询

另一种看似跨浏览器的Web套接字方法是Long-Polling(见Comet).在这种情况下,您的客户端建立与服务器的连接并使其挂起,等待数据被推回.这种设置有点复杂,但它确实代表了短轮询和Web套接字之间的中间地带.