HTTP 推技术(Murphy Push)

http://www.cnblogs.com/chinhr/archive/2008/08/07/1262553.html

现在越来越多的系统使用BS框架来开发系统，使用BS框架来开发系统在很多方面都有优势。例如系统的维护部署，系统维护的复杂度等等。基本上可以通过简单的配置或者根本不需要配置就可以通过IE等各种浏览起来进行业务操作，报表查看，数据统计等。并且他是基于HTTP通信协议，这就保障了系统借用Internet的国际化，可以在世界的任何地方，就像浏览其他门户网站一样简单的来完成各种操作。但是事情总是有两面性，当我们需要实时的或者及时地通过BS框架系统来获得最新的业务数据等信息时就变得异常困难。我这篇文章就是简单的分析一下如何通过HTTP来实时的从服务器端发送数据到客户端。很多时候我们管它命名为推技术。

 

第一部分：实时系统

 

在实现实时系统的时候，我们一般会采用两种截然不同的思想来实现。

 

一种是推技术：他是指从服务器端来发起，根据最新信息的状态，来判断是否来发送最新的数据。如果需要发送，根据发送规则来以广播的形式群发，发送对象也许是所有订阅者，也许只是部分订阅者。

 

另外一种技术是拉技术： 拉技术是指客户端来发起，一般是以一定的周期频率来发送请求，请求服务器端来获得最新的信息，服务器根据请求，判断搜索最新的数据，返回给客户端，但不是每次都有新信息可以获得，所以空返回占有绝大多数。

 

使用这两种技术的系统都不在少数，但如果需要对性能要求很高的系统来说推技术无疑是首选。我们可以从以下几个方面来分析。

	推技术	拉技术
系统性能	只在服务器运行，可以通过事件方式，例如更新数据时等来实时传送数据，或一定的周期或频率来判断发送数据。只占用一个CPU的资源。	在每个客户端设备上运行，一般是以一定的周期频率来获得信息。占用所有客户端CPU的资源。
信息/发送	每次发送的都是有效信息。	大多数是空返回。
网络资源	最优化网络传输。	占用大量的传输来做请求。
数据实时性	可以实时的或地数据也可以一定周期的获得数据。	一定周期的获得数据。

 

我的分析也许还不透彻，或者分析项目还很少，但他们很重要，尤其在数据的实时性和性能上，在浪费大量计算机和网络资源后而无法获得实时的数据。拉技术似乎让我们非常失望，但我们不能忽略系统的运行环境，例如我曾参与开发的一套基于BS的实时设备操作系统，便是使用ActiveX控件来周期性的从服务器端拉数据，或者有些系统需要JS的setTimeout()函数来拉数据。但这毕竟是少数。而大多数例如现在非常流行的魔兽服务系统是基于socket的推技术。而且是根据登陆的游戏玩家Id，人物位置等信息来筛选数据推。或者我们在线电视，或者某些Email都是推技术来完成的。但我们似乎发现了一个规律，就是如果系统是架构在HTTP协议上的，基本是采用拉技术，而系统采用socket完成数据通信的，基本都是推技术。原因其实很简单，就是HTTP协议很难实现推技术，存在一定的复杂度和技术风险。

      

       基于HTTP协议的BS系统是否需要推技术。答案是显而易见的。需要，并且有些类型系统非常需要。我之前完成过很多BS系统，有OA，ERP，SCM等等，如果客户不点击按钮或链接，数据永远都是过时，这样客户在业务判断和处理就有很大的迷惑性，错误在所难免，而且数据的验证也只能在服务器端完成才能算完成，客户端很难针对已存在数据进行有效的校验。有些方法可以降低其发生度，例如用尽量少的一次显示数据，多进行与服务器交互，但这并不能解决实际问题。

 

第二部分：HTTP 推技术

 

我们知道，如果实现推技术，必须需要几点条件。

一是客户端一直侦听某个端口，得到信息后事件触发后进行处理。

还有就是服务器端可以获得客户端的IP地址和端口，并且可以永久的发送数据。

 

如果是一个基于Socket的CS架构系统，实现这两点并不困难，但如果是基于浏览器和服务器的Web服务程序一起来完成这个任务，就比较困难了。首先HTTP是请求应答式的，请求是客户端发起的，在得到服务器端的应答后，便会自动关闭TCP通道，在下一次请求时在开新的。这样我们无法得到稳定通信通道，服务器便无法发送信息到客户端。

 

还有就是一般的Web服务程序例如IIS的运行模式也是基于请求应答式的运行。请求来了，服务初始或所有内存变量，程序和页面，调用程序，根据请求和业务规则返回应答，然后释放所有内存等资源，等待下一次的请求。而推技术的服务程序是需要永久运行的，并可以不断地接收或主动获得最新的数据，根据规则来分发数据。

 

如果能够解决以上两个难点，实现推技术，便不再困难。实际现在已经存在使用HTTP 推技术的系统，例如很多的基于网页的聊天室。那么他们到底是如何实现的呢，在.NET 框架下又如何更好的实现这项技术，并可以为更多种的系统提供稳定，可靠的实时服务是我下面章节所有介绍的。

 

第三部分：实现

 

如何让浏览器实时的监控端口，并不断的获得最新数据呢？我们知道浏览器每次与服务器交互都会打开两个端口，其中一个端口就是用来接收服务器的应答数据包，直到得到结束包后就停止监听端口，完成一次请求应答。但如果服务器端不发送结束包，那么浏览器就会一直监听端口，这样我们可以利用HTTP协议的这个特点，一直不发送结束包，来让浏览器一直处于监听状态，这样服务器就有足够的时间来获得最新的数据来发送到客户端。并且我们可以在网页中添加一个“iframe”标签，或者通过脚本来添加这个标签，其“src”属性为一个特殊的实时数据通信网页。我们可以把这个侦叫做“实时通信侦”。并且添加一些处理，例如，如果iframe结束链接或全部装载完成后重新链接。

 

       服器器如何不发送结束包。一个简单的解决方案就是，在服务器处理过程时处于循环状态，在循环过程中发送数据而不结束这个处理过程，而导致发送结束包。并且结合全局静态变量或类实例，其他的页面模块更新静态变量，利用事件机制通知循环中的过程，来发送最新的数据包。这样如果你更新数据和实时显示数据是在一个程序域中便可以实时的显示数据了。但这种处理方式有几个明显的命题。一个是一般的web服务程序的链接和线程数量都是有限的，如果过多地占用这些资源便会使整个系统的性能下降，并且无法满足大量用户的链接使用。第二是数据的更新并一定在web程序中进行，例如其他业务的系统更新的是数据库，但无法通知web程序来实时获得最新数据。如果在循环过程中不停的去到数据库或什么数据源去判断是否有最新的数据。这样我们又会回到数据不能是实时这个问题上来。如果要解决这个问题，我们就必须有一个实时通信服务来解决以上所有的问题。

 

       这个服务必须能够截获所有需要实时通信的HTTP的请求，并能够返回应答。这是HTTP服务的基本要求，而且可以能够提供接口来供其他应用程序通过各种方式来调用，传送最新的数据或命令。如下图所示。

不同变成语言和相应的技术都有其解决方式，我是使用.NET 来实现的，我在这里就不详细谈了。

 

结束语

不使用任何其他技术和工具的帮助便可以实现基于HTTP协议的推技术，并且在服务器端提供一个推服务来完善整个系统架构，是实现这项技术的关键。在不同环境实现这种思想都会存在一定的难度，但所表现的技术优势和性能的提高我们所付出的是值得的。同时也希望大家提出更好的解决方案。

分类:  操作系统