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