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

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM