短輪詢和長輪詢的目的都是用于實現(xiàn)客戶端和服務(wù)器端的一個即時通訊。

短輪詢的基本思路： 瀏覽器每隔一段時間向瀏覽器發(fā)送 http 請求，服務(wù)器端在收到請求后，不論是否有數(shù)據(jù)更新，都直接進行響應(yīng)。這種方式實現(xiàn)的即時通信，本質(zhì)上還是瀏覽器發(fā)送請求，服務(wù)器接受請求的一個過程，通過讓客戶端不斷的進行請求，使得客戶端能夠模擬實時地收到服務(wù)器端的數(shù)據(jù)的變化。這種方式的優(yōu)點是比較簡單，易于理解。缺點是這種方式由于需要不斷的建立 http 連接，嚴重浪費了服務(wù)器端和客戶端的資源。當(dāng)用戶增加時，服務(wù)器端的壓力就會變大，這是很不合理的。

長輪詢的基本思路： 首先由客戶端向服務(wù)器發(fā)起請求，當(dāng)服務(wù)器收到客戶端發(fā)來的請求后，服務(wù)器端不會直接進行響應(yīng)，而是先將這個請求掛起，然后判斷服務(wù)器端數(shù)據(jù)是否有更新。如果有更新，則進行響應(yīng)，如果一直沒有數(shù)據(jù)，則到達一定的時間限制才返回?？蛻舳?JavaScript 響應(yīng)處理函數(shù)會在處理完服務(wù)器返回的信息后，再次發(fā)出請求，重新建立連接。長輪詢和短輪詢比起來，它的優(yōu)點是明顯減少了很多不必要的 http 請求次數(shù)，相比之下節(jié)約了資源。長輪詢的缺點在于，連接掛起也會導(dǎo)致資源的浪費。

SSE 的基本思想： 服務(wù)器使用流信息向服務(wù)器推送信息。嚴格地說，http 協(xié)議無法做到服務(wù)器主動推送信息。但是，有一種變通方法，就是服務(wù)器向客戶端聲明，接下來要發(fā)送的是流信息。也就是說，發(fā)送的不是一次性的數(shù)據(jù)包，而是一個數(shù)據(jù)流，會連續(xù)不斷地發(fā)送過來。這時，客戶端不會關(guān)閉連接，會一直等著服務(wù)器發(fā)過來的新的數(shù)據(jù)流，視頻播放就是這樣的例子。SSE 就是利用這種機制，使用流信息向瀏覽器推送信息。它基于 http 協(xié)議，目前除了 IE/Edge，其他瀏覽器都支持。它相對于前面兩種方式來說，不需要建立過多的 http 請求，相比之下節(jié)約了資源。

WebSocket 是 HTML5 定義的一個新協(xié)議議，與傳統(tǒng)的 http 協(xié)議不同，該協(xié)議允許由服務(wù)器主動的向客戶端推送信息。使用 WebSocket 協(xié)議的缺點是在服務(wù)器端的配置比較復(fù)雜。WebSocket 是一個全雙工的協(xié)議，也就是通信雙方是平等的，可以相互發(fā)送消息，而 SSE 的方式是單向通信的，只能由服務(wù)器端向客戶端推送信息，如果客戶端需要發(fā)送信息就是屬于下一個 http 請求了。

上面的四個通信協(xié)議，前三個都是基于HTTP協(xié)議的。對于這四種即使通信協(xié)議，從性能的角度來看：WebSocket > 長連接（SEE） > 長輪詢 > 短輪詢但是，我們?nèi)绻紤]瀏覽器的兼容性問題，順序就恰恰相反了：短輪詢 > 長輪詢 > 長連接（SEE） > WebSocket所以，還是要根據(jù)具體的使用場景來判斷使用哪種方式。