comet技術

comet技術  

 

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

http://www.ibm.com/developerworks/cn/java/j-lo-comet/

 

 

在網上查了一下資料，發現輪詢和長輪詢還有不一樣的定義：

1. 輪詢：客戶端定時向服務器發送Ajax請求，服務器接到請求後立刻返回響應信息並關閉鏈接。
   優勢：後端程序編寫比較容易。
   缺點：請求中有大半是無用，浪費帶寬和服務器資源。
   實例：適於小型應用。

2. 長輪詢：客戶端向服務器發送Ajax請求，服務器接到請求後hold住鏈接，直到有新消息才返回響應信息並關閉鏈接，客戶端處理完響應信息後再向服務器發送新的請求。
   優勢：在無消息的狀況下不會頻繁的請求。
   缺點：服務器hold鏈接會消耗資源。
   實例：WebQQ、Hi網頁版、Facebook IM。

另外，對於長鏈接和socket鏈接也有區分：

1. 長鏈接：在頁面裏嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據。
   優勢：消息即時到達，不發無用請求。
   缺點：服務器維護一個長鏈接會增長開銷。
   實例：Gmail聊天

2. Flash Socket：在頁面中內嵌入一個使用了Socket類的 Flash 程序JavaScript經過調用此Flash程序提供的Socket接口與服務器端的Socket接口進行通訊，JavaScript在收到服務器端傳送的信息後控制頁面的顯示。
   優勢：實現真正的即時通訊，而不是僞即時。
   缺點：客戶端必須安裝Flash插件；非HTTP協議，沒法自動穿越防火牆。
   實例：網絡互動遊戲。

以上是四種請求方式的介紹和優缺點比較。

 

長鏈接工做原理：

 

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

長輪詢工做原理：

長輪詢是如今最爲經常使用的方式，和長鏈接方式的區別就是服務器端在接到請求後掛起，有更新時返回鏈接即斷掉，而後客戶端再發起新的鏈接。

 

固然如今也有正在彌補以上兩種不足的第三種方式WebSocket

不論是長鏈接仍是長輪詢，其實都只是單向通訊，直到WebSocket的出現，纔是B/S之間真正的全雙工通訊。不過目前WebSocket協議仍在開發中，目前Chrome和Safri瀏覽器默認支持WebSocket，而FF4和Opera出於安全考慮，默認關閉了WebSocket，IE則不支持（包括9），目前WebSocket協議最新的爲「76號草案」。有興趣能夠看如下資料

http://dev.w3.org/html5/websockets/

 

-----------------------------------------------------------------------------------------------

長鏈接的技術主要是用Comet，採用的技術分瀏覽器來實現，ie上用iframe，別的瀏覽器用xhr來實現。長鏈接主要是因爲對服務器的資源會有一個佔用，因此相對開銷會比較大，好處是即時性很是好，管理起來也相對方便。 
長輪詢的話通常就是間隔必定的時間向服務器請求事件。技術上就是用ajax來實現了。長輪詢會造出很是多的請求，不斷的請求可能會形成的影響是數據順序沒法獲得保證。管理難度較大，好處是對系統的資源佔用相對較少。

 

---------------------------------------------------------------------------------------------------------------------------

Comet 實現的方法

• 簡單輪詢

  最先期的 Web 應用中，主要經過 JavaScript 或者 Meta HTML 標籤等手段，定時刷新頁面來檢測服務端的變化。顯然定時刷新頁面服務端仍然在被動響應客戶端的請求，只不過客戶端的請求是連續、頻繁的，讓用戶看起來產生 有服務端自動將信息發過來的錯覺。這種方式簡單易行，但缺陷也很是明顯：可能大部分請求都是無心義的，由於服務端期待的事件沒有發生，實際上並無須要發 送的信息，而不得不重複的迴應着頁面上全部內容給瀏覽器；另外就是當服務端發生變化時，並不能「實時」的返回，刷新的間隔過短，產生很大的性能浪費，間隔 太長，事件通知又可能晚於用戶指望的時間到達。

  當絕大部分瀏覽器提供了 XHR（XmlHttpRequest）對象支持後，Ajax 技術出現並迅速流行，這一階段作的輪詢就沒必要每次都返回都返回整個頁面中全部的內容，若是服務端沒有事件產生，只須要返回極少許內容的 http 報文體。Ajax 能夠節省輪詢傳輸中大量的帶寬浪費，但它沒法減小請求的次數，所以 Ajax 實現的簡單輪詢仍然有輪詢的侷限性，對其缺陷只能必定程度緩解，而沒法達到質變。

• 長輪詢（混合輪詢）

  長輪詢與簡單輪詢的最大區別就是鏈接時間的長短：簡單輪詢時當頁面輸出完鏈接就關閉了，而長輪詢通常會保持 30 秒乃至更長時間，當服務器上期待的事件發生，將會馬上輸出事件通知到客戶端，接着關閉鏈接，同時創建下一個鏈接開始一次新的長輪詢。

  長輪詢的實現方式優點在於當服務端期待事件發生，數據便當即返回到客戶端，期間沒有數據返回，再較長的等待時間內也沒有新的請求發生，這樣可讓發送的請求減小不少，而事件通知的靈敏度卻大幅提升到幾乎是「實時」的程度。

• Comet 流（Forever Frame）

  Comet 流是按照長輪詢的實現思路進一步發展的產物。令長輪詢將事件通知發送回客戶端後再也不關閉鏈接，而是一直保持直到超時事件發生才從新創建新的鏈接，這種變體 咱們就稱爲 Comet 流。客戶端可使用 XmlHttpRequest 對象中的 readyState 屬性來判斷是 Receiving 仍是 Loaded。Comet 流理論上可使用一個連接來處理若干次服務端事件通知，更進一步節省了發送到服務端的請求次數。

不管是長輪詢仍是 Comet 流，在服務端和客戶端都須要維持一個比較長時間的鏈接狀態，這一點在客戶端不算什麼太大的負擔，可是服務端是要同時對多個客戶端服務的，按照經典 Request-Response 交互模型，每個請求都佔用一個 Web 線程不釋放的話，Web 容器的線程則會很快消耗殆盡，而這些線程大部分時間處於空閒等待的狀態。這也就是爲何 Comet 風格服務很是期待異步處理的緣由，但願 Web 線程不須要同步的、一對一的處理客戶端請求，能作到一個 Web 線程處理多個客戶端請求。