最近對伺服器推送技術比較感興趣，在網上也看了好些文章，由於每個人理解的不同，實現細節或者語言表達方式不同，本人被各種名詞或者技術實現搞的頭大，於是自己準備整理下。

首先實現伺服器推送技術一直一來是B/S應用開發的一塊難題，因為是基於HTTP協議的，HTTP協議為無狀態，單向性的協議，這種情況導致只有客戶端請求，伺服器才能被動響應結果，雖然HTTP協議的優勢是很大的，高效，高伸縮性等。但是有優勢自然有不足，譬如我想做個聊天室，這種情況導致伺服器無法主動向客戶端推送訊息，這就有了瓶頸。

....於是人們就開始尋找各種解決方案了。

一種就是控制客戶端的頁面不斷的進行ajax請求，應該很好實現吧。js定時器就可以實現，每次請求如果伺服器端有更新資料則響應到客戶端。但是這會造成伺服器的嚴重壓力，如果線上使用者數量過多的話，每隔個一兩秒請求一次，哪個伺服器能受得了，這種肯定不太現實，或者是最無奈的實現方法。

於是出現了 comet ，comet技術是伺服器推技術的一個總稱，但不是具體實現方式。下面我將會講兩種實現方式，是基於HTTP長連線的實現。

第一種叫做長輪詢（long-polling)方式，它同樣使用的ajax,簡單說一下，就是客戶端使用ajax傳送一個請求，伺服器端肯定會開啟一個執行緒，這個執行緒會時時監測要請求的資料是否有變化，如果有變化，則向客戶端輸出最新訊息，並關閉連結，客戶端收到訊息處理之後，再次向伺服器端請求，如此迴圈，所以叫長輪詢，這種實現方式比起上一種自然要好的多了，不需要客戶端不斷的ajax請求，減輕伺服器端的一定壓力，而且可以算得上是實時的。

另外一種是流方式，這種和長輪詢方式挺像，只有一點區別，就是流方式是在客戶端請求服務端並建立連結之後，伺服器端始終不會關閉連結（直到超時，斷電或者其他特殊情況）每次有資料時，就向客戶端進行輸出，而不像長輪詢每次向客戶端輸出之後，都要關閉連結。

關於長輪詢和流方式注意以下：

在長輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 為 4（即資料傳輸結束）時呼叫回撥函式，進行資訊處理。當 readystate 為 4 時，資料傳輸結束，連線已經關閉，長輪詢方式IE、Mozilla FireFox 都支援。而至於流方式，Mozilla Firefox 提供了對流方式的支援，即 readystate 為 3 時（資料仍在傳輸中），客戶端可以讀取資料，從而無須關閉連線，就能讀取處理伺服器端返回的資訊。IE 在 readystate 為 3 時，不能讀取伺服器返回的資料，目前 IE 不支援流方式。

comet實現瓶頸解決——伺服器servlet執行緒阻塞問題