服務(wù)器端推的技術(shù)，對于普通的互聯(lián)網(wǎng)站式應(yīng)用是很少涉及到的，大家已經(jīng)習(xí)慣了請求響應(yīng)式的”拉“，但是對于現(xiàn)在ajax的快速發(fā)展，以及html5的誕生，服務(wù)器端的推送技術(shù)被越來越多的提到。這里總結(jié)幾個push技術(shù)。如何push，給誰push，這就引出了推技術(shù)的核心——發(fā)布訂閱模型。我們常見的推主要有email系統(tǒng)、RSS、IM、消息系統(tǒng)等。
假設(shè)一個場景，一個網(wǎng)站，想對登陸用戶進(jìn)行消息提醒，那么如何選擇技術(shù)實現(xiàn)呢？現(xiàn)在大多數(shù)的實現(xiàn)是輪詢——也就是間隔拉技術(shù)，定時的用ajax請求訪問server，將返回的數(shù)據(jù)更新到頁面上，通過間隔拉取來模擬出push的效果。但這畢竟還不是推，而且存在的核心問題就是請求浪費(fèi)，資源浪費(fèi)，本可避免的服務(wù)器端壓力，總之一句話：低效率。
單純的服務(wù)器端推：
1，http服務(wù)一般是做長連接的，連接不斷開，那么當(dāng)有事件發(fā)生時，服務(wù)器端可以定向的向持有連接的客戶端push數(shù)據(jù)。
2，http響應(yīng)header里的content-type設(shè)置為multipart/mixed這樣的MIME，這種技術(shù)可以通過boundary來在header的content-type里設(shè)置一個邊界值，客戶端通過解析邊界值來區(qū)分不同的顯示部分。換句話說，服務(wù)器端告訴客戶端這個響應(yīng)是有多個部分的，客戶端應(yīng)該通過boundary來區(qū)分這些部分并分別處理。這種技術(shù)有個明顯的劣勢是IE不支持，多數(shù)是被用到webcam這樣的應(yīng)用中。
3，websocket，html5才支持的最新技術(shù)，優(yōu)點(diǎn)嘛自然是高效，但是缺點(diǎn)就是客戶端瀏覽器的支持度了。
另外的幾種技術(shù)：
1，pushlet：與剛才1中提到一樣的持久連接，服務(wù)端定期的返回js片段給到客戶端，客戶端持續(xù)顯示loading狀態(tài)，在收到j(luò)s后執(zhí)行，將結(jié)果更新到頁面上。缺點(diǎn)的話是服務(wù)器端對客戶端超時的控制沒有掌握，在超時后，只有客戶端主動刷新才能解決。詳細(xì)優(yōu)缺點(diǎn)參看這篇文章
2，長輪詢：與傳統(tǒng)定時輪詢不同，長輪詢會在服務(wù)器端阻塞請求，直到有數(shù)據(jù)的時候再做響應(yīng)，而服務(wù)器端在接到響應(yīng)后馬上重新請求，如此往復(fù)。具體可以參看這篇文章
3，F(xiàn)lash XML Socket relays：通過加入一個relay服務(wù)器，這個服務(wù)器接收到客戶端的一個請求，且這個請求基于tcp的連接，然后relay會返回一個id給到客戶端，然后客戶端會帶著這個id請求web服務(wù)器，web服務(wù)器會把響應(yīng)消息給到relay，relay再通過flash socket分發(fā)出去。當(dāng)然tcp并發(fā)連接就是個瓶頸，但是這種做法的效率很高，對于小規(guī)模實現(xiàn)有益。
眾所周知的服務(wù)器端推就是comet技術(shù)了，長輪詢其實也是一種comet技術(shù)。comet技術(shù)本身是個泛化了的概念，具體實現(xiàn)可以有多種，但是通用且多數(shù)的實現(xiàn)時基于XHR（XMLHttpRequest）的ajax長輪詢。
對于具體的業(yè)務(wù)場景，我們可能選擇不同的服務(wù)器端推策略，對于現(xiàn)有的web應(yīng)用比如聊天和消息可能TCP或者長連接就能解決問題，但是對于大并發(fā)下的大型網(wǎng)站，拉取是更合適的選擇，長輪詢可能用的會多一些。當(dāng)然我們最期望的是websocket的表現(xiàn)~
參考文章：
http://en.wikipedia.org/wiki/Push_technology
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
http://en.wikipedia.org/wiki/Internet_Relay_Chat
http://en.wikipedia.org/wiki/Comet_(programming)
http://en.wikipedia.org/wiki/MIME#Mixed-Replace_.28experimental.29