通常看到標題咱們通常會產生下面幾個問題???javascript
接下來咱們就一個個來了解下,在這以前咱們先看看http協議是什麼??html
1、http協議介紹java
http 協議是請求/響應範式的, 每個 http 響應都是由一個對應的 http 請求產生的; http 協議是無狀態的,多個 http 請求之間是沒有關係的.node
http端輪詢是服務器收到請求不論是否有數據都直接響應 http 請求; 瀏覽器受到 http 響應隔一段時間在發送一樣的http 請求查詢是否有數據;web
http 短輪詢的侷限是實時性低;後端
二者相同點:
能夠看出 http 長輪詢和 http 短輪詢的都會 hold 一段時間;瀏覽器
二者不一樣點
間隔發生在服務端仍是瀏覽器端: http 長輪詢在服務端會 hold 一段時間, http 短輪詢在瀏覽器端 「hold」一段時間;緩存
http 長輪詢是服務器收到請求後若是有數據, 馬上響應請求; 若是沒有數據就會 hold 一段時間,這段時間內若是有數據馬上響應請求; 若是時間到了尚未數據, 則響應 http 請求;瀏覽器受到 http 響應後立在發送一個一樣http 請求查詢是否有數據;服務器
http 長輪詢的侷限:網絡
目前 http 協議廣泛使用的是 1.1 版本, 以前有個 1.0 版本,二者之間的一個區別是 1.1 支持 http 長鏈接, 或者叫持久鏈接.1.0 不支持 http 長鏈接, 每次一個 http請求響應後都關閉 tcp 鏈接, 下個 http 請求會從新創建 tcp 鏈接.
所謂 http 長鏈接, 就是多個 http 請求共用一個 tcp 鏈接; 這樣能夠減小屢次臨近 http 請求致使 tcp創建關閉所產生的時間消耗. http 1.1 中在請求頭和相應頭中用 connection字段標識是不是 http長鏈接, connection: keep-alive, 代表是 http 長鏈接; connection:closed, 代表服務器關閉 tcp 鏈接
與 connection 對應的一個字段是 keep-live, http 響應頭中出現, 他的格式是 timeout=30,max=5, timeout 是兩次 http 請求保持的時間(s), , max 是這個 tcp 鏈接最多爲幾個 http請求重用
5、webSocket:
WebSocket的實現了一次鏈接,雙方通訊的功能。首先由客戶端發出WebSocket請求,服務器端進行響應,實現相似TCP握手的動做。這個鏈接一旦創建起來,就保持在客戶端和服務器之間,二者之間能夠直接的進行數據的互相傳送。服務器端的邏輯比較複雜,若是是java或者node開發,都有不少封裝好的組件可使用。
案例:①、建立webSocket對象
var ws = new WebSocket(「ws//localhost:8080」);
WebSocket是一個不一樣於HTTP的協議,其參數傳遞中的ws://前綴相似於http://,用於進行協議的聲明。
②、事件操做
WebSocket提供了四個事件操做,以下:
onmessage收到服務器響應時執行
onerroe 出現異常時執行
onopen 創建起鏈接時執行
onclose 斷開鏈接時執行
6、優缺點
輪詢:客戶端定時向服務器發送Ajax請求,服務器接到請求後立刻返回響應信息並關閉鏈接。
優勢:後端程序編寫比較容易。
缺點:請求中有大半是無用,浪費帶寬和服務器資源。
實例:適於小型應用。
長輪詢:客戶端向服務器發送Ajax請求,服務器接到請求後hold住鏈接,直到有新消息才返回響應信息並關閉鏈接,客戶端處理完響應信息後再向服務器發送新的請求。
優勢:在無消息的狀況下不會頻繁的請求,耗費資源小。
缺點:服務器hold鏈接會消耗資源,返回數據順序無保證,難於管理維護。
實例:WebQQ、Hi網頁版、Facebook IM。
長鏈接:在頁面裏嵌入一個隱蔵iframe,將這個隱蔵iframe的src屬性設爲對一個長鏈接的請求或是採用xhr請求,服務器端就能源源不斷地往客戶端輸入數據。
優勢:消息即時到達,不發無用請求;管理起來也相對方便。
缺點:服務器維護一個長鏈接會增長開銷。
實例:Gmail聊天
Flash Socket:在頁面中內嵌入一個使用了Socket類的 Flash 程序JavaScript經過調用此Flash程序提供的Socket接口與服務器端的Socket接口進行通訊,JavaScript在收到服務器端傳送的信息後控制頁面的顯示。
優勢:實現真正的即時通訊,而不是僞即時。
缺點:客戶端必須安裝Flash插件;非HTTP協議,沒法自動穿越防火牆。
實例:網絡互動遊戲。
長輪詢通常用在 web im, im 實時性要求高, http 長輪詢的控制權一直在服務器端, 而數據是在服務器端的,所以實時性高;
像新浪微薄的im, 朋友網的 im 以及 webQQ 都是用 http 長輪詢實現的;
NodeJS 的異步機制貌似能夠很好的處理 http 長輪詢致使的服務器瓶頸問題, 這個有待研究.
http 短輪詢通常用在實時性要求不高的地方, 好比新浪微薄的未讀條數查詢就是瀏覽器端每隔一段時間查詢的.
關於 http 長鏈接一個誤解就是服務器主動推送數據, 這個在 http 協議下是沒法實現的, 由於 http請求/響應範式決定的, http 中服務器返回數據必需要有一個瀏覽器端的請求對應,服務器沒法主動推送給瀏覽器數據.
無論 http 長輪詢仍是 http 短輪詢 保證同一個用戶在多 tab 下只存在一個定時查詢是有好處的,這能夠經過在瀏覽器端緩存數據解決, 在 http 響應後在瀏覽器端緩存數據, 並設置一個有效期,而後在每次發送 http 請求時檢查是否有有效數據, 沒有則發送請求獲取
這是我所學習的東西,固然這只是總結啦,寫得很差別見怪,寫錯了麻煩指正謝謝