英文原文： Reverse Ajax,Part 1: Introduction to Comet

在过去的几年中，web开发已经发生了很大的变化。现如今，我们期望的是能够通过web快速、动态地访问应用。在这一新的文章系列中，我们学习如何使用反向Ajax（Reverse Ajax）技术来开发事件驱动的web应用，以此来实现更好的用户体验。客户端的例子使用的是JQuery JavaScript库，在这首篇文章中，我们探索不同的反向Ajax技术，使用可下载的例子来学习使用了流（streaming）方法和长轮询（long polling）方法的Comet。

　　前言

@H_502_8@　　web开发在过去的几年中有了很大的进展，我们已经远超了把静态网页链接在一起的做法，这种做法会引起浏览器的刷新，并且要等待页面的加载。现在需要的是能够通过web来访问的完全动态的应用，这些应用通常需要尽可能的快，提供近乎实时的组件。在这一新的由五部分组成的文章系列中，我们学习如何使用反向Ajax（Reverse Ajax）技术来开发事件驱动的web应用。

@H_502_8@　　在这第一篇文章中，我们要了解反向Ajax、轮询（polling）、流（streaming）、Comet和长轮询（long polling），学习如何实现不同的反向Ajax通信技术，并探讨每种方法的优点和缺点。你可以下载本文中例子的相应源代码。

@H_502_8@　　Ajax、反向Ajax和WebSocket

@H_502_8@　　异步的JavaScript和XML（Asynchronous JavaScript and XML，Ajax），一种可通过JavaScript来访问的浏览器功能特性，其允许脚本向幕后的网站发送一个HTTP请求而又无需重新加载页面。Ajax的出现已经超过了十年，尽管其名字中包含了XML，但你几乎可以在Ajax请求中传送任何的东西，最常用的数据是JSON，其与JavaScript语法很接近，且消耗更少带宽。清单1给出了这样的一个例子，Ajax请求通过某个地方的邮政编码来检索该地的名称。

@H_502_8@　　清单1. Ajax请求举例

@H_502_8@　　在本文可下载的源代码中，你可在listing1.html中看到这一例子的作用。

@H_502_8@　　反向Ajax（Reverse Ajax）本质上则是这样的一种概念：能够从服务器端向客户端发送数据。在一个标准的HTTP Ajax请求中，数据是发送给服务器端的，反向Ajax可以某些特定的方式来模拟发出一个Ajax请求，这些方式本文都会论及，这样的话，服务器就可以尽可能快地向客户端发送事件（低延迟通信）。

@H_502_8@　　WebSocket技术来自HTML5，是一种最近才出现的技术，许多浏览器已经支持它（Firefox、Google Chrome、Safari等等）。WebSocket启用双向的、全双工的通信信道，其通过某种被称为WebSocket握手的HTTP请求来打开连接，并用到了一些特殊的报头。连接保持在活动状态，你可以用JavaScript来写和接收数据，就像是正在用一个原始的TCP套接口一样。WebSocket会在这一文章系列的第二部分中谈及。

@H_502_8@　　反向Ajax技术

@H_502_8@　　反向Ajax的目的是允许服务器端向客户端推送信息。Ajax请求在缺省情况下是无状态的，且只能从客户端向服务器端发出请求。你可以通过使用技术模拟服务器端和客户端之间的响应式通信来绕过这一限制。

@H_502_8@　　HTTP轮询和JSONP轮询

@H_502_8@　　轮询（polling）涉及了从客户端向服务器端发出请求以获取一些数据，这显然就是一个纯粹的Ajax HTTP请求。为了尽快地获得服务器端事件，轮询的间隔（两次请求相隔的时间）必须尽可能地小。但有这样的一个缺点存在：如果间隔减小的话，客户端浏览器就会发出更多的请求，这些请求中的许多都不会返回任何有用的数据，而这将会白白地浪费掉带宽和处理资源。

@H_502_8@　　图1中的时间线说明了客户端发出了某些轮询请求，但没有信息返回这种情况，客户端必须要等到下一个轮询来获取两个服务器端接收到的事件。

@H_502_8@　　图1. 使用HTTP轮询的反向Ajax

@H_502_8@

@H_502_8@　　JSONP轮询基本上与HTTP轮询一样，不同之处则是JSONP可以发出跨域请求（不是在你的域内的请求）。清单1使用JSONP来通过邮政编码获取地名，JSONP请求通常可通过它的回调参数和返回内容识别出来，这些内容是可执行的JavaScript代码。

