理解 Comet

您可能已經聽說過 Comet，因為它最近受到了一定的關注。Comet 有時也稱反向 Ajax 或服務器端推技術（server-side push）。其思想很簡單：將數據直接從服務器推到瀏覽器，而不必等到瀏覽器請求數據。聽起來簡單，但是如果熟悉 Web 應用程序，尤其是 HTTP 協議，那么您就會知道，這絕不簡單。實現 Comet 風格的 Web 應用程序，同時保證在瀏覽器和服務器上的可伸縮性，這只是在最近幾年才成為可能。目前一些主流網站都有類似的原理，例如：webQQ、開心網、白社會等等，它們中消息動態都是采用類似的技術，也許具體實現方式不一樣；

使用 Comet 的動機

HTTP 協議的成功毋庸置疑。它是 Internet 上大部分信息交換的基礎。然而，它也有一些局限性。特別是，它是無狀態、單向的協議。請求被發送到 Web 服務器，服務器處理請求并發回一個響應 — 僅此而已。請求必須由客戶機發出，而服務器則只能在對請求的響應中發送數據。這至少會影響很多類型的 Web 應用程序的實用性。典型的例子就是聊天程序。另外還有一些例子，例如比賽的比分、股票行情或電子郵件程序。

HTTP 的這些局限性也是它取得一定成功的原因。請求/響應周期使它成為了經典的模型，即每個連接使用一個線程。只要能夠快速為請求提供服務，這種方法就有巨大的可伸縮性。每秒鐘可以處理大量的請求，只需使用少量的服務器就可以處理很大數量的用戶。對于很多經典的 Web 應用程序，例如內容管理系統、搜索應用程序和電子商務站點等等而言，這非常適合。在以上任何一種 Web 應用程序中，服務器提供用戶請求的數據，然后關閉連接，并釋放那個線程，使之可以為其他請求服務。如果提供初始數據之后仍可能存在交互，那么將連接保持為打開狀態，因此線程就不能釋放出來，服務器也就不能為很多用戶服務。

但是，如果想在對請求做出響應并發送初始數據之后，仍然保持與用戶的交互呢？在 Web 早期，這一點常使用 meta 刷新實現。這將自動指示瀏覽器在指定秒數之后重新裝載頁面，從而支持簡陋的輪詢（polling）。這不僅是一種糟糕的用戶體驗，而且通常效率非常低下。如果沒有新的數據要顯示在頁面上呢？這時不得不重新呈現同樣的頁面。如果對頁面的更改很少，并且頁面的大部分沒有變化呢？同樣，不管是否有必要，都得重新請求和獲取頁面上的一切內容。

Ajax 的發明和流行改變了上述狀況。現在，服務器可以異步通信，因此不必重新請求整個頁面。現在可以進行增量式的更新。只需使用 XMLHttpRequest 輪詢服務器。這項技術通常被稱作 Comet。這項技術存在一些變體，每種變體具有不同的性能和可伸縮性。我們來看看這些不同風格的 Comet。

Comet 風格

Ajax 的出現使 Comet 成為可能。HTTP 的單向性質可以有效地加以規避。實際上有一些不同的方法可以繞過這一點。您可能已經猜到，支持 Comet 的最容易的方式是輪詢（poll）。使用 XMLHttpRequest 向服務器發出調用，返回后，等待一段固定的時間（通常使用 JavaScript 的 setTimeout 函數），然后再次調用。這是一項非常常見的技術。例如，大多數 webmail 應用程序就是通過這種技術在電子郵件到達時顯示電子郵件的。

這項技術有優點也有缺點。在這種情況下，您期望快速返回響應，就像任何其他 Ajax 請求一樣。在請求之間必須有一段暫停。否則，連續不斷的請求會沖垮服務器，并且這種情況下顯然不具有可伸縮性。這段暫停使應用程序產生一個延時。暫停的時間越長，服務器上的新數據就需要越多的時間才能到達客戶機。如果縮短暫停時間，又將重新面臨沖垮服務器的風險。但是另一方面，這顯然是最簡單的實現 Comet 的方式。

現在應該指出，很多人認為輪詢并不屬于 Comet。相反，他們認為 Comet 是對輪詢的局限性的一個解決方案。最常見的 “真正的” Comet 技術是輪詢的一種變體，即長輪詢（long polling）。輪詢與長輪詢之間的主要區別在于服務器花多長的時間作出響應。長輪詢通常將連接保持一段較長的時間 — 通常是數秒鐘，但是也可能是一分鐘甚至更長。當服務器上發生某個事件時，響應被發送并隨即關閉，輪詢立即重新開始。

長輪詢相對于一般輪詢的優點在于，數據一旦可用，便立即從服務器發送到客戶機。請求可能等待較長的時間，期間沒有任何數據返回，但是一旦有了新的數據，它將立即被發送到客戶機。因此沒有延時。如果您使用過基于 Web 的聊天程序，或者聲稱 “實時” 的任何程序，那么它很可能就是使用了這種技術。

長輪詢有一種變體，這是第三種風格的 Comet。這通常被稱為流（streaming）。按照這種風格，服務器將數據推回客戶機，但是不關閉連接。連接將一直保持開啟，直到過期，并導致重新發出請求。XMLHttpRequest 規范表明，可以檢查 readyState 的值是否為 3 或 Receiving（而不是 4 或 Loaded），并獲取正從服務器 “流出” 的數據。和長輪詢一樣，這種方式也沒有延時。當服務器上的數據就緒時，該數據被發送到客戶機。這種方式的另一個優點是可以大大減少發送到服務器的請求，從而避免了與設置服務器連接相關的開銷和延時。不幸的是，XMLHttpRequest 在不同的瀏覽器中有很多不同的實現。這項技術只能在較新版本的 Mozilla Firefox 中可靠地使用。對于 Internet Explorer 或 Safari，仍需使用長輪詢。

至此，您可能會想，長輪詢和流都有一個很大的問題。請求需要在服務器上存在一段較長的時間。這打破了每個請求使用一個線程的模型，因為用于一個請求的線程一直沒有被釋放。更糟糕的是，除非要發回數據，否則該線程一直處于空閑狀態。這顯然不具有可伸縮性。幸運的是，現代 Java Web 服務器有很多方式可以解決這個問題。搞JAVA開發的程序員，相對而言比較幸運，PHP目前還不是很多的

轉載于:https://www.cnblogs.com/hailuo/archive/2009/12/10/1620892.html

總結

以上是生活随笔為你收集整理的Comet, 下一代反向AJAX（即服务器推送技术- Server-side push）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。