http 協議介紹：

http 協議是請求/響應正規化的, 每一個 http 響應都是由一個對應的 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-live, http 響應頭中出現, 他的格式是 timeout=30,max=5, timeout 是兩次 http 請求保持的時間(s), , max 是這個 tcp 連線最多為幾個 http請求重用

http 長輪詢：

http 長輪詢是伺服器收到請求後如果有資料, 立刻響應請求; 如果沒有資料就會 hold 一段時間,這段時間內如果有資料立刻響應請求; 如果時間到了還沒有資料, 則響應 http 請求;瀏覽器受到 http 響應後立在傳送一個同樣http 請求查詢是否有資料;

http 長輪詢的侷限:

1. 瀏覽器端對統一伺服器同時 http 連線有最大限制, 最好同一使用者只存在一個長輪詢;
2. 伺服器端沒有資料 hold 住連線時會造成浪費, 容易產生伺服器瓶頸;

http 短輪詢：

http端輪詢是伺服器收到請求不管是否有資料都直接響應 http 請求; 瀏覽器受到 http 響應隔一段時間在傳送同樣的http 請求查詢是否有資料;

http 短輪詢的侷限是實時性低;

兩者相同點：
可以看出 http 長輪詢和 http 短輪詢的都會 hold 一段時間;

兩者不同點
間隔發生在服務端還是瀏覽器端: http 長輪詢在服務端會 hold 一段時間, http 短輪詢在瀏覽器端 “hold”一段時間;

應用：

長輪詢一般用在 web im, im 實時性要求高, http 長輪詢的控制權一直在伺服器端, 而資料是在伺服器端的,因此實時性高;
像新浪微薄的im, 朋友網的 im 以及 webQQ 都是用 http 長輪詢實現的;
NodeJS 的非同步機制貌似可以很好的處理 http 長輪詢導致的伺服器瓶頸問題, 這個有待研究.

http 短輪詢一般用在實時性要求不高的地方, 比如新浪微薄的未讀條數查詢就是瀏覽器端每隔一段時間查詢的.

其他：

關於 http 長連線一個誤解就是伺服器主動推送資料, 這個在 http 協議下是無法實現的, 因為 http請求/響應正規化決定的, http 中伺服器返回資料必須要有一個瀏覽器端的請求對應,伺服器無法主動推送給瀏覽器資料.
不管 http 長輪詢還是 http 短輪詢 保證同一個使用者在多 tab 下只存在一個定時查詢是有好處的,這可以通過在瀏覽器端快取資料解決, 在 http 響應後在瀏覽器端快取資料, 並設定一個有效期,然後在每次傳送 http 請求時檢查是否有有效資料, 沒有則傳送請求獲取