@H_502_8@　　要在JavaScript中实现轮询的话，你可以使用setInterval来定期地发出Ajax请求，如清单2所示：

@H_502_8@　　清单2. JavaScript轮询

@H_502_8@　　文章源代码中的轮询演示给出了轮询方法所消耗的带宽，间隔很小，但可以看到有些请求并未返回事件，清单3给出了这一轮询示例的输出。

@H_502_8@　　清单3. 轮询演示例子的输出

@H_502_8@　　用JavaScript实现的轮询的优点和缺点：

@H_502_8@　　1. 优点：很容易实现，不需要任何服务器端的特定功能，且在所有的浏览器上都能工作。

@H_502_8@　　2. 缺点：这种方法很少被用到，因为它是完全不具伸缩性的。试想一下，在100个客户端每个都发出2秒钟的轮询请求的情况下，所损失的带宽和资源数量，在这种情况下30%的请求没有返回数据。

@H_502_8@　　Piggyback

@H_502_8@　　捎带轮询（piggyback polling）是一种比轮询更加聪明的做法，因为它会删除掉所有非必需的请求（没有返回数据的那些）。不存在时间间隔，客户端在需要的时候向服务器端发送请求。不同之处在于响应的那部分上，响应被分成两个部分：对请求数据的响应和对服务器事件的响应，如果任何一部分有发生的话。图2给出了一个例子。

@H_502_8@　　图2. 使用了piggyback轮询的反向Ajax

@H_502_8@　　在实现piggyback技术时，通常针对服务器端的所有Ajax请求可能会返回一个混合的响应，文章的下载中有一个实现示例，如下面的清单4所示。

@H_502_8@　　清单4. piggyback代码示例

@H_502_8@　　清单5给出了一些piggyback输出。

@H_502_8@　　清单5. piggyback输出示例

@H_502_8@　　你可以看到表单验证的结果和附加到响应上的事件，同样，这种方法也有着一些优点和缺点：

@H_502_8@　　1. 优点：没有不返回数据的请求，因为客户端对何时发送请求做了控制，对资源的消耗较少。该方法也是可用在所有的浏览器上，不需要服务器端的特殊功能。

@H_502_8@　　2. 缺点：当累积在服务器端的事件需要传送给客户端时，你却一点都不知道，因为这需要一个客户端行为来请求它们。

@H_502_8@　　Comet

@H_502_8@　　使用了轮询或是捎带的反向Ajax非常受限：其不具伸缩性，不提供低延迟通信（只要事件一到达服务器端，它们就以尽可能快的速度到达浏览器端）。Comet是一个web应用模型，在该模型中，请求被发送到服务器端并保持一个很长的存活期，直到超时或是有服务器端事件发生。在该请求完成后，另一个长生存期的Ajax请求就被送去等待另一个服务器端事件。使用Comet的话，web服务器就可以在无需显式请求的情况下向客户端发送数据。

@H_502_8@　　Comet的一大优点是，每个客户端始终都有一个向服务器端打开的通信链路。服务器端可以通过在事件到来时立即提交（完成）响应来把事件推给客户端，或者它甚至可以累积再连续发送。因为请求长时间保持打开的状态，故服务器端需要特别的功能来处理所有的这些长生存期请求。图3给出了一个例子。（这一文章系列的第2部分会更加详细地解释服务器端的约束条件）。

@H_502_8@　　图3. 使用Comet的反向Ajax

@H_502_8@　　Comet的实现可以分成两类：使用流（streaming）的那些和使用长轮询（long polling）的那些。

@H_502_8@　　使用HTTP流的Comet

@H_502_8@　　在流（streaming）模式中，有一个持久连接会被打开。只会存在一个长生存期请求（图3中的#1），因为每个到达服务器端的事件都会通过这同一连接来发送。因此，客户端需要有一种方法来把通过这同一连接发送过来的不同响应分隔开来。从技术上来讲，两种常见的流技术包括Forever Iframe（隐藏的IFrame），或是被用来在JavaScript中创建Ajax请求的XMLHttpRequest对象的多部分（multi-part）特性。

@H_502_8@　　Forever Iframe

@H_502_8@　　Forever Iframe（永存的Iframe）技术涉及了一个置于页面中的隐藏Iframe标签，该标签的src属性指向返回服务器端事件的servlet路径。每次在事件到达时，servlet写入并刷新一个新的script标签，该标签内部带有JavaScript代码，iframe的内容被附加上这一script标签，标签中的内容就会得到执行。

