comet 異步請求技術中相關關鍵字解釋 (新手向)

最近想在產品中加入即時通信的功能.BS架構的程序.實現方式不外乎兩大標準下的各類奇淫技巧.

這兩大標準就是 HTML5 HTML4

爲啥這兩個呢..由於HTML5裏面有websocket.這個完全顛覆http請求的東西,使得請求再也不是無狀態的.

固然websocket目前支持不是很好.也沒辦法.看着好東西無法用.這是一種何種的煎熬....搞得我老是想在產品裏面內嵌chromeFrame.而後強制給客戶裝上.哈哈...固然客戶沒準會和我拼命呢...

沒辦法,在現有的需求中基本上,實現思路只有一個了.也就是第一個讓我頭疼了一陣的關鍵詞

"輪詢"

這詞看上去很高級的樣子,其實就是寫個ajax間隔一段時間不斷向服務器請求內容.這活誰都幹過.

而後我就想啊.若是用輪詢實現,那也顯得過低級了吧.怎麼着.咱得弄個高級點的技巧顯擺顯擺..因而,查了一番資料,一個更加裝逼的詞語蹦到了偶的眼前

"長輪詢"

看,變長了果真不同了.這個詞還伴隨着一個英文

"comet"

其實原理很簡單.以往的web請求,服務器處理請求後要當即返回,儘管超時的時間也能到達30秒這麼多(並非說用了comet才能夠容許鏈接在服務器等待,我也可讓鏈接在服務器端sleep).可是鏈接只能存在於本次請求中.沒法保持住.而comet容許鏈接請求過來後被保持住(保存起來,如session裏面).當我須要的時候,讀出來再返回給客戶端數據.因此這種狀況的所謂的"長"長在了服務器端.

長輪詢比輪詢的好處在於,若是像是即時通信,聊天室一類的應用,輪詢並不能保證每次查閱服務器必定有數據須要返回,因此會形成不少沒用的請求到達服務器.而長輪詢由於鏈接保持在了服務器,須要的時候激活就能夠.因此就省去了不少沒用的請求.

長輪詢適合那些數據反映須要及時,可是數據量不大的場景.好比站內消息.其實聊天室不是多麼適合.由於人多的時候.長輪詢和輪詢沒啥區別.因此,對於服務器與瀏覽器交互密集型的實時場景.長輪詢並不能減小多餘的請求.

長輪詢使用ajax實現瀏覽器響應.其實也可使用隱藏的iframe來作.畢竟那個奇葩的IE是咱們不得不兼容的.

用iframe 模擬ajax請求的這種 叫作 "iframe streaming"

對於交互密集型實時場景.還有沒有辦法優化.還真有.

對於 Servlet3 的 AsynContext 關閉有兩種狀況.一種是正常的complete.另外一種就是dispatch.

complete很容易理解.完成後.瀏覽器繼續請求一次.這叫長鏈接.

若是不complete.而dispatch到自身.數據會返回到客戶端.可是鏈接並不須要再次請求.dispatch後的請求仍然能夠繼續返回到客戶端.

因此這種請求方式只須要客戶端發起一次請求就能夠了.

可是.好事多磨.對於前臺來講.因爲鏈接被dispatch.ajax會報錯.(聽說FF仍是op.容許ajax繼續處理請求,我試驗的chrome,報錯了,若是誰成功了,必定告訴我.)

可是.咱們可使用隱藏的iframe來接收這些請求.就能夠正常使用了.固然.瀏覽器的加載按鈕會一直轉啊轉啊..

我我的比較喜歡dispatch這種方式.奇淫技巧很唬人啊.適合忽悠剛入職的小朋友們哈哈..