通過HTTP 2.0實現AJAX與Websocket REST的性能？

Question

通過HTTP 2.0，Websocket與AJAX之間的真實性能差異是什么？

特別是，我正在開發的項目需要雙向實時更新，因此，盡管非標准，如果只在域內進行請求，則通過Websocket而不是AJAX執行REST可能更有效。

但是，我不確定當前有關性能差異的可用信息是否適用於HTTP 2.0。

Answer 1

性能應該始終進行測試而不是理論化...說完了，我會快速指出為什么我認為Websockets更高性能和更可靠 ：

websockets over polling的優點是兩個：

1. 在Http / 2之前，每個新的輪詢請求都需要一個新的連接。 Websockets將為您節省與新連接相關的資源。

   顯然， 當使用Http / 2時不再是這種情況，因為Http / 2旨在利用相同的連接 。 繼續優勢2：

2. 每個新的輪詢請求都是一個請求 ，需要與請求相關的所有資源（例如輪詢數據庫以查看更改等）。

   Websockets將為您節省與輪詢請求相關的資源，因為只有在可用時才會推送數據，從而最大限度地減少臨時請求的數量。

   實際上， websockets仍然可以為您節省大量與實際輪詢相關的資源 。 大多數websocket更新（如果不是全部）都使用數據更新掛鈎，因此不涉及輪詢（推送在更新后立即啟動，無需輪詢和查看更改）。

   即使將輪詢用於websocket數據， 所有客戶端也只有一個輪詢事件，而每個客戶端只有一個輪詢事件。

Http / 2 Push怎么樣？

這應該讓性能問題得以解決......但是，有人可能會問 - “Http / 2推怎么樣？這不是說不再需要websockets嗎？”

這有點值得商榷，你可以找到關於它的討論（例如， 這里 ）。

從我對鏈接問題的回答中可以看出，我相信websocket更可靠，這就是原因：

這里的一些信息不在原始答案中，我的原始答案中的其他信息被跳過或匯總

正如Http / 2草案所述（標准到現在為止？）：

中介可以從服務器接收推送，並選擇不將它們轉發到客戶端...

對於瀏覽器也是如此（如果您查看“設置”框架文檔）。 例如，當我在玩Iodine的Http / 2服務器 （我是作者）時，我注意到Safari正在設置推送通知以“關閉”...我不確定是否仍然如此，但是當我認為websockets與Http / 2時，對我來說這是一個大問題。

此外，當瀏覽器仍在訪問頁面時，客戶端（或服務器或其間的任何人） 可以終止 Http / 2連接，從而有效地禁用Http / 2推送通知。

當在websockets中發生這種情況時，可以使用onclose回調來重新建立連接。 有了Http / 2，你現在無能為力。

出於這些原因（以及其他一些原因），我認為Websockets可以提供更好的性能和更好的可靠性。

編輯 （與評論有關）

SSE （服務器發送事件）

請允許我說明為什么我認為websockets優於SSE。

SSE是基於長輪詢，預網頁時代的開發。

它可能對服務器到客戶端消息很有用，除了一些事情：

1. 它的服務器端實現大多糟透了。

   至於Http / 2，我沒有看到任何實現，所以我不能評論可能發生的事情，但是：

   許多SSE實現將為每個連接打開一個新線程，或實現在服務器的IO反應器旁邊運行的第二個IO反應器，僅用於管理SSE連接。

   與websockets相比，這會浪費資源（雖然我看到一些websocket實現做同樣的事情 - brrr ......）。

2. SSE是單向的 ，不能用於客戶端到服務器發送的消息。

   這意味着您仍然使用Http + AJAX從客戶端發送到服務器的數據。

   與Websockets不同，SSE和Http + AJAX都是無狀態的 ，因此您需要對每個新的消息周期進行身份驗證，解碼Http / 2頭，編碼Http / 2頭並使用與新請求相關的所有資源。 。

   Websockets允許您通過有狀態跳過所有這些。 這意味着只有在打開連接時才執行Http標頭和身份驗證，並且所有消息都在此持久上下文中發送，持續時間為連接的生命周期。

3. SSE沒有得到社區的支持。

   與Websockets相比，很難找到與SSE相關的好庫或信息...... 即使SSE預先確定了websockets ！

   我認為這是webwebsocket在實際生產中的優勢的一個很好的證明。

Http / 2中的Websocket隧道

我認為這個概念和想法是錯誤的，不應該使用隧道。

我認為有一個原因是2014年2月14日的建議在2014年8月18日到期后沒有續訂（據我所知）。

以下是我能想到的幾個原因：

1. Websockets和Http / 2旨在具有不同的生命周期和連接超時。

   雖然與Http / 1.1相比，Http / 2存在很長時間，但瀏覽器（或服務器）可能隨時斷開它們（有或沒有實現websocket斷開模式）。

   路由器，代理和負載平衡器與Http / 2相關，以設置連接的超時設置。 相應的設置不太可能適用於今天用於websockets的超時設置。

2. Websockets和Http / 2是為不同的客戶設計的。

   Http / 2是為Http客戶端設計的 - 主要是瀏覽器。

   另一方面，Websockets是為所有Web客戶端設計的，以幫助瀏覽諸如ISP，防火牆，代理，NAT路由器等中介。 （即這個包 ）

   這意味着當您決定編寫本機應用程序並將Web服務器用作后端時，該本機應用程序應使用websockets以實現更好的連接（它的連接統計信息優於原始TCP / IP）。

   您的本機應用程序不會說Http / 2，但它確實具有建立websockets連接所需的剝離Http / 1。

   如果您決定使用隧道，則可能無法將當前代碼用於本機應用程序。

Answer 2

我肯定會使用websockets，更不用說這種甜蜜的語法，但永遠不要忘記使用socket.io，因為它們是websockets不進行NAT遍歷，並且有一些阻塞，這可能會削弱你的項目。

另外一個事實是，如果你想使用cordova ios和websockets去WKWebView，那么你會因為它們在ios的默認瀏覽器中的工作方式而感到非常驚訝。

關於websockets的最后一件事是盡量不使用它們來發送數據從客戶端到服務器只有服務器 - >客戶端，因為在一天結束時，AJAX是一個比websockets更可靠的解決方案。