轉(zhuǎn)自：http://blog.163.com/bailin_li/blog/static/17449017920124811524364/

需求：

我想做個會員站內(nèi)通知的功能。不想用以前的ajax查詢，聽說有個推技術(shù)。以下文章介紹的不錯，來自轉(zhuǎn)載，

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

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

?

隨著人們對Web即時應(yīng)用需求的不斷上升，Server Push(推送)技術(shù)在聊天、消息提醒尤其是社交網(wǎng)絡(luò)等方面開始興起，成為實時應(yīng)用的數(shù)據(jù)流核心。這篇日志試圖探討的便是各種適合于PHP的Push的實現(xiàn)方式以及其優(yōu)劣。

1. 什么是Server Push

想象在聊天應(yīng)用中，如果使用傳統(tǒng)的ajax來承擔消息的傳入，那么一般是通過每隔一定時間拉取一次信息的方式實現(xiàn)，但是其實這種方式有大量查詢是浪費的。聊天等Web應(yīng)用更需要服務(wù)器在特定時間來主動告知前端有新的消息(Push)，而不是前端每時每刻問服務(wù)器：“來消息了嗎？”(Pull)。這也正是為什么這個技術(shù)常被叫做反向ajax。

其他別名：Comet，反向Ajax

?

2. 如何實現(xiàn)Push

其實所謂的推送技術(shù)也沒有多么復(fù)雜，目前從大類上有3種，一種仍然建立在ajax基礎(chǔ)上，還有一種建立在框架基礎(chǔ)上，最后一種拋棄了傳統(tǒng)的HTTP協(xié)議，使用Flash或者HTML5的WebSockets技術(shù)。接下來將對這三種類別產(chǎn)生的不同的方式進行探討。

1) Ajax 長輪詢

Ajax長輪詢從本質(zhì)上來說仍然是一種pull，但是實時性較高，無用請求減少很多，是一種不錯的Push實現(xiàn)方案。不過它只減少了網(wǎng)絡(luò)上的無謂消耗。

核心:?客戶端發(fā)起一個ajax請求，服務(wù)端將請求擱置(pending)或者說掛起，直到到了超時時間(timeout)或需要推送時返回；客戶端則等待ajax返回后處理數(shù)據(jù)，再發(fā)起下一個ajax請求。

優(yōu)點:?兼容性較高，實現(xiàn)簡單

缺點:?對于php這種語言來說，如果要做到實時，那么服務(wù)端就要承受大得多的壓力，因為擱置到什么時候往往是不確定的，這就要php腳本每次擱置都進行一個while循環(huán)。
當然，如果服務(wù)器刷新每秒級，那尚可接受，只是實時性上退化了。

注意:?瀏覽器有連接數(shù)限制。我得出的結(jié)論是如果當前頁面上有一個ajax請求處于等待返回狀態(tài)，那么其他ajax請求都會被擱置(Chrome, Firefox已測)。如果頁面有一般ajax需求怎么辦？解決方法是開個框架，框架中使在另一個域名下進行Comet長輪詢，需要注意跨域問題。

PHP實現(xiàn):?Jquery+php實現(xiàn)comet

相關(guān):Ajax跨域和js跨域解決方案

?

2) Frame 長連接

受到ajax啟發(fā)，出現(xiàn)了框架下的長連接。

核心:?Frame中發(fā)起一個普通請求，服務(wù)器將其擱置；需要推送時輸出直接執(zhí)行
腳本，然后繼續(xù)保持連接。如果擔心超時問題可以改成框架論詢。

優(yōu)點:?與1一樣具有高兼容特性

缺點:?最大的問題是如果框架在載入，那么瀏覽器就好一直顯示“載入中”，這就弱爆了(解決方法參見文末的相關(guān)閱讀資源)。同樣服務(wù)器也要能hold住大量循環(huán)……另外，是否有同域連接限制沒測試。

?

?

3) Flash/HTML5 WebSockets

用flash來發(fā)起WebSockets，秒殺前面一切問題。

優(yōu)點:?標準化, RealTime, Push

