服務器端事件+客戶端事件vs Websocket

Question

我正在更新用於使用ajax輪詢機制的舊系統。 該腳本會定期調用后端以查找更新，很少用戶會發出ajax請求來發送數據。 我最初想使用Web套接字，因為我可以立即從推送事件中獲取數據，並且因為連接保持打開狀態。 然后，我閱讀有關服務器端事件的內容，以及它是如何定向的。 這完全符合我的需要，因為瀏覽器只是在等待事件。 但是，在極少數情況下，用戶可以發送數據。 是否有服務器端事件的替代方法，我可以保持連接打開狀態以將數據發送回服務器？ 使用SSE + AJAX，SSE +（替代方式）還是僅使用Web套接字（即使很少將數據發送回服務器）更好？

謝謝

Answer 1

這是上交所及其靈活性的最好解釋

服務器發送的事件與WebSockets

您為什么選擇通過WebSockets發送服務器發送的事件？ 好問題。

將SSE保留在陰影中的原因之一是因為后來的API（如WebSocket）提供了更豐富的協議來執行雙向全雙工通信。 對於游戲，消息傳遞應用程序以及需要雙向雙向近乎實時更新的情況，擁有雙向通道更具吸引力。 但是，在某些情況下，不需要從客戶端發送數據。 您只需要某些服務器操作的更新即可。 一些示例是朋友的狀態更新，股票行情自動收錄器，新聞提要或其他自動數據推送機制（例如，更新客戶端Web SQL數據庫或IndexedDB對象存儲）。 如果您需要將數據發送到服務器，則XMLHttpRequest始終是朋友。

SSE通過傳統的HTTP發送。 這意味着它們不需要特殊的協議或服務器實現即可正常工作。 另一方面，WebSockets需要全雙工連接和新的Web Socket服務器來處理協議。 另外，服務器發送的事件具有WebSocket設計上缺少的各種功能，例如自動重新連接，事件ID和發送任意事件的功能。

我已經為我的站點構建了一個使用sse和ajax的聊天應用程序。我建議如果只有流更新並且從客戶端到服務器的更新很少，則可以使用sse + ajax，因為您可以使用ajax部分

我發現的唯一問題是缺乏跨瀏覽器的支持。如果您想進一步了解sse，請具體詢問您想要什么

瀏覽器支持列表

Answer 2

由於您的使用主要是服務器向客戶端推送，因此我建議將服務器已發送事件組合起來，用於從服務器向客戶端推送，以及將AJAX用於其他方式。

您絕對應該閱讀本文以做出決定：

http://streamdata.io/blog/push-sse-vs-websockets/

這將為您提供使用Server-Sent事件和WebSocket的優缺點。