Ajax與Socket.io

Question

我正在開發一個Web應用程序，我想知道哪種方法適合我的項目。

基本上，我想向用戶顯示的是一些從請求發送到其他服務器的通知。 我的node.js應用程序獲取了所有信息，然后將其分發給用戶，並將副本保存到我的MongoDB中。

這個想法很簡單，但是通過閱讀方法我發現了這兩種技術：

1. Ajax：客戶端將一直檢查服務器上是否有新內容。 這將通過使用jquery ajax到達我的服務器API來完成（每30/60秒）。

2. Socket.io：客戶端連接一次，然后保持永久的TCP連接（更實時）。

---

現在我已經解釋了這種情況，我有以下問題：

• 我對ajax的請求不會太多嗎？ 想象一下，我想每分鍾檢查一次服務器，如果我們將應用程序擴展到100個用戶，則每分鍾將給我100個查詢。 擁有套接字會在系統資源中“便宜”嗎？

• 對於移動設備，socket.io是否會成為問題？ 帶寬和性能。 服務器的響應始終是JSON格式的信息。

• 我讀到now.js可以用於此目的，但似乎不再支持該項目，因此不確定是否使用它是個好主意。

• 兩種方法的緩存如何？ 我正在考慮為每個用戶創建一個緩存文件，該文件將由服務器端的node.js進行更新。 我猜想這可以與ajax一起很好地工作，但是socket.io呢？

• 確實socket.io與許多瀏覽器根本不兼容嗎？ 我的應用程序將更加專注於移動設備，我認為這可以讓我考慮選擇ajax。

• 有其他建議嗎？

我希望這可以清除我和處於相同情況的其他人的想法:)謝謝

Answer 1

這里討論了webSocket和Ajax之間的許多通用折衷：

websocket vs rest API實時數據？

此處討論了移動設備的一些權衡問題：

Cordova：套接字，PushNotifications還是反復輪詢服務器？

簡而言之，如果您的數據主要是服務器驅動的，然后需要發送給客戶端，並且您希望在客戶端看到新數據時等待相當長的等待時間，那么這正是webSockets可以解決的確切問題。 在這種情況下，webSockets效果最佳，因為客戶端不需要頻繁輪詢，服務器不需要處理來自許多客戶端的常規輪詢請求。 取而代之的是，每個客戶端都只建立一個持久的webSocket通信通道，服務器可以隨時根據需要向下發送數據。

我對ajax的請求不會太多嗎？ 想象一下，我想每分鍾檢查一次服務器，如果我們將應用程序擴展到100個用戶，則每分鍾將給我100個查詢。 擁有套接字會在系統資源中“便宜”嗎？

套接字在不活動時只需要很少的資源，因此，持久的webSocket比許多不斷輪詢的客戶端更有效。 這就是發明webSocket的原因，因為它們更擅長解決此特定問題。

對於移動設備，socket.io是否會成為問題？ 帶寬和性能。 服務器的響應始終是JSON格式的信息。

socket.io對於帶寬或性能而言不是問題。 嘗試在后台使用webSockets存在一些移動問題，因為移動設備也試圖進行主動電源管理，盡管客戶端輪詢也存在類似問題。

兩種方法的緩存如何？ 我正在考慮為每個用戶創建一個緩存文件，該文件將由服務器端的node.js進行更新。 我猜想這可以與ajax一起很好地工作，但是socket.io呢？

不清楚您對緩存有什么要求？ 在webSocket實現中，服務器獲取數據，然后將其發送給每個用戶。 通常不需要服務器端緩存。 在客戶端Ajax輪詢實現中，服務器必須將數據存儲在某個位置，然后“等待”每個客戶端然后請求數據。 對於webSocket或Ajax，沒有“內置”緩存機制。

確實socket.io與許多瀏覽器根本不兼容嗎？ 我的應用程序將更加專注於移動設備，我認為這可以讓我考慮選擇ajax。

socket.io與所有具有webSockets的瀏覽器完全兼容，除了IE9和更早版本，幾乎所有當前使用的webSockets都使用。 如果使用socket.io庫，則如果不存在webSockets，它將自動退回長時間輪詢。 無論您是進行常規輪詢還是使用webSocket，您的移動問題都可能會相似，因為移動設備希望對長期運行的設備進行電源管理，但又不想停止輪詢。 我認為這不是避免使用webSockets / socket.io的原因。 socket.io在失去連接時具有一些非常好的自動重新連接邏輯，這很有用。

在移動世界中，我認為您會發現，如果不使用某種可以插入設備上本機“推送”系統的本機應用程序組件，就無法在后台可靠地進行實時通知。這是唯一一個既具有電池效率又與電源管理完全兼容的系統。 如果不是前台任務或設備處於空閑狀態，則將對網頁進行電源管理。