短轮询也称为高频轮询，就是我在本文开头处介绍的技术。这种方法在以下情况中表现最好：
- 有足够的带宽可用。
- 根据统计数据，大多数时候，请求都能获得更新。例如，股市数据就总是有可用更新。
- 使用 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（基于文本）格式。
在这篇文章中，我要强调的是如何真正地绕开第三个和第四个问题。如果您能够处理安全性和防火墙问题，那么其他问题也能得到处理。这种做法的获益极为显著。
您可为应用程序实现最大程度的实时服务器推送行为（不考虑网络延时等外部因素），您将获得高度可伸缩的解决方案（以同时连接的客户端数量为准）。
没有评论:
发表评论