comet 异步请求技术中相关关键字解释 (新手向)
2019獨角獸企業重金招聘Python工程師標準>>>
最近想在產品中加入即時通訊的功能.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這種方式.奇淫技巧很唬人啊.適合忽悠剛入職的小朋友們哈哈..
轉載于:https://my.oschina.net/jsmagic/blog/125456
總結
以上是生活随笔為你收集整理的comet 异步请求技术中相关关键字解释 (新手向)的全部內容，希望文章能夠幫你解決所遇到的問題。