缺點:?服務(wù)器需要能應(yīng)對WebSockets；還有如果既沒有Flash又不支持HTML5的怎么辦？

PHP實現(xiàn):?Start Using HTML5 WebSockets Today

?

6) 使用兼容封裝層(socket.io)

以上每種方法都有優(yōu)劣，那么終極解決方案便是合在一起！能WebSockets時候就WebSockets，不支持HTML5特性就退化到Flash，沒有Flash則退化到Ajax長輪詢。這也是我的Rainbowfish所采用的方式。

優(yōu)點:?高度封裝，編寫非常容易，幾乎不需要關(guān)心如何去實現(xiàn)的。實時，超低負載，高并發(fā)。

缺點:?其實算不上缺點，socket.io的服務(wù)器端要求是node.js，而不是php。

個人看法:?如果你是獨立主機，能運行程序，那么socket.io配合node.js是個非常高效的選擇。為什么呢？因為它還可以避免php的服務(wù)端高負載。

Rainbowfish的消息系統(tǒng)通過這種方式實現(xiàn): 所有客戶端都通過socket.io掛在nodejs服務(wù)器上(注意: 只是掛著，不需要任何循環(huán)，因為它是事件驅(qū)動的)；需要推送消息了，服務(wù)器就與nodejs通信(比如訪問某個地址來實現(xiàn))，告訴它推送什么消息到哪里；nodejs收到推送信號后，則通過socket.io實時傳輸數(shù)據(jù)給瀏覽器。這個其實也是一條單向的路，因為nodejs服務(wù)器不具備與php通信的能力，實際上也不需要，網(wǎng)頁上直接連php就可以了。

?

3. 結(jié)束語

事實上，第一個方法(Ajax Long Pull)是一個不錯的方法，只是如果使用php完成的話服務(wù)器負載上有點大，但這其實是通病；而最后列舉的socket.io方案完全避免了這個問題，因為它屬于另一種架構(gòu)，并且這種組合也可以配合幾乎所有的腳本語言實現(xiàn)push。

對于實時性要求非常高的應(yīng)用，或許使用php實現(xiàn)實時部分并不是一個好的選擇，將會面臨非常大的服務(wù)器負載(可以通過編寫支持等待事件的擴展來解決這個問題)；如果只是消息提示等，則可以調(diào)整服務(wù)器上刷新的間隔降低到秒的級別，負載尚可接受。不過無論哪種用途，配合那些非阻塞語言或許才是最好的選擇。

4. 相關(guān)閱讀

How to implement COMET with PHP

Start Using HTML5 WebSockets Today

Comet(Wikipedia)

Ajax跨域和js跨域解決方案

Jquery+php實現(xiàn)comet

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

?

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

?

在Web應(yīng)用中，客戶端的AJAX技術(shù)已經(jīng)非常普遍也非常深入人心了，但與此同時，另一些應(yīng)用，諸如在線監(jiān)控，實時數(shù)據(jù)顯示，即時通訊等需要將后臺數(shù)據(jù)變化情況實時顯示到前臺，這樣的由服務(wù)器push的行為（也許會讓你想到blackberry）則需要另一種方案來解決，也就是本文所要介紹的Comet —— 無需安裝插件，保持http長連接的服務(wù)器推方案。
以下兩點是方案中必須顧及到的。

瀏覽器通用性，對各種不同實現(xiàn)結(jié)構(gòu)模型的支持。

長連接對于服務(wù)器資源的占用，以及服務(wù)器的承受能力。

Comet的客戶端與服務(wù)端交互流

業(yè)界對于Comet實現(xiàn)有兩種主要的解決方案：

基于AJAX的輪詢(long polling)方式

這種方式就是由客戶端發(fā)出AJAX請求，然后服務(wù)端阻塞請求直至有響應(yīng)或超時。客戶端在接收到服務(wù)端的指令之后會進行響應(yīng)并發(fā)出新的請求。

