在 Ajax 应用程序中实现实时数据推送 -2 Ajax 应用程序中的服务器更新技术

look_w

Ajax 应用程序中的服务器更新技术让我们来具体看看用于更新来自服务器的信息的一些常用技术，这些技术模拟了服务器推送。
短轮询短轮询也称为高频轮询，就是我在本文开头处介绍的技术。这种方法在以下情况中表现最好：

• 有足够的带宽可用。
• 根据统计数据，大多数时候，请求都能获得更新。例如，股市数据就总是有可用更新。
• 使用 HTTP 1.1 协议。设置 keepAlive=true，因而，同一个套接字连接始终保持活动状态，并可重用。

长轮询长轮询是用于更新服务器数据的另外一种方法。这种方法的理念就是客户端建立连接，服务器阻塞连接（通过使请求线程在某些条件下处于等待状态），有数据可用时，服务器将通过阻塞的连接发送数据，随后关闭连接。客户端在接收到更新后，立即重新建立连接，服务器重复上述过程，以此实现近于实时的通信。然而，长轮询具有以下缺陷：

• 一般的浏览器默认允许每台服务器具有两个连接。在这种情况下，一个连接始终是繁忙状态。因而，UI 只有一个连接（也就是说，能力减半）可用于为用户请求提供服务。这可能会导致某些操作的性能降低。
• 仍然需要打开和关闭 HTTP 连接，如果采用的是非持久连接模式（keepAlive=false），那么这种方法的代价可能极高。
• 这种方法近于实时，但并非真正的实时。（当然，某些外部因素总是不可控的，比如网络延时，在任何方法中都会存在这些因素。）

流通道流通道（streaming channel）与长轮询大致相同，差别在于服务器不会关闭响应流。而是特意保持其处于打开状态，使浏览器认为还有更多数据即将到来。但是，流通道也有着自己的缺陷：

• 最大的问题就是数据刷新（flushing）。过去，Web 服务器会缓存响应数据，仅在接受到足够的字节数或块数后才会发送出去。在这种情况下，即便应用程序刷新数据，也仍然会由服务器缓存，以实现优化。更糟的是，如果在客户端和服务器之间存在代理服务器，那么代理也可能会为自身之便缓存数据。
• 如果发现套接字将打开较长的时间，某些浏览器实现可能会自行决定关闭套接字。在这种情况下，通道需要重新建立。

通常，第一个问题可通过为每个流响应附加垃圾有效载荷来解决，使响应数据足以填满缓冲区。第二个问题可通过 “保持活动” 或按固定间隔 “同步” 消息来欺瞒浏览器，使浏览器认为数据是以较慢的速率传入的。
这些解决方案适用的用例范围狭窄。所有这些方法都已经在 Internet 上的某些解决方案中得到了应用。然而，这些解决方案都遭遇了相同的问题：缺乏可伸缩性。典型情况下，要阻塞一个请求，您需要阻塞处理请求的线程，因为如今几乎所有应用服务器都会执行阻塞 I/O。即便不是这样，Java™ 2 Platform, Enterprise Edition (J2EE) 也未提供为 HTTP 请求和响应执行非阻塞 I/O 的标准。（Servlets 3.0 API 可解决这一问题，因为这些 API 中包含 Comet Servlet。）
至此，您需要具备非阻塞 I/O（NIO）服务器，客户端应用程序通过它进行连接。由于此类套接字是纯 TCP 二进制套接字，因而将实现以下目标：

• 由于服务器端具有 NIO，因而可实现更高的可伸缩性。
• 响应缓存的问题不复存在，因为这个套接字直接受应用程序的控制。

基于上述说明，有必要指出这种方法的四个缺点：

• 由于使用的是二进制 TCP 套接字，因而应用程序无法真正地利用 HTTPS 层提供的 SSL 安全性。所以，要求数据安全性的应用程序可能需要提供自己的加密工具。
• 通常情况下，服务器套接字将在 80 以外的端口上运行，如果防火墙仅允许来自端口 80 的流量，将出现问题。因而，可能需要进行一些端口配置。
• Ajax 客户端无法通过后端打开 TCP 套接字连接。
• 即便 Ajax 客户端能够执行 open 函数，也无法理解二进制内容，这是因为 Ajax 使用的是 XML 或 JSON（基于文本）格式。

在这篇文章中，我要强调的是如何真正地绕开第三个和第四个问题。如果您能够处理安全性和防火墙问题，那么其他问题也能得到处理。这种做法的获益极为显著。
您可为应用程序实现最大程度的实时服务器推送行为（不考虑网络延时等外部因素），您将获得高度可伸缩的解决方案（以同时连接的客户端数量为准）。
下面我们将开始探索如何解决上述的第三个和第四个问题。