[轉載] 瀏覽器Browser對同域名下的請求併發數量

原文連接：https://blog.csdn.net/a562550212/article/details/79552713

另附原文做者貼的一個知乎地址，幾個答主講的很是好  https://www.zhihu.com/question/20474326

原由：

1. 在面試時問到，移動端首頁是採起5個單獨的請求（返回文件小）好，仍是1個請求（返回文件大）返回全部的數據好？
2. 在開發中發現k線圖總有兩個是延遲渲染的

解決方案：
　　有關網絡問題，通常都是查看瀏覽器的network。經過查看network發現，chrome瀏覽器在同一時間內向同域至多發起6個請求。以後的請求，須要等待前6個返回後才能技術發送。總結：同一時間針對同一域名下的請求有必定數量限制，超過限制數目的請求會被阻塞。知乎用戶王納米

 

 

圖上白線部分表示當前請求等待時間。

1. 採起5個單獨的請求，利用瀏覽器的併發效果，而且考慮一下首屏緣由，優先發送某幾個請求
2. 在代碼中優先請求k線數據接口。

知識解析：
1. 查看瀏覽器開發者工具network的Timing流程，瞭解其對應的含義
我儘可能用中文進行翻譯，若是有錯誤的地方，還但願能指出，我修改。
Firefox瀏覽器

 

 

項目 價格
阻塞（Blocked） 網絡鏈接排隊的時間
瀏覽器強行加入對同域服務器同時發起連接的請求數限制。在Firefox裏默認爲6個，可是能夠經過firefox提供的 network.http.max-persistent-connections-per-server(在url中輸入about:config)。若是全部的鏈接都在使用，瀏覽器沒法下載更多的資源知道其中一個被釋放。
DNS 解析（DNS resolution） 解析域名爲ip地址的時間
握手協議（TLS創建） 三次握手，確保鏈接成功
發送請求（Sending） 發送HTTP請求到服務器的時間
等待（Waiting） 等待服務器的響應（這個時候就得看服務器處理能力了）
接收（Receiving） 獲取當前請求的完整數據包（大部分咱們的響應成功是200，有些大文件，http會分片，根據content-Range）
2. 瀏覽器爲何要作請求限制？
網上的說法挺好，這裏直接引用了。

　　是基於端口數量和線程切換開銷的考慮，瀏覽器不可能無限量的併發請求，所以衍生出來了併發限制和HTTP/1.1的Keep alive。 因此，IE6/7在HTTP/1.1下的併發才2，但HTTP/1.0倒是4。 而隨着技術的發展，負載均衡和各種NoSQL的大量應用，基本已經足以應對C10K的問題。 但卻並非每一個網站都懂得利用domain hash也就是多域名來加速訪問。所以，新的瀏覽器加大了併發數的限制，但卻仍控制在8之內

 

　　因爲 TCP 協議的限制，PC 端只有65536個端口可用以向外部發出鏈接，而操做系統對半開鏈接數也有限制以保護操做系統的 TCP\IP 協議棧資源不被迅速耗盡，所以瀏覽器很差發出太多的 TCP 鏈接，而是採起用完了以後再重複利用 TCP 鏈接或者乾脆從新創建 TCP 鏈接的方法。
若是採用阻塞的套接字模型來創建鏈接，同時發出多個鏈接會致使瀏覽器不得很少開幾個線程，而線程有時候算不得是輕量級資源，畢竟作一次上下文切換開銷不小。
　　這是瀏覽器做爲一個有良知的客戶端在保護服務器。就像以太網的衝突檢測機制，客戶端在使用公共資源的時候必需要自行決定一個等待期。當超過2個客戶端要使用公共資源時，強勢的那個邪惡的客戶端可能會致使弱勢的客戶端徹底沒法訪問公共資源。從前迅雷被噴就是由於它不是一個有良知的客戶端，它做爲 HTTP 協議客戶端沒有考慮到服務器的壓力，做爲 BT 客戶端沒有考慮到本身回饋上傳量的義務。
————————————————