從實現(xiàn)層面上來說，當XMLHttpRequest的狀態(tài)為4也就是load的狀態(tài)時會進行客戶端處理，而Gecko（Firefox）和Webkit（Chrome，Safari）目前支持在readystate為3的時候讀取（當然只能讀取到所有該請求已返回的串內(nèi)容，所以需要自行確定指令邊界），Trident（IE）目前如果中途去讀取會拋出錯誤，IE8中使用XDomainRequest可以適當解決這個問題（參見Eric Law的COMET Streaming in Internet Explorer[]）。

目前，開心網(wǎng)采用的是這一種方式。

?

基于iframe及htmlfile的流(streaming)方式

這種方式是使用了iframe的機制，然后使得這個iframe請求一個特定的URL，并通過對這個頁面的加載不斷的從服務(wù)端抓回數(shù)據(jù)，這里從服務(wù)端抓回的數(shù)據(jù)大多是對頁面當前JavaScript函數(shù)的引用和操作。

這個方案的一個明顯不足之處是頁面會一直顯示正在加載，而這在IE上會更明顯。Google的天才們想到了用htmlfile的ActiveX控件來解決這個問題的方案，詳細描述可以參見Alex Russell的What else is burried down in the depth's of Google's amazing JavaScript?

目前，人人網(wǎng)和GTalk采用的是這種方式。

除了文首所提到的通用性和性能之外，還有幾點是需要列入考量范圍的。

數(shù)據(jù)交換的格式。由于數(shù)據(jù)交換的形式是推送，所以不可避免的會有指令隊列的存在，于是數(shù)據(jù)結(jié)構(gòu)是需要前后臺詳細約定的，執(zhí)行指令和數(shù)據(jù)指令都需要有嚴格的界定，一般來說，JSON的方案比較普遍。

瀏覽器本身的連接數(shù)限制。HTTP 1.1規(guī)范中聲明客戶端不應(yīng)該與服務(wù)器端建立超過兩個的 HTTP 連接，而IE又嚴格遵守了這一點，所以前臺在處理請求的時候需要謹慎控制請求的數(shù)量。

其實，Comet技術(shù)在AJAX大紅大紫的2005年之后的2006年時是業(yè)界一個很熱的討論點，目前的這兩種方式非常成熟，在dojo，dwr等前端框架中都已經(jīng)有這樣的實現(xiàn)，而Bayeux協(xié)議的出現(xiàn)也已經(jīng)在實質(zhì)上訂下了一種業(yè)界的標準。

Comet的框架前端有Pushlet，dwr和dojo等，服務(wù)端有Jetty，Meteor，Orbited，Glassfish，Alpha，實現(xiàn)的產(chǎn)品語言也覆蓋了Java，C++，Python，Perl，Ruby，Erlang，.Net等。

下一代HTML5中的WebSocket會是Comet的一個新起點，但在那之前，在非插件的web層面應(yīng)該不會有更進一步的討論與技術(shù)出現(xiàn)。

本文只是對Comet這個技術(shù)進行大體的概述，粗陋不明之處難免，在后續(xù)的文章中將會對WebSocket進行一定的解釋和演示。

參考資料：

• 這里有一個php的comet的例子How to implement COMET with PHP。這個要看看

• 這是developerWorks上對于Comet的介紹。

• 這是當前Comet的服務(wù)器端的一些產(chǎn)品及介紹。

• 當然，Wikipedia上面對Comet的解釋也是非常詳盡。

• 還可以看看AjaxPatterns上面的一些介紹。

• 最后，CometDaily是個值得去了解最新Comet新聞和知識的地方。

• =====================================================================================================

Comet：基于 HTTP 長連接的“服務(wù)器推”技術(shù)

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

ps:上述文章應(yīng)該夠你看明白的了。使用一種吧。但我現(xiàn)在還沒有在項目用推技術(shù)，原因，還沒有來得及折騰，但在本地測試都很正常 。

以下提供protype 和 jquery的 +php實現(xiàn)的代碼例子。[例子代碼來自網(wǎng)上，已測試通過。好用]

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

轉(zhuǎn)載于:https://blog.51cto.com/smileyouth/1630199

總結(jié)

以上是生活随笔為你收集整理的PHP ServerPush (推送) 技术的探讨的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。