|
|
基于 WEB 的實時事件通知方式大致有五種方案：HTTP拉取方式(pull)，HTTP流，Long Polling，FlashXMLSocket方式，Java Applet。
首先說下Comet這個詞，Comet這個詞是最早由Alex Russell（DojoToolkit 的項目 Lead）提出的，稱基于 HTTP 長連接、無須在瀏覽器端安裝插件的“服務器推(Push)”技術為“Comet”。
1. HTTP拉取方式(pull)
在這種傳統的方法中，客戶端以用戶可定義的時間間隔去檢查服務器上的最新數據。這種拉取方式的頻率要足夠高才能保證很高的數據精確度，但高頻率可能會導致多余的檢查，從而導致較高的網絡流量。而另一方面，低頻率則會導致錯過更新的數據。理想地，拉取的時間間隔應該等于服務器狀態改變的速度。常見的實現如利用 "<meta http-equiv="refresh" c />" tag，當然利用xmlHttpRequest定時取也是一種方法。
2. HTTP流(Push機制)
HTTP流有兩種形式：
* Page Stream: 頁面上不間斷的HTTP連接響應(HTTP 1.1 Keep Alive).
通過在 HTML 頁面里嵌入一個隱蔵幀（iframe），然后將這個隱蔵幀的SRC屬性設為對一個長連接的請求，服務器端就能源源不斷地往客戶端輸入數據。
* Service Stream: XMLHttpRequest連接中的服務器數據流。
客戶端是在 XMLHttpRequest 的 readystate 為4（即數據傳輸結束）時調用回調函數，進行信息處理。當 readystate 為 4 時，數據傳輸結束，連接已經關閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持，即 readystate 為3時（數據仍在傳輸中），客戶端可以讀取數據，從而無須關閉連接，就能讀取處理服務器端返回的信息。IE 在 readystate 為3時，不能讀取服務器返回的數據，目前 IE 不支持基于 Streaming AJAX。
注：使用 Page Stream(iframe) 請求一個長連接有一個很明顯的不足之處：IE、Morzilla Firefox下端的進度欄都會顯示加載沒有完成，而且 IE 上方的圖標會不停的轉動，表示加載正在進行。Google 的天才們使用一個稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題，并將這種方法用到了 gmail+gtalk 產品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介紹了這種方法。Zeitoun 網站提供的comet-iframe.tar.gz，封裝了一個基于 iframe 和 htmlfile 的 JavaScript comet 對象，支持IE、Mozilla Firefox 瀏覽器，可以作為參考。（http://alex.dojotoolkit.org/?p=538）
3. 長時間輪詢(Long Polling)
也就是所謂的異步輪詢(Asynchronous Polling)，這種方式是純服務器端推送方式和客戶端拉取方式的混合。它是基于BAYEUX協議(http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html) 的。這個協議遵循基于主題的發布——訂閱機制。在訂閱了某個頻道后，客戶端和服務器間的連接會保持打開狀態，并保持一段事先定義好的時間（默認為45 秒）。如果服務器端沒有事件發生，而發生了超時，服務器端就會請求客戶端進行異步重新連接。如果有事件發生，服務器端會發送數據到客戶端，然后客戶端重新連接。
a) 服務器端會阻塞請求直到有數據傳遞或超時才返回。
b) 客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息后，再次發出請求，重新建立連接。
c) 當客戶端處理接收的數據、重新建立連接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端重新建立連接，客戶端會一次把當前服務器端所有的信息取回。
4. Flash XMLSocket(push機制)
這種方案實現的基礎是：
a) 安裝了 Flash 播放器，Flash 提供了 XMLSocket 類(Flash 7.0.14以上版本)。
b) JavaScript 和 Flash 的緊密結合：在 JavaScript 可以直接調用 Flash 程序提供的接口。
具體實現方法：在 HTML 頁面中內嵌入一個使用了 XMLSocket 類的 Flash 程序。JavaScript 通過調用此 Flash 程序提供的套接口與服務器端的套接口進行通信。JavaScript 在收到服務器端以 XML 格式傳送的信息后可以很容易地控制 HTML頁面的內容顯示。
關于如何去構建 JavaScript 與 Flash XMLSocket 的 Flash 程序，以及如何在 JavaScript 里調用 Flash 提供的接口，我們可以參考 AFLAX（Asynchronous Flash and XML）項目提供的 Socket Demo 以及SocketJS（請參見 [http://www.aflax.org/ Asynchronous Flash and XML，提供了強大的Flash、Javascript 庫和很多范例。]）。
Javascript 與 Flash 的緊密結合，極大增強了客戶端的處理能力。從 Flash 播放器 V7.0.19 開始，已經取消了XMLSocket 的端口必須大于 1023 的限制。Linux 平臺也支持 Flash XMLSocket 方案。但此方案的缺點在于：
a) 客戶端必須安裝 Flash 播放器；
b) 因為 XMLSocket 沒有 HTTP 隧道功能，XMLSocket類不能自動穿過防火墻；
c) 因為是使用Socket接口，需要設置一個通信端口，防火墻、代理服務器也可能對非 HTTP 通道端口進行限制；
d) 必須使用XML格式作為消息格式，數據冗余增大。
5. Java Applet(Push機制)
類似于Flash XMLSocket方式。目前已經很少使用，原因極可能是因在手機等移動終端缺少支持。
總結和建議：
如果我們想要高數據一致性和高網絡性能，我們就應該選擇推送方式。但是，推送會帶來一些擴展性問題；服務器應用程序CPU使用率是拉取方式的7倍。根據TUD（http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2007-016.pdf）的測試結果，服務器性能會在350-500個用戶時趨于飽和。對于更大數量的用戶，服務器端需要維護大量并發的長連接。在這種應用背景下，服務器端需要考慮負載均衡和集群技術；或是在服務器端為長連接作一些改進。
使用拉取方式，要想達到完整的數據一致性以及很高的網絡性能是很困難的。如果拉取的時間間隔大于數據更新的時間間隔，就會發生一些數據的遺失。而如果小于數據更新的時間間隔，網絡性能就會受到影響。拉取方式只有在拉取時間間隔等同于數據更新時間間隔時，才會恰到好處。但是，為了達到那樣的目標，我們就需要提前知道準確的數據更新時間間隔。然而，數據更新的時間間隔很少是靜態不變并可以預知的。這使得拉取方式只有在數據是根據某種特定模式發布的情況才有用。
控制信息與數據信息使用不同的 HTTP 連接
使用長連接時，存在一個很常見的場景：客戶端網頁需要關閉，而服務器端還處在讀取數據的堵塞狀態，客戶端需要及時通知服務器端關閉數據連接。服務器在收到關閉請求后首先要從讀取數據的阻塞狀態喚醒，然后釋放為這個客戶端分配的資源，再關閉連接。所以在設計上，我們需要使客戶端的控制請求和數據請求使用不同的 HTTP 連接，才能使控制請求不會被阻塞。
在實現上，如果是基于 iframe 流方式的長連接，客戶端頁面需要使用兩個iframe，一個是控制幀，用于往服務器端發送控制請求，控制請求能很快收到響應，不會被堵塞；一個是顯示幀，用于往服務器端發送長連接請求。如果是基于 AJAX 的長輪詢方式，客戶端可以異步地發出一個 XMLHttpRequest 請求，通知服務器端關閉數據連接。
在客戶和服務器之間保持“心跳”信息
在瀏覽器與服務器之間維持一個長連接會為通信帶來一些不確定性：因為數據傳輸是隨機的，客戶端不知道何時服務器才有數據傳送。服務器端需要確保當客戶端不再工作時，釋放為這個客戶端分配的資源，防止內存泄漏。因此需要一種機制使雙方知道大家都在正常運行。在實現上：
a) 服務器端在阻塞讀時會設置一個時限，超時后阻塞讀調用會返回，同時發給客戶端沒有新數據到達的心跳信息。此時如果客戶端已經關閉，服務器往通道寫數據會出現異常，服務器端就會及時釋放為這個客戶端分配的資源。
b) 如果客戶端使用的是基于 AJAX 的長輪詢方式；服務器端返回數據、關閉連接后，經過某個時限沒有收到客戶端的再次請求，會認為客戶端不能正常工作，會釋放為這個客戶端分配、維護的資源。
c) 當服務器處理信息出現異常情況，需要發送錯誤信息通知客戶端，同時釋放資源、關閉連接。
it知識庫：基于WEB的實時事件通知方案，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
