HTTP協議中的短輪詢、長輪詢、長串連和短串連

標籤：串連   socket   即時   條件   src   缺點   應用   alt   資料   

今天開始自己研究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 短輪詢一般用在即時性要求不高的地方, 比如新浪微薄的未讀條數查詢就是瀏覽器端每隔一段時間查詢的.

 

HTTP協議中的短輪詢、長輪詢、長串連和短串連