首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 网站开发 > PHP >

PHP ServerPush (推送) 技术的研讨

2013-11-15 
PHP ServerPush (推送) 技术的探讨需求:我想做个会员站内通知的功能。不想用以前的ajax查询,听说有个推技术

PHP ServerPush (推送) 技术的探讨

需求:

我想做个会员站内通知的功能。不想用以前的ajax查询,听说有个推技术。以下文章介绍的不错,来自转载,

==================================================================================

PHP中Push(推送)技术的探讨? [http://vistaswx.com/blog/article/php-server-push]

?

随着人们对Web即时应用需求的不断上升,Server Push(推送)技术在聊天、消息提醒尤其是社交网络等方面开始兴起,成为实时应用的数据流核心。这篇日志试图探讨的便是各种适合于PHP的Push的实现方式以及其优劣。

1. 什么是Server Push

想象在聊天应用中,如果使用传统的ajax来承担消息的传入,那么一般是通过每隔一定时间拉取一次信息的方式实现,但是其实这种方式有大量查询是浪费的。聊天等Web应用更需要服务器在特定时间来主动告知前端有新的消息(Push),而不是前端每时每刻问服务器:“来消息了吗?”(Pull)。这也正是为什么这个技术常被叫做反向ajax。

其他别名:Comet,反向Ajax

?

2. 如何实现Push

其实所谓的推送技术也没有多么复杂,目前从大类上有3种,一种仍然建立在ajax基础上,还有一种建立在框架基础上,最后一种抛弃了传统的HTTP协议,使用Flash或者HTML5的WebSockets技术。接下来将对这三种类别产生的不同的方式进行探讨。

1) Ajax 长轮询

Ajax长轮询从本质上来说仍然是一种pull,但是实时性较高,无用请求减少很多,是一种不错的Push实现方案。不过它只减少了网络上的无谓消耗。

核心:?客户端发起一个ajax请求,服务端将请求搁置(pending)或者说挂起,直到到了超时时间(timeout)或需要推送时返回;客户端则等待ajax返回后处理数据,再发起下一个ajax请求。

优点:?兼容性较高,实现简单

缺点:?对于php这种语言来说,如果要做到实时,那么服务端就要承受大得多的压力,因为搁置到什么时候往往是不确定的,这就要php脚本每次搁置都进行一个while循环。
当然,如果服务器刷新每秒级,那尚可接受,只是实时性上退化了。

注意:?浏 览器有连接数限制。我得出的结论是如果当前页面上有一个ajax请求处于等待返回状态,那么其他ajax请求都会被搁置(Chrome, Firefox已测)。如果页面有一般ajax需求怎么办?解决方法是开个框架,框架中使在另一个域名下进行Comet长轮询,需要注意跨域问题。

PHP实现:?Jquery+php实现comet

相关:Ajax跨域和js跨域解决方案

?

2) Frame 长连接

受到ajax启发,出现了框架下的长连接。

核心:?Frame中发起一个普通请求,服务器将其搁置;需要推送时输出直接执行
脚本,然后继续保持连接。如果担心超时问题可以改成框架论询。

优点:?与1一样具有高兼容特性

缺点:?最大的问题是如果框架在载入,那么浏览器就好一直显示“载入中”,这就弱爆了(解决方法参见文末的相关阅读资源)。同样服务器也要能hold住大量循环……另外,是否有同域连接限制没测试。

?

?

3) Flash/HTML5 WebSockets

用flash来发起WebSockets,秒杀前面一切问题。

优点:?标准化, RealTime, Push

缺点:?服务器需要能应对WebSockets;还有如果既没有Flash又不支持HTML5的怎么办?

PHP实现:?Start Using HTML5 WebSockets Today

?

6) 使用兼容封装层(socket.io)

以上每种方法都有优劣,那么终极解决方案便是合在一起!能WebSockets时候就WebSockets,不支持HTML5特性就退化到Flash,没有Flash则退化到Ajax长轮询。这也是我的Rainbowfish所采用的方式。

优点:?高度封装,编写非常容易,几乎不需要关心如何去实现的。实时,超低负载,高并发。

缺点:?其实算不上缺点,socket.io的服务器端要求是node.js,而不是php。

个人看法:?如果你是独立主机,能运行程序,那么socket.io配合node.js是个非常高效的选择。为什么呢?因为它还可以避免php的服务端高负载。

Rainbowfish 的消息系统通过这种方式实现: 所有客户端都通过socket.io挂在nodejs服务器上(注意: 只是挂着,不需要任何循环,因为它是事件驱动的);需要推送消息了,服务器就与nodejs通信(比如访问某个地址来实现),告诉它推送什么消息到哪 里;nodejs收到推送信号后,则通过socket.io实时传输数据给浏览器。这个其实也是一条单向的路,因为nodejs服务器不具备与php通信 的能力,实际上也不需要,网页上直接连php就可以了。

?

3. 结束语

事 实上,第一个方法(Ajax Long Pull)是一个不错的方法,只是如果使用php完成的话服务器负载上有点大,但这其实是通病;而最后列举的socket.io方案完全避免了这个问题, 因为它属于另一种架构,并且这种组合也可以配合几乎所有的脚本语言实现push。

