2011-06-23 30 views
6

我剛開始研究HTML5 WebSockets。我想知道我是否可以使用websockets而不是使用ASP.NET UpdatePanels來更新所有的網頁內容,或者這會過度殺傷?我可以使用HTML5 WebSockets執行通常使用AJAX完成的任務嗎?

可以使用WebSockets作爲AJAX的替代嗎?這是WebSockets應該用於什麼?

大多數示例都是雙向聊天式演示。但是,如果我想點擊一個按鈕而不是回發來更新網格,我可以用WebSockets來做到這一點,這是一個好主意嗎?

回答

0

如果您想在IE8應該能夠查看的頁面中使用WebSockets,請改爲使用Ajax。

WebSockets最初設計用於客戶端和服務器之間的快速雙向通信。讓遊戲在瀏覽器中蓬勃發展是非常重要的,但服務器端實現還沒有完全標準化 - 可能會有進一步的安全問題。

現在,WebSockets只用於玩具的實現。他們不是客戶準備好的。此外,只有當阿賈克斯呼叫彗星呼叫對您的需求來說太慢時,他們才真正需要。

+0

通過向您的應用程序添加[web-socket-js](https://github.com/gimite/web-socket-js)(基於Flash的polyfill/fallback),您可以使用Flash支持任何瀏覽器。將其與iOS本身支持WebSockets的事實結合起來,並使得幾乎所有主流瀏覽器都可以使用WebSockets。有許多WebSocket服務器,大多數支持瀏覽器中的所有協議版本。另外,「玩具」具有誤導性。儘管大多數WebSocket的使用都是相對較新的,但是在開發中確實如此,但它確實具有生產質量的應用。 – kanaka

0

從技術上講,是的。實際上,我可能會等待。

Websockets絕對是HTML5做我們習慣的通信類型的方式。從技術上講,你可以,但是取決於你正在建設的網站的類型,你可能想要延期。 Websockets是HTML5規範中最新的部分之一,目前仍在最終確定中。它適用於最新版本的Chrome和Firefox 4,但IE9尚未實現此功能,如果IE10也有此功能,則無此言語。展示最新技術的技術網站(例如演示HTML5中的可能性)以及絕大多數受衆將被保證使用支持瀏覽器或早期採用者的任何其他事物都應該沒問題。如果沒有,你可能會疏遠一些用戶。只有你可以決定走哪條路。

這裏的關鍵在於Websockets目前是一個不斷變化的規範,AJAX可以在新舊瀏覽器中使用。如果除了保證之外,您還想向後兼容,則明天規範和瀏覽器不會更改並破壞現有代碼,請使用AJAX。如果你很酷,很可能規格和瀏覽器的實現可能在未來發生變化,並且不關心使用舊瀏覽器的人,那麼使用websockets。

Another stackoverflow answer shows websocket support

  • Chrome瀏覽器4.0支持WebSockets的。
  • Safari 5.0.2也支持它們
  • Firefox 4.0隨附支持禁用WebSockets。使其能夠看到
  • 歌劇院11附帶禁用支持重新啓用它看
  • IE9不支持他們,但一個附加提供實驗支持
+0

WebSocket API(它是協議本身的一個單獨標準,在技術上也不是HTML5的一部分)不可能以向後不兼容的方式進行更改。 WebSocket協議允許編寫支持協議多個版本的服務器,而且大部分都可以。 iOS現在本機支持WebSockets。另外,[web-socket-js](https://github.com/gimite/web-socket-js)是基於Flash的polyfill/fallback。這意味着瀏覽器支持已經基本普及。 – kanaka

2

WebSocket的標準設計的應用程序需要低延遲,低開銷的通信。它們對現有的應用程序非常有用,這些應用程序正在推動AJAX/Comet/long-poll的可能性。但更重要的是,WebSockets將啓用一個全新的Web應用程序類別,但目前還不存在。

對於你的情況,這聽起來像WebSockets可能會過度殺傷,因爲延遲不是你正在構建的核心問題。你當然可以用WebSockets來完成,但是我懷疑在你的情況下這將會是額外的工作。

請參閱this answer爲什麼WebSocket已經準備好可供常規使用(web-socket-js和本機iOS支持,這意味着幾乎所有瀏覽器都支持WebSockets)。

+0

在這種情況下使用WebSocket的主要問題是可能需要付出相當大的努力才能獲得一點收穫。在這種情況下,可能不值得嘗試向IIS添加WebSocket支持(假設ASP.NET應用程序在IIS上運行)或添加額外的WebSocket服務器和基礎結構以允許ASP.NET應用程序與它交談。我完全同意WebSockets已準備好供常規使用,因爲有後備支持。問題是在**自己的主機環境中在後端設置WebSocket支持**目前有點痛苦。 – leggetter

3

我認爲XHR和WebSocket適用於2種不同的場景,您應該使用更適合您場景的場景。

XHR有請求 - 響應對。每個請求都與響應配對。這對遠程過程調用很有用,但如果您希望沒有請求的響應(即服務器推送),則會產生不必要的開銷。

WebSocket解決了上述問題。您可以發送請求,而不需要任何響應。服務器也可以通過響應向您發送任何內容,而無需先發起請求。

在按鈕點擊和內容更新場景(例如編輯表格單元格)中,XHR(和UpdatePanel)效果更好。這是因爲內容更新必須與點擊按鈕配對。這是一個請求 - 響應對。但在純內容更新場景中(例如顯示實時股票價格),WebSocket的效果更好。在內容更新與按鈕點擊(例如聊天)無關的情況下,WebSocket也可以更好地工作。

相關問題