為什麼是長輪詢而不是持久連線。

阿新 • • 發佈：2019-01-17

在web開發當中，常用的伺服器推技術主要是兩種，長輪詢和持久連線。

如果我們仔細觀察現有的產品實現，會發現，大多都會選擇長輪詢，而不是持久連線。（webqq、人人IM、facebook IM、新浪微博等都是基於長輪詢）。

在不考慮其他外掛技術，如flash等的情況下，對長輪詢和持久連線做一下對比如下：

優劣對比
長輪詢	持久連線
效能	重複建立連線，網路開銷大。	不需要重複建立連線，開銷小，但需要間隔傳送比較小的心跳包。
瀏覽器相容性	jsonp和xhr都可以相容所有瀏覽器。	iframe流可以相容所有瀏覽器。
網路相容性	可以相容任何透明代理，防火牆。	無法相容某些透明代理、防火牆。

我今天主要說一下《網路相容性

》這方面。現在，透明代理和防火牆代理的應用非常普遍。由於實際網路中，大量不支援http1.1以及不相容的攔截代理配置的情況下，

基於持久連線的服務推技術，就不能正確實現了。

如上圖所示的透明代理存在的情況下，內網的使用者瀏覽器端發起的持久連線，可能在透明代理等存在的情況下，錯誤地當做的常規的基於“請求-響應”的短連線請求。

這樣，當伺服器在傳送完資料，並繼續保持連線的情況下，透明代理可能不會及時或正確地將資料返回給使用者的瀏覽器端。

例如，透明代理可能會將伺服器的響應放到一塊緩衝區當中，當伺服器關閉連線時，代理再將資料一併返回。當發生這種問題的時候，輕者會造成訊息延遲，重者會導致客戶端一段時間內沒有收到心跳，而導致產生超時而主動斷開連線。

因此，在複雜網路情況下，基於持久連線的服務推技術很可能會失效。而基於長輪詢的伺服器推技術，由於實際上跟普通的http請求沒有根本上的差異，因而可以更好的穿過這些透明的中間代理。我想這也是很多WEBIM應用大多采用長輪詢而不是持久連線的理由之一吧。