@H_502_8@　　1. 优点：实现简单，在所有支持iframe的浏览器上都可用。

@H_502_8@　　2. 缺点： 没有方法可用来实现可靠的错误处理或是跟踪连接的状态，因为所有的连接和数据都是由浏览器通过HTML标签来处理的，因此你没有办法知道连接何时在哪一端已被断开了。

@H_502_8@　　Multi-part XMLHttpRequest

@H_502_8@　　第二种技术，更可靠一些，是XMLHttpRequest对象上使用某些浏览器（比如说Firefox）支持的multi-part标志。Ajax请求被发送给服务器端并保持打开状态，每次有事件到来时，一个多部分的响应就会通过这同一连接来写入，清单6给出了一个例子。

@H_502_8@　　清单6. 设置Multi-part XMLHttpRequest的JavaScript代码示例

@H_502_8@　　在服务器端，事情要稍加复杂一些。首先你必须要设置多部分请求，然后挂起连接。清单7展示了如何挂起一个HTTP流请求。（这一系列的第3部分会更加详细地谈及这些API。）

@H_502_8@　　清单7. 使用Servlet 3 API来在servlet中挂起一个HTTP流请求

@H_502_8@　　现在，每次有事件发生时你都可以遍历所有的挂起连接并向它们写入数据，如清单8所示：

@H_502_8@　　清单8. 使用Servlet 3 API来向挂起的多部分请求发送事件

@H_502_8@　　本文可下载文件的Comet-straming文件夹中的部分说明了HTTP流，在运行例子并打开主页时，你会看到只要事件一到达服务器端，虽然不同步但它们几乎立刻会出现在页面上。而且，如果打开Firebug控制台的话，你就能看到只有一个Ajax请求是打开的。如果再往下看一些，你会看到JSON响应被附在Response选项卡中，如图4所示：

@H_502_8@　　图4. HTTP流请求的FireBug视图

@H_502_8@　　照例，做法存在着一些优点和缺点：

@H_502_8@　　1. 优点：只打开了一个持久连接，这就是节省了大部分带宽使用率的Comet技术。

@H_502_8@　　2. 缺点：并非所有的浏览器都支持multi-part标志。某些被广泛使用的库，比如说用Java实现的CometD，被报告在缓冲方面有问题。例如，一些数据块（多个部分）可能被缓冲，然后只有在连接完成或是缓冲区已满时才被发送，而这有可能会带来比预期要高的延迟。

@H_502_8@　　使用HTTP长轮询的Comet

@H_502_8@　　长轮询（long polling）模式涉及了打开连接的技术。连接由服务器端保持着打开的状态，只要一有事件发生，响应就会被提交，然后连接关闭。接下来。一个新的长轮询连接就会被正在等待新事件到达的客户端重新打开。

@H_502_8@　　你可以使用script标签或是单纯的XMLHttpRequest对象来实现HTTP长轮询。

@H_502_8@　　script标签

@H_502_8@　　正如iframe一样，其目标是把script标签附加到页面上以让脚本执行。服务器端则会：挂起连接直到有事件发生，接着把脚本内容发送回浏览器，然后重新打开另一个script标签来获取下一个事件。

@H_502_8@　　1. 优点：因为是基于HTML标签的，所有这一技术非常容易实现，且可跨域工作（缺省情况下，XMLHttpRequest不允许向其他域或是子域发送请求）。

@H_502_8@　　2. 缺点：类似于iframe技术，错误处理缺失，你不能获得连接的状态或是有干涉连接的能力。

@H_502_8@　　XMLHttpRequest长轮询

@H_502_8@　　第二种，也是一种推荐的实现Comet的做法是打开一个到服务器端的Ajax请求然后等待响应。服务器端需要一些特定的功能来允许请求被挂起，只要一有事件发生，服务器端就会在挂起的请求中送回响应并关闭该请求，完全就像是你关闭了servlet响应的输出流。然后客户端就会使用这一响应并打开一个新的到服务器端的长生存期的Ajax请求，如清单9所示：

@H_502_8@　　清单9. 设置长轮询请求的JavaScript代码示例

@H_502_8@　　在后端，代码也是使用Servlet 3 API来挂起请求，正如HTTP流的做法一样，但你不需要所有的多部分处理代码，清单10给出了一个例子。

@H_502_8@　　清单10. 挂起一个长轮询Ajax请求