HTTP協議中的短輪詢、長輪詢、長鏈接和短鏈接

今天開始本身研究nodejs，看見輪詢，研究下

http 協議介紹：

http 協議是請求/響應範式的, 每個 http 響應都是由一個對應的 http 請求產生的; http 協議是無狀態的, 多個 http 請求之間是沒有關係的.

在長鏈接的應用場景下，client端通常不會主動關閉它們之間的鏈接，Client與server之間的鏈接若是一直不關閉的話，會存在一個問題，隨着客戶端鏈接愈來愈多，server遲早有扛不住的時候，這時候server端須要採起一些策略，如關閉一些長時間沒有讀寫事件發生的鏈接，這樣能夠避免一些惡意鏈接致使server端服務受損；若是條件再容許就能夠以客戶端機器爲顆粒度，限制每一個客戶端的最大長鏈接數，這樣能夠徹底避免某個蛋疼的客戶端連累後端服務。

長鏈接和短鏈接的產生在於client和server採起的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇

應用場景區別： 
1. 通常長鏈接（追求實時性高的場景）用於少數client-end to server-end的頻繁的通訊，例如：數據庫的鏈接用長鏈接， 若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket 建立也是對資源的浪費。
2. 而像WEB網站的http服務通常都用短連接（追求資源易回收場景），由於長鏈接對於服務端來講會耗費必定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源。

短輪詢和長輪詢

和短鏈接和長鏈接有本質區別 
1. 短輪詢：重複發送Http請求，查詢目標事件是否完成，優勢：編寫簡單，缺點：浪費帶寬和服務器資源 
2. 長輪詢：在服務端hold住Http請求（死循環或者sleep等等方式），等到目標時間發生，返回Http響應。優勢：在無消息的狀況下不會頻繁的請求，缺點：編寫複雜

應用：

長輪詢通常用在 web im, im 實時性要求高, http 長輪詢的控制權一直在服務器端, 而數據是在服務器端的, 所以實時性高;
像新浪微薄的im, 朋友網的 im 以及 webQQ 都是用 http 長輪詢實現的;
NodeJS 的異步機制貌似能夠很好的處理 http 長輪詢致使的服務器瓶頸問題, 這個有待研究.

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