HTML服務器推送技術簡介

　　為什麼需要服務器推送？

最大的優點實時

適用場景實時股票價格商品價格實時新聞Twitter/weibo timeline基於浏覽器的聊天系統

Web交互的發展歷程？

F手動刷新 > AJAX輪詢(Polling) > Comet實時更新 > HTML實時通信

隨著AJAX的流行當前大部分網站都采取輪詢的方式進行更新但是這種方式的效率是十分低下的一方面服務器端不是總有數據更新所以每次請求不一定都有更新另一方面當發起請求的客戶端數量增加服務器端的接受的請求數量會大量上升無形中就增加了服務器的壓力

另外輪詢方式的實時性也是不夠的比如基於Web的聊天功能對實時性要求就很高於是comet出現了Comet是基於HTTP長連接的服務器推送技術主要有流（streaming）方式和長輪詢（longpolling）方式Comet工作原理用戶發起請求後就掛起等待服務器返回數據在此期間不會斷開連接流方式和長輪詢方式的區別是對於流方式客戶端發起連接就不會斷開連接而是由服務器端進行控制當服務器端有更新時刷新數據客戶端進行更新而對於長輪詢當服務器端有更新返回客戶端先斷開連接進行處理然後重新發起連接

Comet雖然是一個進步但是其仍然是單向通信不能適應Web應用的飛速發展於是各種新技術不斷湧現其中WebSocket在Google的力推之下已經成為業界標准並不斷完善中

下面簡單介紹一下Comet的實現方式

Comet的實現方式

基於AJAX和基於IFrame的流（streaming）方式

從上圖可以看出每次數據傳送不會關閉連接連接只會在通信出現錯誤時或是連接重建時關閉（一些防火牆常被設置為丟棄過長的連接服務器端可以設置一個超時時間超時後通知客戶端重新建立連接並關閉原來的連接）

基於AJAX的長輪詢（longpolling ）方式

    從上圖可以看出客戶端發出請求後掛起服務端在接到請求也掛起等待有更新時返回數據並斷掉連接然後客戶端再發起新的連接

    HTML實時通信

    ServerSent Event只支持單向的從服務器到客戶端的通道

    ServerSent Events實際上將Comet技術進行了標准化ServerSent Events規范定義了API來打開一個HTTP連接通過該連接能夠獲取從服務器推送的通知

    ServerSent Events包含新的HTML元素EventSource和新的MIME類型 text/eventstream這個MIME類型定義了事件框架格式

    EventSource代表的是接收事件的客戶端的終點客戶端通過創建EventSource對象來打開一個event stream創建EventSource對象時該對象接收一個事件來源的URL作為其構造函數的參數當每次收到新的事件數據時onmessage事件處理器會被調用

    ServerSent Event是基於HTTP streaming的如上所述response會一直打開當服務器端有事件發生的時候事件會被寫入response中

    WebSocket基於TCP之上定義了幀協議支持雙向的通信

    WebSocket 是HTML一種新的協議它是實現了浏覽器與服務器的雙向通訊

    在 WebSocket API 中浏覽器和服務器只需要要做一個握手的動作然後浏覽器和服務器之間就形成了一條快速通道兩者之間就直接可以數據互相傳送

    現在很多網站為了實現即時通訊所用的技術都是輪詢輪詢是在特定的的時間間隔（如每秒）由浏覽器對服務器發出HTTP request然後由服務器返回最新的數據給客戶端的浏覽器這種傳統的模式帶來很明顯的缺點即浏覽器需要不斷的向服務器發出請求然而HTTP request 的header是非常長的裡面包含的數據可能只是一個很小的值這樣會占用很多的帶寬和服務器資源

    而比較新的技術去做輪詢的效果是Comet使用了AJAX但這種技術雖然可達到雙向通信但依然需要發出請求而且在Comet中普遍采用了長鏈接這也會大量消耗服務器帶寬和資源

    面對這種狀況HTML定義了WebSocket協議能更好的節省服務器資源和帶寬並達到實時通訊

From:http://tw.wingwit.com/Article/program/net/201311/12980.html