我已閱讀了許多關於實時推送通知的文章。簡歷是，只要你不關心100％的瀏覽器兼容性，websocket通常是首選的技術。然而，one article指出長期輪詢vs websocket期待從服務器端的一次性響應
長輪詢 - 可能當你與 服務器交換單呼，並且服務器正在做後臺的一些工作。
這就是我的情況。用戶按下一個按鈕，在服務器端啓動一些複雜的計算，一旦答案就緒，服務器就會向客戶端發送推送通知。問題是，我們可以說，對於一次性響應的情況，長輪詢是比websockets更好的選擇嗎？ 或者，除非我們擔心過時的瀏覽器支持，並且如果我要從頭開始項目，那麼在push協議方面，websockets總是應該比長時間輪詢更受歡迎？
問題是，我們可以說，對於一次性回覆的情況，長輪詢是比websockets更好的選擇嗎？
不是。長時間輪詢效率低下（多次傳入請求，多次您的服務器必須檢查長時間運行的作業的狀態），特別是如果通常的時間段足夠長以至於您將不得不輪詢多次。
如果某個客戶端頁面只可能做一次這個操作，那麼你就可以真正去任何一種方式。每種機制都有一些優點和缺點。
在5-10分鐘的響應時間內，您不能認爲單個http請求會長期等待響應，即使您確定服務器端將保持打開狀態的時間很長，仍會保持活動狀態。客戶端或中間網絡設備（代理服務器等）不會保持初始http連接打開很久。如果你能做到這一點，那將是最有效的機制。但是，我不認爲你可以依賴於你無法控制的隨機網絡配置和客戶端配置。
所以，這給你留下了幾個我認爲你已經知道的選項，但我會在這裏描述其他人的完整性。
選項1：
選項2：
方案3：
方案4：
如果單純從網絡和服務器效率的角度來看事物，那麼選項3或4可能是最有效的。在客戶端和服務器之間只有一個TCP連接的開銷，並且一個連接用於所有流量，並且該連接上的流量非常高效並且支持實際推送，因此客戶端將盡快得到通知。
從體系結構的角度來看，我並不喜歡選項1，因爲當您使用一種技術發起請求，然後通過另一種技術發送響應並且需要您創建關聯時，它似乎有些複雜發起傳入http請求的客戶端和連接的webSocket之間。這可以做到，但它是在服務器上額外的簿記。選項2在結構上很簡單，但效率很低（定期輪詢服務器），所以它也不是我最喜歡的。
完美的答案。感謝您的專業知識 –
有一個替代方案不需要輪詢或一直開放的套接字連接。
它被稱爲web push。
Push API使Web應用程序能夠接收從服務器推送給它們的消息，無論該Web應用程序是處於前臺還是當前加載的用戶代理上。這使得開發人員可以爲選擇加入的用戶提供異步通知和更新，從而更好地參與及時的新內容。
一些特殊待遇是
我不認爲你應該這樣做。如果您進行觸發長時間運行的API調用，則返回202接受並使用位置來檢索結果。見例如HTTP：// farazdagi。com/blog/2014/rest-long-running-jobs/ – jonrsharpe
@jonrsharpe - 客戶仍然需要一種策略來了解長時間運行何時完成以及何時可以得到結果（這是OP的主要觀點題）。你的建議並沒有解決這個問題。 – jfriend00
@jonrsharpe - 這就是OP所要求的。他們應該使用輪詢，長輪詢還是使用webSocket來獲得這樣的響應。您的評論（或您鏈接的文章）不會以任何方式指導他們回答問題的這一部分。 – jfriend00