爲什麼SIgnalR更喜歡Forever Frames輪詢？

我正在學習使用SignalR，到目前爲止，我在這方面取得了成功。我可以實現集線器，我可以實現業務邏輯，我可以從服務器調用客戶端功能，我可以從客戶端調用服務器端方法，這很棒。令我困惑的是理論。爲什麼SIgnalR更喜歡Forever Frames輪詢？

事實上，我從這個video收集信息。 SignalR使用的是WebSockets，它通過單個TCP連接提供full duplex channel。如果沒有可用的WebSocket，則回退協議將爲EventSource。如果不可用，那麼將使用Forever Frame。如果不可用，那麼將使用長輪詢。對於我來說很奇怪的是，一個非常冒險的解決方案，如永遠的框架比較老的慣例更受歡迎，我對SignalR決定將永久框架作爲第三選項和投票作爲第四選項的理由感興趣。

我試圖找出這個問題的答案，我發現它是傳言there is a 3x max latency time in the case of long polling compared to forever frames。這是一個事實嗎？如果是這樣，這是所有瀏覽器或子集的事實嗎？

來源

2016-09-16 Lajos Arpad

foreverFrame有點像serverSentEvents - 有一個長時間運行的http請求，服務器永遠不會終止，但用來將數據推送到客戶端。 longPolling的工作方式不同 - 有一個輪詢http請求，每當有客戶端讀取數據（或超時到期）時，服務器都會關閉該請求。如果客戶想要讀取更多的數據，它需要打開一個新的http請求，一旦客戶端有任何數據，這個請求就會被服務器關閉。換句話說，在foreverFrame的情況下，服務器使用已建立的通道將數據推送到客戶端，而在longPolling的情況下，客戶端不斷創建http請求以從服務器獲取數據。

來源

2016-09-16 02:27:20 Pawel

理解並感謝您的答覆，這已經是值得讚賞的。但是，我想知道是否可以真實地確認每次輪詢器發送數據時由於需要打開HTTP通道而產生的3倍延遲實際上存在。 –

發送數據的方式相同 - 在這兩種情況下都會創建一個新的http請求，所以我會說在發送數據時foreverFrame和longPolling之間的延遲沒有區別。 – Pawel

接收時有延遲嗎？ –

爲什麼SIgnalR更喜歡Forever Frames輪詢？

回答

相關問題