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