[Ajax]服務器推技術 - 反向AJAX - (服務端原理)

首先感謝有sun這樣的公司，是他們給咱們的創造帶來無盡的可能。

首先闡明服務器推的集中可能

圖片出自Sun 科技日2008-2009
2008年11月22日 星期六\使用Comet和Ajax開發網絡應用

首先進行簡單的描述
第一種狀況 polling 能夠解釋爲輪訓，相似心跳檢測的方式。
只客戶端按照必定的時間間隔按期請求服務器，在這個過程當中可能沒有任何事情發生，此時的操做徹底是浪費網絡資源。不過這也是最簡單、最容易理解的方式。
其存在的缺點也是不言而喻，首先是請求的間隔控制，間隔過久就會失去意義，間隔過短就會額外增長服務器的壓力。最最關鍵的是其沒法保證服務器事件的實時性，即你不能保證服務器上事件發生的時候客戶端能夠及時檢測到。


第二種方式 long poll 能夠解釋爲長輪詢，即服務端阻斷前一次對客戶端的迴應，在事件發生後將事件內容綁定在迴應中返回給客戶端，同時迴應結束，此時客戶端當即發送第二次請求，服務器阻塞回應等待下一次事件發生。
此方法與第一種方法相比已經增色很多，大大下降了網絡的利用率，即在沒有事件的前提下，理論上沒有數據交互，同時也是最最重要的一點是它體現了很強的實時性，即服務器端發生事件後客戶端能第一時間收到信息。

第三種stream 沒有合適的翻譯。
按照現有的技術判斷，這已是終極了。即服務器阻斷客戶端的迴應，和第二種方式類似，重要的是服務器沒有關閉迴應而是一直保留這這個到客戶端的輸出流。與第二種相比確實是一個很到的進步。

可是第三種方式是理論上的，實際的應用中不需結合第二種，即超時和鏈接驗證等等。
按照以前個人測試在IE下(IE6)是不能支持第三種狀況，因此在IE6下要使用第二種狀況，所以在IE下超時判斷就和鏈接判斷融合在一塊兒。可是在FireFox下還要單獨作超時判斷。

搜狗西奈(聯想取詞的方法有時候很噁心啊)。



在此關於業界支持和具體技術評測請參見Sun 科技日2008-2009\2008年11月22日 星期六\使用Comet和Ajax開發網絡應用 中的演講內容和演講ppt轉換的發行版pdf：4_TD09_Comet_Doris_Beijing.pdf