对于实时性要求非常高的应用,或许使用php实现实时部分并不是一个好的选择,将会面临非常大的服务器负载(可以通过编写支持等待事件的扩展来解决这个问题);如果只是消息提示等,则可以调整服务器上刷新的间隔降低到秒的级别,负载尚可接受。不过无论哪种用途,配合那些非阻塞语言或许才是最好的选择。

4. 相关阅读

How to implement COMET with PHP

Start Using HTML5 WebSockets Today

Comet(Wikipedia)

Ajax跨域和js跨域解决方案

Jquery+php实现comet

==============================================================================================

?

comet研究[http://lync.in/research-on-comet/]

?

在 Web应用中,客户端的AJAX技术已经非常普遍也非常深入人心了,但与此同时,另一些应用,诸如在线监控,实时数据显示,即时通讯等需要将后台数据变化 情况实时显示到前台,这样的由服务器push的行为(也许会让你想到blackberry)则需要另一种方案来解决,也就是本文所要介绍的Comet —— 无需安装插件,保持http长连接的服务器推方案。
以下两点是方案中必须顾及到的。

  1. 浏览器通用性,对各种不同实现结构模型的支持。
  2. 长连接对于服务器资源的占用,以及服务器的承受能力

Comet的客户端与服务端交互流

业界对于Comet实现有两种主要的解决方案:

  1. 基于AJAX的轮询(long polling)方式

    这种方式就是由客户端发出AJAX请求,然后服务端阻塞请求直至有响应或超时。客户端在接收到服务端的指令之后会进行响应并发出新的请求。

    从 实现层面上来说,当XMLHttpRequest的状态为4也就是load的状态时会进行客户端处理,而Gecko(Firefox)和 Webkit(Chrome,Safari)目前支持在readystate为3的时候读取(当然只能读取到所有该请求已返回的串内容,所以需要自行确定 指令边界),Trident(IE)目前如果中途去读取会抛出错误,IE8中使用XDomainRequest可以适当解决这个问题(参见Eric Law的COMET Streaming in Internet Explorer[])。

    目前,开心网采用的是这一种方式。

  1. ?
  2. 基于iframe及htmlfile的流(streaming)方式

    这种方式是使用了iframe的机制,然后使得这个iframe请求一个特定的URL,并通过对这个页面的加载不断的从服务端抓回数据,这里从服务端抓回的数据大多是对页面当前JavaScript函数的引用和操作。

    这个方案的一个明显不足之处是页面会一直显示正在加载,而这在IE上会更明显。Google的天才们想到了用htmlfile的ActiveX控件来解决这个问题的方案,详细描述可以参见Alex Russell的What else is burried down in the depth's of Google's amazing JavaScript?

    目前,人人网和GTalk采用的是这种方式。

除了文首所提到的通用性和性能之外,还有几点是需要列入考量范围的。

  1. 数据交换的格式。由于数据交换的形式是推送,所以不可避免的会有指令队列的存在,于是数据结构是需要前后台详细约定的,执行指令和数据指令都需要有严格的界定,一般来说,JSON的方案比较普遍。
  2. 浏览器本身的连接数限制。HTTP 1.1规范中声明客户端不应该与服务器端建立超过两个的 HTTP 连接,而IE又严格遵守了这一点,所以前台在处理请求的时候需要谨慎控制请求的数量。

其实,Comet技术在AJAX大红大紫的2005年之后的2006年时是业界一个很热的讨论点,目前的这两种方式非常成熟,在dojo,dwr等前端框架中都已经有这样的实现,而Bayeux协议的出现也已经在实质上订下了一种业界的标准。

Comet的框架前端有Pushlet,dwr和dojo等,服务端有Jetty,Meteor,Orbited,Glassfish,Alpha,实现的产品语言也覆盖了Java,C++,Python,Perl,Ruby,Erlang,.Net等。

下一代HTML5中的WebSocket会是Comet的一个新起点,但在那之前,在非插件的web层面应该不会有更进一步的讨论与技术出现。

本文只是对Comet这个技术进行大体的概述,粗陋不明之处难免,在后续的文章中将会对WebSocket进行一定的解释和演示。

参考资料:

  • 这里有一个php的comet的例子How to implement COMET with PHP。这个要看看
  • 这是developerWorks上对于Comet的介绍。
  • 这是当前Comet的服务器端的一些产品及介绍。
  • 当然,Wikipedia上面对Comet的解释也是非常详尽。
  • 还可以看看AjaxPatterns上面的一些介绍。
  • 最后,CometDaily是个值得去了解最新Comet新闻和知识的地方。
  • =====================================================================================================

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

    ? [http://www.ibm.com/developerworks/cn/web/wa-lo-comet/]

    ps:上述文章应该够你看明白的了。使用一种吧。但我现在还没有在项目用推技术,原因,还没有来得及折腾,但在本地测试都很正常 。

    以下提供protype 和 jquery的 +php实现的代码例子。[例子代码来自网上,已测试通过。好用]

    http://bbs.php100.com/read-htm-tid-290215-ds-1.html

热点排行