反向AJAX（服务器推技术）

服务器推技术介绍

　　HTTP是一种“无状态的协议”，也就是不知道以前请求的历史，无法保留上一次请求的结果。
　　Cookie的诞生，弥补了这个不足，浏览器可以通过本地持久化请求数据来记录上次请求的环境。但这个没有根本上改变HTTP请求本身的这种“客户端请求服务器端相应”模式——客户端是主动的，而服务器是被动的。
　　“HTTP长连接”能够实现“服务器推”的这种概念，也就是服务器是主动发送请求，客户端是被动接受请求。
　　HTTP长连接这种把数据从服务器主动“推”到客户端的技术，能带来的好处不言而喻。它可以把最新的统计数据输出到客户端，也可以实现即时通讯。

首先阐明服务器推的几种可能

对几种“推”技术进行简单的描述

　　第一种情况 polling 可以解释为轮训，类似心跳检测的方式。
只客户端按照一定的时间间隔定期请求服务器，在这个过程中可能没有任何事情发生，此时的操作完全是浪费网络资源。不过这也是最简单、最容易理解的方式。
　　其存在的缺点也是不言而喻，首先是请求的间隔控制，间隔太久就会失去意义，间隔太短就会额外增加服务器的压力。最最关键的是其无法保证服务器事件的实时性，即你不能保证服务器上事件发生的时候客户端可以及时检测到。
　　第二种方式 long poll 可以解释为长轮询，即服务端阻断前一次对客户端的回应，在事件发生后将事件内容绑定在回应中返回给客户端，同时回应结束，此时客户端立即发送第二次请求，服务器阻塞回应等待下一次事件发生。
此方法与第一种方法相比已经增色不少，大大降低了网络的利用率，即在没有事件的前提下，理论上没有数据交互，同时也是最最重要的一点是它体现了很强的实时性，即服务器端发生事件后客户端能第一时间收到信息。
　　第三种stream 没有合适的翻译。
　　按照现有的技术判断，这已经是终极了。即服务器阻断客户端的回应，和第二种方式相似，重要的是服务器没有关闭回应而是一直保留这这个到客户端的输出流。与第二种相比确实是一个很到的进步。

“服务器推”技术的应用

　　传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：

监控系统：后台硬件热插拔、LED、温度、电压发生变化；
即时通信系统：其它用户登录、发送信息；
即时报价系统：后台数据库内容发生变化；

　　这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。

基于 HTTP 长连接的“服务器推”技术

Comet 简介

　　浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。
　

　　　　图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较

　　下面将介绍两种 Comet 应用的实现模型

基于 AJAX 的长轮询（long-polling）方式

　　如图1所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于：

服务器端会阻塞请求直到有数据传递或超时才返回。
客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。

基于长轮询的服务器推模型

　
　　　　图 2 基于长轮询的服务器推模型

　　一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。

　　在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持， 即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。
基于 Iframe 及 htmlfile 的流（streaming）方式

　　iframe 是很早就存在的一种 HTML 标记， 通过在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。

　
　　　图 3. 基于流方式的服务器推模型

　　上节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据，然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端，iframe 服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

　　从 图 3 可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接， 服务器端可以设置一个超时时间， 超时后通知客户端重新建立连接，并关闭原来的连接）。